3
\$\begingroup\$

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?

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

1 Answer 1

3
+50
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for those ideas. Unfortunately, when my tests will run the FPGA will not have any logic in it (other than my tests). \$\endgroup\$
    – Randomblue
    Commented Apr 5, 2012 at 15:58
  • 2
    \$\begingroup\$ 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. \$\endgroup\$
    – davidcary
    Commented Apr 12, 2012 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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