On-Chip Memory instruction corruption

How well constrained is your project? How fast is your Nios running? Does it all meet timing? By adding the code you're adding are you exercising part of the logic that has a timing issue but not doing so without the extra code?

Cheers,

Alex

Dear Alex,

Thanks for your reply. I will check the timing a little more. We are running the sysCLK @100Mhz. We also have a TSE GigaBit design and its clocks within the system as well. I know last time I did some timing analysis I had constrained all the clocks but none of the IO

This problem has occurred when we changed the code at times we added code and times we deleted code.

This on chip memory is dual port. We did so more debug on it. I pulled out the basic signals to the block and started looking at them. In the system we have 3 NIOS processors. The first is responsible for communicating to the the Flash. On start up it holds the CPU1 and CPU2 in reset. It reads the instructions from flash and copies them into the separate on chip memories associated with each CPU. It then 1 by 1 releases each CPU after some system checks. This is the basic outline of the system and power up. I check this powerup sequence and I saw the writes from the CPU0 to the on chip memory of CPU1 while it was being held in reset. Then I also saw the release of the CPU1 reset. So far so good. However after the release of the reset for some reason I saw additional bursts of writes to the on chip memory of CPU1. This is not impossible as there is some handshaking and transfer of data to and from CPU1 to CPU0 for storage and retrieval from the flash. I was worried that maybe there was some sort of corruption to to the instruction code. However when we narrowed down the code of the CPU0 we found that it was a single line of code that didn't really do much. It read a variable from the stack from its own on chip memory added 1 and then wrote the the variable back to the stack. This we doubled checked from he assembly code. We changed the stack and the heap everything except where the code is run from and put it into a completely different on chip memory and this strange effect still existed. Interestingly, the CPU1 appeared to work. When we moved the CPU0 instructions into another on chip memory nothing appeared to work - but that was expected.

Any more suggestions from anyone ? Leads ?

You have some timing problems:

+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

; Slow 1100mV 100C Model Setup Summary ;

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------------+

; Clock ; Slack ; End Point TNS ;

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------------+

; clock100MHz ; -5.337 ; -1273.828 ;

; rgmii_125_tx_clk ; -1.041 ; -4.946 ;

On clock100MHz and on rgmii_125_tx_clk you have timing violations (very strong violation on clock100MHz). It is normal that your design does not works.