12:09 <Matt144> cyrozap: Yeah i'll post findings on github once i figure a little bit more out -- What do you mean by 'contains a MAC' -- What does MAC stand for in this situation?

12:34 <vpelletier> Matt144: he probably meant that the fpga does not handle the protocol in a meaningful way, but rather as a pair of shift registers, clocking bits in and out under the control of the cpu

12:53 <PaulFertser> Matt144: I think he meant a peripheral, same as integrated UART, just not integrated but connected on parallel bus :)

12:54 <PaulFertser> Matt144: it's odd you and cyrozap came to polar conclusions regarding where exactly that flash is connected to :)

12:54 <Matt144> yeah im going to like quadruple check to make sure im not telling lies :)

12:55 <Matt144> some of the information ive said here i've been told by my friend whos also working on it with me, its possible we've made mistakes

12:56 <Matt144> re-tracing the serial lines myself right now

13:01 <Matt144> yea confirmed the serial lines lead to the altera but the flash ones only lead to the sharc -- ok mistake on our end there

13:01 <Matt144> my bad bois

13:04 <PaulFertser> Matt144: making some rig to dump this flash with a help of stm32 disco board is what I'd suggest doing next then

14:57 <Matt144> I didnt notice this before: https://i.imgur.com/AZYhOs2.jpg i'm having trouble finding the datasheet for it. Is it an eeprom by any chance? googling LC08A brings up a whole bunch of things... (and im not getting a result for the 29KCXKN)

15:01 <vpelletier> https://www.veswin.com/product-LC08A.html

15:01 <Matt144> yeah click the datasheet link

15:01 <vpelletier> ah, sorry, right

15:10 <PaulFertser> Matt144: in case it's an eeprom it's likely to contain some board-specific calibration data or serial number.

15:32 <Matt144> yeah i figured it wouldnt be too useful

19:23 <cyrozap> Matt144: By "MAC" I just meant some hardware that handles shifting data bits in and out of some MMIO registers, so the CPU doesn't have to bit-bang the protocol, and can just write the data to a FIFO or something.

19:25 <cyrozap> And my guesses are just based on the answers from asking myself, "What would be the easiest thing for the engineers to build that would meet whatever requirements they were given?"

19:31 <cyrozap> From personal experience, I know that building a whole serial protocol state machine in an FPGA is a _total pain in the butt_, and if a CPU is available, it's _way_ easier to just run the state machine in code on the CPU. Conversely, bit-banging protocols from a CPU is extremely annoying due to timing constraints (you either need to use a timer peripheral or a delay loop, and you end up writing a lot of

19:31 <cyrozap> code for even simple protocols), but having an FPGA handle the low-level serialization/deserialization is very easy (for the case of simple UARTs, it's pretty much just a shift register).

19:35 <cyrozap> So it follows that if 1) the serial port is directly connected to the FPGA, and 2) the SHARC is only connected to the FPGA by way of the SHARC's memory bus, then the simplest thing to do would be to do the serialization/deserialization in the FPGA and just expose some memory-mapped registers that the SHARC can use to send and receive data.