FDCE vs FDRE in 7-series/Zynq devices

[tjnash]

According to the HDL coding techniques in Chapter 3 of the "Vivado Design Suite User Guide: Synthesis", rule number 1 is "Do not asynchronously set or reset registers".  This sounds consistent with the guidance in Xilinx WP272 (Get Smart About Reset...).

Why then, do the 7-series/Zynq devices have a FDCE primitive?  Granted, this question assumes that the term 'set' and 'preset' are synonymous, as are the terms 'clear' and 'reset'.  To experiment, I've synthesized a design implementing an asynchronous reset (with Synplify Pro) and sure enough, it instantiates a FDCE primitive, as expected.

Have I misunderstood the guidance?  Does Xilinx WP272 even apply to these devices?  I don't see the design getting more complicated, as the HDL coding guidance seems to imply.

Thanks in advance!

Tim

[avrumw]

The rule "Do not asynchronously set or reset registers" is a bit strongly stated in that manual.

First, don't get me wrong, I am not advocating asynchronous resets - I agree with the recommendation not to use asynchronous presets and clears - there are a lot of reasons why this recommendation makes sense. But it is not a rule.

Chapter 3 outlines a number of reasons why it is not recommended to use asynchronous presets and clears

• preventing control set reduction
• preventing the use of the registers in the DSP48 and block RAM
• (frankly, even I can't follow the third one)

But those are enough - asynchronous preset/clear make things more complicated. This is on top of the fact that there has historically been a large number of people who use asynchronous preset/clear pins incorrectly - all presets and clears must be deasserted synchronously to the clock - failure to do so will lead to system failures (and this is described in WP272).

But all this being said, you can use asynchronous presets and clears in Xilinx designs. There are applications where you want to/need to; the most common are

• when you have a portion of the design that may not always have a valid clock
  • an asynchronous preset and clear can return a system to a known state even when no clock is present
• when there is potential to do damage to an external device when no clock is present (or not present yet)
  • for example driving the "enable" of a radio transmitter or motor
  • making sure a tristate pin is tristated at time 0 (to prevent contention)

And we also have to acknowledge that designs in the past have used asynchronous presets and clears - we don't want to force everyone to re-code.

So, the FDPE and FDCE exist, are supported and are fully understood by the tools. They can be used. However, you should only use them if you have a clear and compelling reason to do so (like some of the examples above). If you are coding new stuff and it doesn't fall into any of the categories I described above, then you should use synchronous resets only (or no resets, as applicable - again as described in WP272).

Avrum

[tjnash]

Thanks, Avrum!  I think I understand most of your point..  The only outstanding question I have is the idea that using asynchronous resets/presets may "prevent control set reduction".  If use of an asynchronous reset distills down to a single instance of FDCE (as did in my synthesis experiment, shown below), what control set reduction have I prevented?

always @(posedge clk or posedge rst) begin
  if (reset)
    q <= '0;
  else
    q <= d;
end

Even if I add a clock enable (synchronous), the FDCE/FDPE primitives have a clock enable input on them. Does this guidance only apply to some design of potentially more complexity?  I think my hangup is on the idea that the use of FDCE and FDPE are reserved for special cases, even though they are no less available (and sound equally routable) as their synchronous counterparts, FDRE and FDSE.

Thanks!

Tim

[avrumw · Accepted solution]

All 8 flip-flops in a slice (in the 7 series devices) share the same control set; they all use the same clock, reset, and clock enable.

If two flip-flops have different control sets, then they cannot be packed into the same slice, and that can cause efficiency problems in devices that are full (or are speed critical).

Now take the example of these two flip-flops. They both use the same clock, have the same CE, but one uses a synchronous reset and the other does not (it is never reset). These two cannot be packed in the same slice due to the different control sets.

However, the synthesis tool can do control set reduction. It can replace the synchronous reset with an AND gate in front of the D input of the flip-flop, with the other input being the !reset (and this AND function can be merged with the LUT in front of the flip-flop if it has a spare input). Now both flip-flops have the same clock, reset (which is none - i.e. Logic 0) and CE, and hence can be packed into the same slice. So control set reduction may increase logic (LUT) utilization slightly, but can improve packing hence reduce overall slice utilization.

With an asynchronous clear, there is no equivalent - the asynchronous clear must be routed to the CLR pin of the FDCE. The tools cannot to control set reduction, so these two flip-flops will end up in two different slices.

Avrum

[chapman]

I'm really pleased to see this discussion.

Remember that your starting point should be NO reset at all! Unless you have a compelling logical reason to have a local reset then don't put one in your code. All flip-flops (and memory contents) have a known defined state after configuration so you don't need to have yet another signal to do the same job.   

I think you will also find the following white paper useful...

https://www.xilinx.com/support/documentation/white_papers/wp275.pdf

[rggber]

I found this post and I have the same issue about ff reset. In the red, what is the known defined state after configuration for A7 fpga. Does "reg[7:0] reg_mt = 8'b0000_0000 has the same effect for this?

---

@chapmanwrote:

I'm really pleased to see this discussion.

Remember that your starting point should be NO reset at all! Unless you have a compelling logical reason to have a local reset then don't put one in your code. All flip-flops (and memory contents) have a known defined state after configuration so you don't need to have yet another signal to do the same job.   

I think you will also find the following white paper useful...

https://www.xilinx.com/support/documentation/white_papers/wp275.pdf

---