Return to Support Page
 homesearchagentssupportask xilinxmap

Answers Database


How to describe a flip-flop with a clock enable with VHDL/Verilog


Record #1019

Product Family:  Software

Product Line:  Cadence

Problem Title:
How to describe a flip-flop with a clock enable with VHDL/Verilog


Problem Description:
There are many ways to describe a flip-flop with a clock enable.
Four common ways are shown below. Each is a unique way of describ-
ing a flip-flop with an asynchronous reset and a synchronous clock
enable. The information presented below also applies if the
asynchronous reset is removed from the description.



Solution 1:

Note : Verilog is used for the examples below, but most of the
       information applies to VHDL descriptions as well :

 (1) always @ (posedge clk or posedge rst)
     begin
       if (rst)
	 q <= 1'b0;
       else if (clken)
	 q <= d;
     end

 (2) always @ (posedge clk or posedge rst)
     begin
       if (rst)
	 q <= 1'b0;
       else if (clken)
	 q <= d;
       else
	 q <= q;
     end

 (3) assign d_in = clken ? d : q;

     always @ (posedge clk or posedge rst)
     begin
       if (rst)
	 q <= 1'b0;
       else
	 q <= d_in;
     end

 (4) assign d_in = ((clken & d) | (~clken & q));

     always @ (posedge clk or posedge rst)
     begin
       if (rst)
       else
	 q <= d_in;
     end

* Synopsys has two variables that are used to control feedback of
  sequential elements. The variables and their default values are :

  hdlin_keep_feedback		  "FALSE"
  hdlin_keep_inv_feedback	  "TRUE"

  If you type "help hdlin_keep_inv_feedback" at the dc_shell prompt,
  it informs you that the default value for this variable is FALSE.
  That is not accurate -- the default value is TRUE. This was
  evidently changed at release 3.2b, and has been TRUE ever since.

* The hdlin_keep_feedback variable does not seem to affect the choice
  of which type of flop to use for Xilinx parts. This should not be a
  concern.

* Style (4), above, uses an explicit hand-written multiplexer equation
  which is external to the flip-flop code. This wil ALWAYS cause
  Synopsys to generate a flip-flop with an external multiplexer, and
  NOT use the dedicated clock enable flip-flop.

* When FALSE, the hdlin_keep_inv_feedback variable will ALWAYS cause
  Synopsys to generate a flip-flop with a dedicated clock enable for
  cases (1-3).

* When TRUE (the default), the hdlin_keep_inv_feedback variable causes
  Synopsys to generate circuits which are dependent on both your design
  and your coding style :

  -- If the register (q, in the examples above) is a single-bit
     entity, Synopsys will generate a flip-flop with a dedicated
     clock enable using styles (1-3). As stated, an external multiplexer
     will be always be generated for example (4).

  -- If the register instead is a multi-bit bus (or vector), the
     synthesis results depend on how the code is written. Example (1)
     will generate a set of flip-flops with dedicated clock enable (CE)
     pins. Examples (2) and (3) will will generate simple flip-flops
     with a multiplexer driving the D input.

     Basically, if you include the "else --> q gets q" clause in
     the code, Synopsys interprets this (correctly) as a mux, and will
     generate the multiplexer externally using feedback from the
     flip-flop. If you don't, it will use flip-flops with dedicated
     clock enables.

Summary
-------

+==========+============++=====+=====+=====+=====+
| Variable | reg size	|| (1) | (2) | (3) | (4) |
+==========+============++=====+=====+=====+=====+
| False    | single-bit || CE  | CE  | CE  | MUX |
+----------+------------++-----+-----+-----+-----+
| False    | multi-bit	|| CE  | CE  | CE  | MUX |
+----------+------------++-----+-----+-----+-----+
| True	   | single-bit || CE  | CE  | CE  | MUX |
+----------+------------++-----+-----+-----+-----+
| True	   | multi-bit	|| CE  | MUX | MUX | MUX |
+----------+------------++-----+-----+-----+-----+

CE  = dedicated clock enable synthesized
MUX = external multiplexer synthesized

Which is better? That depends upon your application. Using flip-flops
with the dedicated clock enables is most efficient for highest speed
and minimal area. The external multiplexer uses three inputs to a LUT
to generate the mux. In a fan-in limited architecture, this wastes
resources and causes an additional LUT delay for most paths.

Alternatively, there are times when it may be better to use an external
multiplexer instead of the dedicated Clock Enable (CE) for placement
reasons. Each flip-flop in a Xilinx SRAM-based Configurable Logic Block
(CLB) shares a common dedicated CE signal. There is no physical way to
place two flip-flops with different clock enables in the same CLB. If
your design has many unique dedicated clock enables, placement problems
can sometimes occur. Once a flip-flop with a dedicated CE is placed in
a CLB, no other flip-flop with a dedicated CE can be placed there.
This phenomenon is more prevalent with the XC5200 family where there
are four flip-flops per CLB, than in the XC4000E family which has only
two flip-flops per CLB. Flip-flops which do not use the dedicated CE
lines have no such restrictions.

This typically only happens with control logic. Datapath flip-flops are
usually not a problem since large busses often share a common clock
enable. One exception to this might be a command register with individual
write-enables for each bit implemented as clock enables.

A similar placement problem can occur between flip-flops with different
clock or asynchronous control signals, since these inputs are also common
to each flip-flop in a CLB. Most designs do not have enough unique clocks
or resets to make this a problem, but be aware that it can happen.

In summary, use this information to when coding flip-flops that have
clock enables to your advantage. Coding for the dedicated clock enable
resource in Xilinx FPGAs will usually give you a smaller, faster design.
But also be aware of the possible adverse consequences.




End of Record #1019

For the latest news, design tips, and patch information on the Xilinx design environment, check out the Xilinx Expert Journals!

© 1998 Xilinx, Inc. All rights reserved
Trademarks and Patents