Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

On-Chip Memory instruction corruption

We have a design which uses a NIOS CPU whose instruction code is stored in On-Chip Memory. Most of the time everything works however there are times when the code is changed slightly and either the f...
Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

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 ?