I am writing a really simple program on Verilog for my FPGA to have an LED blink once a button is pushed. Here is the code I have written:

module hello_world(
   input ron,           //reset button (ron = reset/on) 
   input clk,           //clk, on board clk is 25 MHz
   output reg led1,     //led to blink
   output reg start);   //problematic signal

reg [22:0] led;
always @(posedge clk) begin 
    if(!ron) begin
        led <= 0;
        start <= 1;

    if(start) begin
        led <= led + 23'b00000000000000000000001;
        led1 <= led[22];


I know there are probably cleaner ways of doing this, but I'm just doing this way, and there is a really weird problem that is occurring. The 'start' register is being set to 1 before I even hit the 'ron' button (reset/on button) and I have no clue why. This problem is happening with any register that I assign 1 to in the if statement.

I tried simulating it in ModelSim, and it seems to run fine, but on the FPGA board (Polmaddie7) it assigns start to 1 before the button is hit.

I would appreciate any help on this please. If I have left any information out that would be helpful to understanding/answering this, please let me know.

  • \$\begingroup\$ Your button may be an active-low type. See this \$\endgroup\$
    – Oldfart
    Commented Sep 5, 2019 at 20:28
  • \$\begingroup\$ Also, some FPGAs have flip-flops are automatically globally reset at start-up, whether your code explicitly describes this behavior or not. \$\endgroup\$
    – The Photon
    Commented Sep 5, 2019 at 20:30
  • \$\begingroup\$ @Oldfart It is an active low pin, that's why I have !ron in the if statement to account for that. \$\endgroup\$
    – Lokwill
    Commented Sep 5, 2019 at 20:31

2 Answers 2


There are two possibilities (at least)

  • Your FPGA has an automatic global reset at start up. Since your code resets led to 0 and start to 1, these are the values they will get when the global reset is applied.

  • Your FPGA doesn't have an automatic global reset. In that case, the initial value of led and start are unpredictable. They just happen to be coming up as 0 and 1 respectively as a matter of chance (and the operating temperature, timing of the power supply ramp up, etc.)

If you want to know what value your start signal will have at power up (for example, you want it to be 0 until the ron signal goes low), then you should code it to reset to 0, and implement a global reset, or choose an FPGA that automatically performs global reset. In this case you need to code the reset behavior of start as going to 0, and use ron as an ordinary signal (not routed on the dedicated reset inputs of the flip-flops) that causes a state transition of start from low to high.

  • \$\begingroup\$ What do you mean by dedicated reset routing resources, when specifying the pin for the ron I just assigned it to a button? Can you elaborate on what you mean by using ron as an ordinary signal causing a transition? \$\endgroup\$
    – Lokwill
    Commented Sep 5, 2019 at 20:38
  • \$\begingroup\$ @Lokwill, that wasn't really what I should have said. I've corrected the answer post. \$\endgroup\$
    – The Photon
    Commented Sep 5, 2019 at 20:42
  • \$\begingroup\$ Hmm, I'm still confused. I am relatively new to the FPGA world. I don't understand how led is 0 and start is 1 if my code says that this should only happen when !ron occurs. \$\endgroup\$
    – Lokwill
    Commented Sep 5, 2019 at 20:46
  • \$\begingroup\$ @Lokwill, if the FPGA has automatic global reset, it will automatically assert !ron at start-up (and in a way that the clock doesn't matter), regardless of what your code says. There might be a way to disable this, but how to do it would depend on exactly which FPGA you're using. \$\endgroup\$
    – The Photon
    Commented Sep 5, 2019 at 20:47
  • \$\begingroup\$ However if you disable global reset, then what state start comes up in is unpredictable. It might always be 1, might always be 0, might sometimes be 1 and sometimes 0, etc. You're much better off using global reset and explicitly choosing which way your signals come up. \$\endgroup\$
    – The Photon
    Commented Sep 5, 2019 at 20:49

my answer

Quartus has an option named "power-Up don't care" enabled by default.


My guess is quartus sees that it will be reset at 1, and so start it as 1

notes on the code

  • In general it is a good idea to have a power up reset logic to avoid this kind of problem. Simply because this is what we usually do in simu, so to simply make life easier for a lot of things.
  • I have seen cases where it is preferable to disable the "power-Up don't care" to about don't cares in synthesys.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.