Hi there,

> 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?

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

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.