Tell me more ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.

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:

  1. Write an SRAM driver directly from the FPGA (without involving the Cortex).
  2. 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?

share|improve this question
What's the FPGA doing in this circuit if it's not the memory controller? – AngryEE Apr 5 '12 at 17:40
Eventually, in the final product, it will be (partly) the memory controller. However, for production testing, the FPGA comes blank. – Randomblue Apr 5 '12 at 17:56
How about a datasheet for the SRAM? Is it designed for boundary scan test? – The Photon Apr 9 '12 at 23:19
@ThePhoton: Here is a link to the SRAM datasheet. – Randomblue Apr 10 '12 at 8:23

1 Answer

up vote 2 down vote accepted
+50

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.

share|improve this answer
Thanks for those ideas. Unfortunately, when my tests will run the FPGA will not have any logic in it (other than my tests). – Randomblue Apr 5 '12 at 15:58
2  
Why is the FPGA connected to the SRAM? (a) if the FPGA in the final application is acting as a simple memory controller because the ARM for some reason can't be directly hooked to the SRAM, then program the FPGA in the same way in your production test and let software in the ARM test the SRAM. (b) if the FPGA in the final application is doing something more complicated -- perhaps reading and writing the SRAM far faster than the ARM chip alone -- then you need to have custom logic in the FPGA that stress tests the SRAM in a similar (but deterministic) way. – davidcary Apr 12 '12 at 14:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.