Those ones are automatically assigned by Quartus (that's why you don't put them in your design).
What I meant by auto assign is lets say you have a PIO with 8 output bits. You then connect an 8 bit set of I/O to it but you don't use Quartus or the SOPC Builder pin mapper to assign them. Quartus will look at those I/O and route them in such a way to get the best timing possible (so if the PIO registers are on the left side of the FPGA it won't wire those to the right side I/O if it can help it). Now sometimes people run into problems when they let Quartus do this automatically because it may route these signals to devices on your board then cause all kinds of problems.
Here's an example (Nios development board): You let Quartus auto-assign a PIO pin and it chooses to pick the PLD-reconfig pin ...... the first time you write to the PIO you may trigger a reconfiguration condition. The reason why I choose that example is that it ties into my other point:
<div class='quotetop'>QUOTE </div>
--- Quote Start ---
4) If you are using a Nios development board make sure unused I/O are set to tri-state[/b]
--- Quote End ---
If you download to a Nios dev. board and the project is not set to tri-state unused I/O (set to ground by default) then after programing the design will trigger a reset (which will cause your design with an OCI core to disappear under some cases). This is a pretty interesting case when your design is programmed from flash because you enter this loop:
1) Board powers up
2) Max part programs the FPGA with the image out of Flash
3) FPGA design triggers a re-config
4) Go back to step 2
(your board gets stuck in a programming loop, you'll notice the LEDs flashing on and off a lot).
This probably doesn't help motumboe but since we were on the topic I wanted to share that to save someone else some headaches.
Honored Contributor
