Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Reset for Registers in FPGA?

Status
Not open for further replies.

digi001

Full Member level 5
Joined
Apr 5, 2011
Messages
244
Helped
22
Reputation
44
Reaction score
21
Trophy points
1,298
Activity points
2,904
I noticed in some of my larger designs, my RESET signal isn't able to reach all of the registers in the required amount of time. Would it make sense to route this reset signal to say a Global Clock network in order to reach all of the various registers throughout the design efficiently?
 

If you are using a Xilinx device, using global clock network for reset with high fanouts can be a good option. However, it isn't super fast, so it may not help if you have really tight timing requirement.
 

To help with this, you should synchronise your reset to the clock domain.
 
  • Like
Reactions: digi001

    digi001

    Points: 2
    Helpful Answer Positive Rating
If you have so many modules to reset then use more than one reset pins ans short all of them.place them appropriately to get the reset in time
 

As far as I'm aware of, all recent design tools are automatically assigning global networks to high fanout signals, including reset. In so far, it's not quite clear what specifically brings up the reported problems.

How did you exactly come to know the said result? It may be actually a problem of missing reset synchronisation, as already guessed.
 
  • Like
Reactions: digi001

    digi001

    Points: 2
    Helpful Answer Positive Rating
Yes, I believe my original design was a asynchronous reset. Changing this to a synchronous reset should help.

I am using an Altera cyclone ii device.

So instead of:
always@(posedge clock or reset)
if(reset)
.........

I should just use
always@(posedge clock)
if(reset)
............
 

not quite. You should at least double register the reset signal otherwise you may violate setup times.
 
  • Like
Reactions: digi001

    digi001

    Points: 2
    Helpful Answer Positive Rating
can you show me an example?
 

Not a verilog person, but in VHDL:

Code:
signal reset_sync : std_logic_vector(1 downto 0);

reset_sync_proc : process(clk)
begin
  if rising_edge(clk) then
    reset_sync <= reset_sync(0) & reset;
  end if;
end process;

other_proc : process(clk, reset_sync(1))
begin
  if reset_sync(1) = '1' then --then you can do this for altera (because all resets are async):
    --async_reset
  elsif rising_edge(clk) then
    --put reset here if you're Xilinx and registers actually have a sync reset in
  end if;
end process;

This way, the reset is synchronous to the clock, regardless of whether its async or sync on the actual register, so everything should come out of reset together.
 

As you can easily check in the Quartus fitter report resource section, a chipwide reset will be surely implemented as a global network. In most cases, it's preferably to implement an asynchronous reset for all registers, because it doesn't consume additional LUT inputs. The reset must be however synchronized to the clock to avoid timing violations and possible unpredictable behaviour. There's a detailed guide in the Quartus software manual how resets should be synchronized.

Basically, the reset is asserted asynchronously and released synchronously, using a two cascaded FFs.

Your Verilog syntax for asnychronous reset is by the way incorrect.

Instead of
Code:
always@(posedge clock or reset)
if(reset)
...
you should write
Code:
always@(posedge clock or posedge reset)
  if(reset)
    begin
    end
  else
    begin
    end

The synchronizer stage for an asynchronous reset input uses the same style
Code:
reg reset,reset_pre;
always@(posedge clock or posedge reset_in)
  if(reset_in)
    begin
      reset_pre <= 1;
      reset <= 1;
    end
  else
    begin
      reset_pre <= 0;
      reset <= reset_pre;
    end
 
Thanks alot! This is very helpful and clear. So by synchronizing the release of the RESET avoids most problems?

I didn't realize Quartus automatically looks for high fanouts and makes them Global Clocks. Is there a way to confirm this or rather explicitly state it as a global clock? For some reason I still cannot find a simple guide on how to designate my Global Clock networks in Quartus.

.......

-While on the topic of Global Clocks, I have a couple more questions. Say I have a master input clock coming into the FPGA on a Global Clock pin, this then goes to a megafunction PLL to divide it down and output c0. Is this c0 now automatically a global clock? If i write a new verilog module file can I just reference to this clock c0 or do i need to route this clock signal to an input of my verilog module block on the schematic?

-Say i have an output signal of a verilog module block that has a very high fanout and acts as a asynchronous trigger signal to many other verilog modules. Will this give me problems? This should be easy to look up in the timing analysis as for the maxfrequency i can use this?

-Now say I have a verilog module block that has a very high fanout and acts as a synchronous clock signal to many other verilog modules. Will Quartus automatically route this through the Global Clock network? Or any steps I can do to make sure this meets timing requirements?
 

-While on the topic of Global Clocks, I have a couple more questions. Say I have a master input clock coming into the FPGA on a Global Clock pin, this then goes to a megafunction PLL to divide it down and output c0. Is this c0 now automatically a global clock? If i write a new verilog module file can I just reference to this clock c0 or do i need to route this clock signal to an input of my verilog module block on the schematic?

The PLL outputs will also be clocks, and should automaticcally be on a global clock network. From an HDL perspective, its just a wire, so you need to route it into every verilog module that uses it. Its not uncommon to have multiple clock inputs into an HDL file.

-Say i have an output signal of a verilog module block that has a very high fanout and acts as a asynchronous trigger signal to many other verilog modules. Will this give me problems? This should be easy to look up in the timing analysis as for the maxfrequency i can use this?

Dont use asynchronous trigger signals. use synchronous ones. like the reset, they will cause setup and hold time violations. Asynchronous signals cannot be assessed by timing analysis very easily. As its an async signal, a "maxfrequency" is meaningless.

-Now say I have a verilog module block that has a very high fanout and acts as a synchronous clock signal to many other verilog modules. Will Quartus automatically route this through the Global Clock network? Or any steps I can do to make sure this meets timing requirements?

Dont generate clocks in logic. Use clock enables instead. logic clocks CAN be routed onto global clock networks, but its much easier and simpler just to use clock enables. Again, its a timing problem.
 
  • Like
Reactions: digi001

    digi001

    Points: 2
    Helpful Answer Positive Rating
Thanks! My questions might be novice, but you are helping to confirm the correct solutions to issues I am having. Some of the proper digital design aspects are finally clicking for me.

BTW: I'm referencing textbook 'Digital Design An embedded Systems Approach using Verilog' along the way and it is quite helpful.
 
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top