I have an ARM Cortex 3M (reference manual here) connected through the FSMC (Flexible Static Memory Controller) to a Spartan 6 FPGA. In turn, the Spartan 6 is connected to some external SRAM.
I need to production test the SRAM. As I see it, I have two options:
- Write an SRAM driver directly from the FPGA (without involving the Cortex).
- Route the Cortex memory pins through the FPGA to the memory.
Reading through the specs of the SRAM, it seems that writing an SRAM driver for the FPGA is a relatively difficult task. I am therefore inclined to go with option 2. However, I was told that there may be latency issues if I naively bridge up the Cortex to the SRAM.
How can I deal with those potential latency issues? Are there other difficulties arising from option 2 that I might be overlooking?
Best Answer
Presumably the FPGA has some purpose for its SRAM connection, though you haven't specified what that is. I would guess that your best bet would be to have a means by which the Cortex can sufficiently influence how the FPGA writes to SRAM, and find out enough about what it's reading, to determine whether the SRAM is working properly. For example, if the FPGA would normally write the SRAM with data captured received from an ADC, and output it, after a delay, to a DAC, one could have a test mode that would instead write data from a linear-feedback-shift register, and another test mode that would mix data read from the SRAM into a linear-feedback-shift register with slightly different taps. If one can arrange to have each test mode run through the SRAM a controlled number of times, initializing the LFSR before the first pass and reading it after each pass, one can arrange things so that it would be unlikely a broken SRAM would yield the correct LFSR values, but the hardware could be simpler than allowing the CPU direct access, and (more importantly) the access timings would be like those the SRAM would see in actual use.