Still having strange problems with SRAM and FLASH

Hi Pszemol,

From the description of your system & the tests you've completed I think you're very close... from what I gather reading your test setup, though, I am thinking that this may be a timing-related issue. This hypothesis comes from the fact that you can successfully complete a write/readback test using the CPU (data master).

During such tests, the actual reads/writes to SRAM are not consecutive... that, is the assembly code actually running is probably not consecutive LD, LD, LD, LD, ST, ST, ST, etc. Additionally, the Nios CPU (Nios I and Nios II)'s data master is not "latency aware".. so when it does an access and is told to 'wait' by Avalon, it will not issue any more bus requests. This architecture works fine for data operations as (above), data read/writes are usually not consecutive.

however, the CPU instruction master is different... when it is fetching instructions from memory the bus requests are often one per clock cycle. As such, the instruction master is designed to be "latency aware" (by the way, the Avalon bus spec discusses latency). This means that the master pipelines its request, even if the slave has wait states. This works great for SRAM as (depending on the clock speed), you can potentially get one instruction per clock cycle once the first few instructions are fetched.

What this all means is that executing from SRAM, or doing a similar operation (DMA transfer) stresses the timing much more than just doing a memory read/write test with the CPU.

If you have not done so already, it may be a good idea to double check the timing specs for the SRAM you're using against what is setup in SOPC Builder in your interface. Additionally, you might consider temporarily slowing clock speed to see if that helps, or just adding additional delay (setup/hold/wait) in the interface to user logic. Finally, one additional test which may be useful: go into the Quartus floor plan view of your design and look at the tri-state bus pins going off to SRAM. Ensure that the register that is feeding/being fed by that I/O cell are going to the register in the I/O cell, and not going across the chip (the I/O cell registers are the little square boxes in the floor plan view that are joined to the I/O..). Our tri-state bridge logic is designed to put registers into the I/O to minimize delay in going off-chip, but there have been some reports that Q4.0 SP1 was not doing this as it should (the user can always force the registers into the I/O cell via quartus assignment). If this last issue is part of the problem, feel free to contact me and I can discuss it with you further.