1. Home
  2. Field-Programmable Gate Arrays
  3. NIOS SRAM Problem with Stratix

NIOS SRAM Problem with Stratix

We have a NIOS design running at a clock speed of 92 MHz in a Stratix part that will have Flash and SRAM. All of our program memory is to reside in SRAM(IDT714V416L) after boot from flash.

We are able to run the debugger on one out of 10 of our boards but the other 9 seem to be having problems just getting started. Almost looks like we are in a permanent reset(reset has been verified to be inactive). We did a test on one of the non working boards by puting a little "Hello World" test in onboard M4K and that worked fine but will not run the same test running form SRAM.

To me this points to timing problems acessing SRAM. Aother thing that is puzzling is that when you look at the memory through the debugger, it appears that the SRAM has correct data in it. Am I getting fooled by the debugger somehow? We also run the Altera memory test which supposedly verifies the SRAM interface and that works correctly.

We do not have any constraints on any of the I/O going to the SRAM/Flash. The assumption is that since these are registered I/O that it would not be necessary. Is this assumption correct?

Any help would be appreciated resolving this issue.

Reply to
babock
Loading thread data ...

Hi there,

Unfortunately not. If you run the core at 92MHz, there's a fairly good chance that Quartus clumps the logic together in some part of the FPGA in order to easily meet the Fmax. It may use registers on the data in/out bus, but these may be somewehere in the center of the die as well, causing long setup and hold times anyway.

Given your clock frequency requirements, I would suggest setting global Tsu and Tco constraints of about 8ns (which will leave you ~3ns of PCB flight time).

Best regards,

Ben

Reply to
Ben Twijnstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.