How to generate Global RESET signal in Verilog?

[Altera_Forum]

Hi, 

I want to generate a active LOW global reset signal once FPGA device power up. I write my code like this:  reg [9:0] reset_sync_n = 1'b0; //initialize the reset signal   always @ (posedge CLK_50M) //Sync the reset signal to clock  begin  reset_sync_n <= 1'b1; end  //reset_sync_n will be using as synchronous reset signal in others flip-flops logic like below:  always @ (posedge ref_clk)  begin  if (rst)   x <= 0;  else   x<= y;   end  My questions are: 1. Can the reset_sync_n initialized like the above? Will a active LOW reset signal be generated once FPGA device power up?  2. What is the right way to generate the RESET signal? 3. Asynchronous reset is better or synchronous reset is better? Which one is the better coding practice?  This is the doubts that always bother me. Please help me! Thank you!^^

[Altera_Forum]

--- Quote Start ---     1. Can the reset_sync_n initialized like the above? Will a active LOW reset signal be generated once FPGA device power up?    --- Quote End ---    I doubt it as your signal will likely be optimised and set high permanently.    --- Quote Start ---   2. What is the right way to generate the RESET signal?   --- Quote End ---    external reset is recommended. Internally generated reset is not guaranteed though may work well.    --- Quote Start ---   3. Asynchronous reset is better or synchronous reset is better? Which one is the better coding practice?   --- Quote End ---    Old story I am afraid. either way is ok. Altera recommends async (less resource). Xilinx recommends sync (but runs into timing problem). The choice is yours.

[Altera_Forum]

You can use an external reset source and then synchronize it inside FPGA. As kaz said internal reset may be OK, but your design can not be put in a safe state when you need it to be. 

an external reset signal should pass through a reset synchronizer. There are many documents addressing this issue. Study the followings which discuss this topic in details and present reset synchronizer design & code as well: http://www.gstitt.ece.ufl.edu/courses/eel4712/labs/cummingssnug2002sj_resets.pdf http://www.sunburst-design.com/papers/cummingssnug2003boston_resets.pdf Asynchronous or Synchronous Reset? AS kaz said, an old issue. My conclusion is this: Use asynchronous design technique in your codes. In the top level, design a reset synchronizer which generates a synchronous reset signal. Connect that synchronized reset signal to your modules. A reset synchronizer should reset asynchronously, and set synchronously.

[Altera_Forum]

Thanks kaz!^^

[Altera_Forum]

This works too, I've used it for a long time with Altera Cyclone FPGAs. This code assumes CLOCK_50 is running at 50MHz. 

  // PowerUP Reset Logic // generate a 500ms reset pulse on initial powerup reg pup_count = 25'd0; reg pup_reset = 1'b1; always @(posedge CLOCK_50) begin pup_count <=# TPD pup_count + 1'd1; if (pup_count == 25'd25000000) pup_reset <=# TPD 1'b0; end wire reset = pup_reset;   Then it gets used like this (where clk is the global PLL generated clock signal, derived from clock_50) as an async reset:   always @(posedge clk or posedge reset) begin if (reset) begin run <= 1'b0; end else begin run <= mode_normal | mode_emul&stepemul | mode_fast&stepfast | mode_slow&stepslow; end end

[Altera_Forum]

Thanks msj!!!^^

[Altera_Forum]

--- Quote Start ---  This works too, I've used it for a long time with Altera Cyclone FPGAs. This code assumes CLOCK_50 is running at 50MHz.   // PowerUP Reset Logic // generate a 500ms reset pulse on initial powerup reg pup_count = 25'd0; reg pup_reset = 1'b1; always @(posedge CLOCK_50) begin pup_count <=# TPD pup_count + 1'd1; if (pup_count == 25'd25000000) pup_reset <=# TPD 1'b0; end wire reset = pup_reset;   --- Quote End ---   how exactly does this work? after pup_count saturates won't it wrap around to 25'd0 and then start incrementing again?

[Altera_Forum]

--- Quote Start ---  how exactly does this work? after pup_count saturates won't it wrap around to 25'd0 and then start incrementing again?  --- Quote End ---    Yes, but that does not matter. Once PUP_RESET gets set to zero it will stay at that value. The only way to set PUP_RESET to one is to powercycle the FPGA and/or reload the configuration file.  So the fact that the counter just keeps on counting and wrapping (forever) is irrelevant.

[Altera_Forum]

--- Quote Start ---  Yes, but that does not matter. Once PUP_RESET gets set to zero it will stay at that value. The only way to set PUP_RESET to one is to powercycle the FPGA and/or reload the configuration file.  So the fact that the counter just keeps on counting and wrapping (forever) is irrelevant.  --- Quote End ---   Oh, right, I should have seen that myself. I have a follow-up question: why would you want to generate a reset signal on start? Is it just to specify certain values on start? I ask because I thought that was what initial blocks were for. If that assumption is correct, is there a practical difference between using an initial block and a on-start reset signal? Thanks for clearing up my doubts

[Altera_Forum]

For the design this was used in there was a requirement that the logic be held in reset for at least 500ms at powerup for external hardware to completely stabliize. This was an easy way to accomplish this.

[Altera_Forum]

"specify certain values on start" doesn't guarantee a predictable design state after the first clock edge, because the power-on-reset is released asynchronously and might cause timing violations. At worst case, a state machine might fall into a not-recoverable illegal state or a counter start at an unexpected arbitrary value. 

 That's why you want a system wide reset that is synchronously released after the design clock is stable.

[Altera_Forum]

--- Quote Start ---  In the top level, design a reset synchronizer which generates a synchronous reset signal. Connect that synchronized reset signal to your modules. A reset synchronizer should reset asynchronously, and set synchronously.  --- Quote End ---    There is no best way how to design the reset logic, however I also think that the above statement is a good practice.  Thanks, Victor