Verify Failed in Nios II

This should be sufficient to hardcode the pin high:

output wire reconfig_req_n;

assign reconfig_req_n = 1'b1;

--- Quote Start ---

This should be sufficient to hardcode the pin high:

output wire reconfig_req_n;

assign reconfig_req_n = 1'b1;

--- Quote End ---

Thanks, BadOmen,

I agree with your tip, but I was looking for some way to do this in a transparent mode for the code. Please follow my thoughts.

Regardless of a developent kit that supports Nios or not, if I want to implement a simple truth table in my development board, one of the possible ways to do this is:

1. write my truth table HDL code and compile it;

2. go o pin planner, perform a pin association with my logic inputs and outputs and compile my code again; and

3. download my .sof to the board.

I did not perform this basic experiment yet, but according to your tip, I would have to create in my HDL code an additional input to make a logic '1' assignment, inside the code and associate this additional input with PIN_J20, in my case (EP2S60F672C5ES Nios II Stratix II Dev Board).

If my thoughts are correct, my question is: is there any way to do this without have to interfere on the HDL codes? Any kind of hardware act, in Qsys, for example?

ps: yes, I know that I would not have to employ Qsys to buid a truth table...lol...

This hardcoding is only necessary if you have a board that has an external configuration system supporting the reconfiguration request pin. Typically the board has a pullup on the signal so if your design doesn't drive the pin then the pullup will make sure the external hardware doesn't attempt to reconfigure the device. Often designs that don't drive this signal out reserve all unusued pins as input tristate which has the same effect.

The only reason why I brought up this pin is because when this thread started Quartus used to tie unused I/O to ground by default which would cause this reconfiguration cycle to constantly occur if your user design didn't contain that pin. So if your user design doesn't have that pin and you are running into this issue it might be just a matter of going into the device and pin options and changing the unused I/O setting from ground to input tri-state.

Note this isn't a Nios II or Qsys thing it has to do with the board being driven a signal and the possibility of Quartus pulling that signal low if you don't have it in your design.

--- Quote Start ---

This hardcoding is only necessary if you have a board that has an external configuration system supporting the reconfiguration request pin. Typically the board has a pullup on the signal so if your design doesn't drive the pin then the pullup will make sure the external hardware doesn't attempt to reconfigure the device. Often designs that don't drive this signal out reserve all unusued pins as input tristate which has the same effect.

The only reason why I brought up this pin is because when this thread started Quartus used to tie unused I/O to ground by default which would cause this reconfiguration cycle to constantly occur if your user design didn't contain that pin. So if your user design doesn't have that pin and you are running into this issue it might be just a matter of going into the device and pin options and changing the unused I/O setting from ground to input tri-state.

Note this isn't a Nios II or Qsys thing it has to do with the board being driven a signal and the possibility of Quartus pulling that signal low if you don't have it in your design.

--- Quote End ---

Perfect.

Thank you again!