NIOS simulation with modelsim -> strange behaviour

Hi, I would like to simulate a NIOS system with modelsim but I have very strange results : it seems that the external SRAM (for the Nios Apex dev board) is incorectly adressed by the NIOS processor. I'm using quartus 2.2 and sopc builder 2.8 (NIOS 3.0)

Here is what I'm doing :

- the system is minimal (a 32 bit nios, an UART, an on chip memory, the external SRAM and two user interfaces).

- To simulate my program, I'm generating the SRAM_lanexx.dat files from the srec file obtained after compilation.

- The on chip memory contains a GERM monitor

- The uart is configured to simulate a G0000 RX. This allows to branch directly to my program.

- the SRAM is configured as a 32bit data width

What I observe : the GERM runs correctly and the G0000 is correctly received. At the moment the processor fetch the adress 0 (observed with the i_adress port of the nios) everything is wrong. Adresses (i_adress) are going odd : 0000,0002,0004,0006 , etc ... but the wrong instructions are fetched. Indeed, instructions are 16 bit wide (2 bytes) but the memory is 32 bits and it seems that the avalon-tristate bridge is unable to correctly adress the memory. The i_adress is directly transmitted to the SRAM and the wrong bytes are selected. So when fetching adress 0002, it gets the 16 upper bits of the third word (SRAM_adress=0002) instead of the 16 upper bits of the first word (SRAM_adress 0000). The signal byte_en to the SRAM are also always to 0....

So, why does it work like that ? It wasn't the case with previous sopc_builder.

What do I have to change ?

- the way the SRAM is interfaced with the system ?

- the way the program is stored on memory (but I will loose space ..)

- use a 16 bit wide SRAM ? (but I would like to keep 32 bits to keep my design bandwidth ...)

- regenerate a new project ?

Did I missed something with this sopc_builder version? Is it a sopc_builder bug ?

Thanks a lot for you help.


Reply to
Mancini Stephane
Loading thread data ...

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.