cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
br1024
Visitor
Visitor
566 Views
Registered: ‎07-22-2021

FDCE + synchronous reset = FDRE?

Jump to solution

Hello,

Using the following dummy VHDL code, Vivado will decide that "q" should be a flip-flop with an asynchronous reset (FDCE):

library ieee;
use ieee.std_logic_1164.all;

entity asynchronous_reset is
  port(
    clock, Reset, data: std_logic;
    q: std_logic
  );
end asynchronous_reset;

architecture bhv of asynchronous_reset is
begin

  process(clock, Reset)
    if Reset = '1' then
      q <= '0';
    elsif rising_edge(clock) then
      q <= data;
    end if;
  end process;

end bhv;

Now, if the "Reset" signal is actually a signal synchronous to "clock", it becomes a synchronous reset, but because of the code structure, Vivado still infers a FDCE primitive considering this signal as an asynchronous reset. However, Vivado does check the reset path timing, making sure that all flip-flops that depend on that reset will go out of reset at the same time, which it can/does not when the "Reset" signal is really asynchronous.

So my question is, does using a FDCE with a synchronous reset signal is the same as using a FDRE (flip-flop with a synchronous reset) in the end? My main concerns here are about out of reset synchronization, logics utilization and power consumption. I know using an asynchronous reset code structure for a synchronous reset is probably a bad coding style, but let's pretend that's not a concern please.

If it makes a difference, my main FPGA target is a Zynq-7000 series (and maybe Ultrascale+). I'm also curious if this would also apply to ASIC, although that's probably dependent on the ASIC tools/technologies.

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
534 Views
Registered: ‎01-23-2009

An "Asynchronous reset" does not mean that it can be used asynchronously to the clock (this is probably the biggest misconception with the name). So if your signal "Reset" is not synchronized to clock (at least the deasserting edge of Reset) then your design is vulnerable to failure on startup - this is an "illegal" design. Take a look at this post on asynchronous resets.

The difference between an asynchronous reset and a synchronous reset basically depends on which has priority - the clock or the reset. In an asynchronous reset, the flip-flop will go to the reset state immediately on assertion of the reset, regardless of the clock (even if the clock is not running). On a synchronous reset, the flip-flop will remain in the current state until the first rising edge of the clock where the Reset is asserted. The difference between these is determined by your code.

The RTL code you have is explicitly calling for an asynchronous reset (hence an FDCE). To use a synchronous reset (FDRE) you need to modify your code.

architecture bhv of asynchronous_reset is
begin

  process(clock)
if rising_edge(clock) then if Reset = '1' then q <= '0'; else q <= data; end if;
end if; end process; end bhv;

This code matches the behavior of a synchronous reset - the reset will only take effect on the rising edge of the clock. (And by the way, in your code, the sensitivity list should only have clock and Reset in it - a flip-flop should never have data in its sensitivity list).

In both cases, Reset must be synchronous to clock. In the case of an asynchronous reset, it is legal to have an "asynchronously asserted, synchronously cleared" signal, which is usually generated by a reset bridge.

Avrum

View solution in original post

4 Replies
avrumw
Expert
Expert
535 Views
Registered: ‎01-23-2009

An "Asynchronous reset" does not mean that it can be used asynchronously to the clock (this is probably the biggest misconception with the name). So if your signal "Reset" is not synchronized to clock (at least the deasserting edge of Reset) then your design is vulnerable to failure on startup - this is an "illegal" design. Take a look at this post on asynchronous resets.

The difference between an asynchronous reset and a synchronous reset basically depends on which has priority - the clock or the reset. In an asynchronous reset, the flip-flop will go to the reset state immediately on assertion of the reset, regardless of the clock (even if the clock is not running). On a synchronous reset, the flip-flop will remain in the current state until the first rising edge of the clock where the Reset is asserted. The difference between these is determined by your code.

The RTL code you have is explicitly calling for an asynchronous reset (hence an FDCE). To use a synchronous reset (FDRE) you need to modify your code.

architecture bhv of asynchronous_reset is
begin

  process(clock)
if rising_edge(clock) then if Reset = '1' then q <= '0'; else q <= data; end if;
end if; end process; end bhv;

This code matches the behavior of a synchronous reset - the reset will only take effect on the rising edge of the clock. (And by the way, in your code, the sensitivity list should only have clock and Reset in it - a flip-flop should never have data in its sensitivity list).

In both cases, Reset must be synchronous to clock. In the case of an asynchronous reset, it is legal to have an "asynchronously asserted, synchronously cleared" signal, which is usually generated by a reset bridge.

Avrum

View solution in original post

drjohnsmith
Teacher
Teacher
516 Views
Registered: ‎07-09-2009

your code also has a wrong sensitivity list,

   data is post the clock,  so should not be in the sensitivity list, 

this will result in different simulation and syntheses results,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
br1024
Visitor
Visitor
428 Views
Registered: ‎07-22-2021

You're both right about the sensitivity list, I've fixed it in the original post.

@avrumw Thanks for the clarification about what asynchronous resets mean in the FDCE case, my initial understanding was wrong indeed. Coincidently, this also confirms my initial hypothesis: when the reset signal only changes in sync with the clock, then FDCE and FDRE behave the same. But it only makes sense to use FDCE when the reset signal also changes when there is no clock though.
BTW, I also want to thank you for all the answers you've given in these forums which are always clear and well detailed so that the readers always understand not just what to do but also why to do it. Each time I had questions or doubts about FPGAs related topics, I always ended up stumbling upon one of your posts that answered them perfectly, so thanks a lot for that!

seamusbleu
Voyager
Voyager
389 Views
Registered: ‎08-12-2008

Be aware that when you describe a synchronous reset, the reset signal may not go to the reset "pin" of the FF - it might just be part of the lut logic that gets AND'd with everything else feeding the d-input of the FF.  This can be advantageous in that it might reduce the number of control sets that are used and that can help the fitter place your logic.  Either way, the logic performs the same.  With an async reset, no choice like that is possible.

<== If this was helpful, please feel free to give Kudos, and accept as Solution if it answers your question ==>