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.
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.
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.
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.