Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
780 Views

4-NIOS design, only processor 0 fails to boot from flash at power-on

I have a design with 4-NIOS processors. A single flash part is used for storing the FPGA image as well as NIOS FW image. 

At power on, 3 of the NIOS processors successfully load from flash and begin execution. However one of the NIOS processors (instance-0) fails to start. If the FPGA is then reset all 4 processors successfully load and begin executing from flash. 

 

Anyone else ever see an issue like this or have any ideas of what might be wrong. From the jtag debug tools, it appears that processor 0 is paused. 

Is there perhaps something special about instance 0? 

 

thanks, 

steve.
0 Kudos
5 Replies
Highlighted
Valued Contributor III
11 Views

How are you sequencing the nios boot? 

Only one of the nios can access the flash at any one time. 

So if you are using the Altera EPCS boot code you need to have all but one of the nios power up with the 'soft reset' asserted. 

After each nios finishes booting it should take the next nios out of reset. 

 

Alternatively make one nios responsible for loading all the code/data and put the reset vectors for the other directly into the loaded code.
0 Kudos
Highlighted
Valued Contributor III
11 Views

To be honest, I don't know how *I'm* sequencing the boot (since I'm not)? The altera tools/code do an awesome job of making it easy to get things up and running. 

The boot loader is Altera's out-of-the-box boot copier that's inserted with elf2flash utility. If the altera-boot copier does nothing for sequencing, then I'm not sequencing the boot. 

 

I do know my "local asic guy" put in a flash arbitration module that allows multi-processor access to the flash. We are using a CFI flash part. We're not sharing memory between the 4 processors. The NIOS's are "stamped" out completely independently. 

 

There's obviously a chance there's something broken in the flash arbitration, perhaps a race condition that only hits at power on, versus reset. It's still pretty interesting that only nios[0] fails at power on, but all 4 nios boot after a push of the reset button. One other point, to save time on the FPGA builds, I can build only a single "slice" of our design. In that case, there is only processor (nios[0]), and it still fails to boot at power-on, but succeeds after the reset button. 

 

Thanks for the questions, I'll dig deeper on my side.
0 Kudos
Highlighted
Valued Contributor III
11 Views

Curious, do you know how long is your power-on reset versus reset button asserted?  

Are you using EPCS flash controller provided in Qsys (EPCS/EPCQx1 Serial Flash Controller)? 

What version of Quartus are you using?
0 Kudos
Highlighted
Valued Contributor III
11 Views

 

--- Quote Start ---  

Curious, do you know how long is your power-on reset versus reset button asserted?  

Are you using EPCS flash controller provided in Qsys (EPCS/EPCQx1 Serial Flash Controller)? 

What version of Quartus are you using? 

--- Quote End ---  

 

 

 

The issue was that the NIOS processor was allowed to read from the flash too quickly following reset. The flash part has a minimum reset time after power-on that was not being followed. The arbitration logic was changed to delay the grant signal back to the NIOS processor.
0 Kudos
Highlighted
Valued Contributor III
11 Views

Are you referring to delaying the waitrequest signal? Where did you modify and how long was the delay added? Interested to find out your solution on this.

0 Kudos