search

lnls-dig / afc-hw

AMC FMC Carrier electronic and mechanical projects
Other
1 stars 1 forks source link

Reformat EEPROM access circuit #16

Open henrique-silva opened 8 years ago

henrique-silva commented 8 years ago

Right now is rather confusing the SPI access/control over both EEPROMs (M25P128), mostly because we have 2 masters in this bus, which is an unusual case for SPI architectures.

We use two 2:1 multiplexers to control the Chip select access on both EEPROMs, but all the other signals are shared amongst the MMC and the FPGA pins, which may cause an unexpected behaviour if, for example, they're both writing to the EEPROM. This will cause concurrency on the lines, and most likely they will all be pulled to GND all the time.

A solution for this is use a quad 2:1 multiplexer to switch all the SPI signals at once, thus, isolating both masters interfaces.

aylons commented 8 years ago

This is tricky. I believe the main issue here is mostly documentation - the schematics are really hard to understand, and there is a lack of comments.

As far as I can tell, the designer's idea is t ohave a EEPROM for the FPGA firmware, and another for general use of both the MMC's microcontroller and the FPGA. So, in practice, there are three masters in the SPI bus: FPGA GP logic, FPGA programmer, and MMC.

MMC and FPGA GP logic share the chip select signal, which is multiplexed with the FPGA programming signal to reach the EEPROM chip-select in both chips. As both multiplexers are controlled by the MMC, it may determine which EEPROM the FPGA programming core will actually access, while MMC and FPGA GPIO will have access of the other.

All other signals are shared in the bus. This means that only one of the EEPROMs may be accessed at any time, even by different masters. Thus, the multiplexing scheme serves only to allow the MMC to set from which EEPROM will the FPGA be programmed, while blocking the other. When the MUX is set to allow access for the FPGA GP logic and the MMC, they share all the signals in the bus, and collisions are possible.

It's a hard problem. To ameliorate this issue, we may implement a collision detection mechanism in the FPGA, or an out-of-band arbitration mechanism. While a full-bus MUX would prevent some collisions, it would not prevent blocking and some arbitration would still be needed. A collision avoidance channel access scheme implemented over the FLASH_Cn signal would work just as well.