Register Inference

By inferring registers, you can use sequential logic in your designs and keep your designs technology-independent. A register is a simple, one-bit memory device, either a latch or a flip-flop. A latch is a level-sensitive memory device. A flip-flop is an edge-triggered memory device.

Foundation Express' capability to infer registers supports coding styles other than those described in this chapter. However, for best results, do the following.

• Restrict each always block to a single type of memory-element inferencing: latch, latch with asynchronous set or reset, flip-flop, flip-flop with asynchronous reset, or flip-flop with synchronous reset.
  
  
• Use the templates provided in the “Inferring Latches” section and “Inferring Flip-Flops” section of this chapter.
  
  

The Inference Report

Foundation Express generates a general inference report when building a design. It provides the asynchronous set or reset, synchronous set or reset, and synchronous toggle conditions of each latch or flip-flop, expressed in Boolean formulas. The following example shows the inference report for a JK flip-flop.

Q_reg

   Sync-reset: J' K

   Sync-set: J K'

   Sync-toggle: J K

   Sync-set and Sync-reset ==> Q: X

The inference report shows the following.

• Y indicates that the flip-flop has a synchronous reset (SR) and a synchronous set (SS).
  
  
• N indicates that the flip-flop does not have an asynchronous reset (AR), an asynchronous set (AS), or a synchronous toggle (ST).
  
  

In the inference report, the last section of the report lists the objects that control the synchronous reset and set conditions. In the above example, a synchronous reset occurs when J is low (logic 0) and K is high (logic 1). The last line of the report indicates the register output value when both the set and reset are active.

• zero (0) - Indicates that the reset has priority and the output goes to logic 0
  
  
• one (1) - Indicates that the set has priority and the output goes to logic 1
  
  
• X - Indicates that there is no priority and that the output value is unstable
  
  

The “Inferring Latches” section and “Inferring Flip-Flops” section of this chapter provide inference reports for each register template. After you input a Verilog description, check the inference report to verify the information.

Latch Inference Warnings

Foundation Express generates a warning message when it infers a latch. The warning message is useful to verify that a combinatorial design does not contain memory components.

Controlling Register Inference

Use directives to direct the type of sequential device you want inferred. The default is to implement the type of latch described in the HDL code. These attributes override this behavior.

Foundation Express provides the following directives for controlling register inference.

• async_set_reset
  
  When a signal has this directive set to TRUE, Foundation Express searches for a branch that uses the signal as a condition. Foundation Express then checks whether the branch contains an assignment to a constant value. If the branch does, the signal becomes an asynchronous reset or set.
  
  Attach the async_set_reset directive to single-bit signals using the following syntax.
  
  

  // synopsys async_set_reset ”signal_name_list”

  
  
  
• async_set_reset_local
  
  Foundation Express treats listed signals in the specified block as if they have the async_set_reset directive set to TRUE.
  
  Attach the async_set_reset_local directive to a block label using the following syntax.
  
  

  /* synopsys async_set_reset_local block_label ”signal_name_list” */

  
  
  
• async_set_reset_local_all
  
  Foundation Express treats all signals in the specified blocks as if they have the async_set_reset directive set to TRUE.
  
  Attach the async_set_reset_local_all directive to block labels using the following syntax.
  
  

  /* synopsys async_set_reset_local_all “block_label_list” */

  
  
  
• sync_set_reset
  
  When a signal has this directive set to TRUE, Foundation Express checks the signal to determine whether it synchronously sets or resets a register in the design.
  
  Attach the sync_set_reset directive to single-bit signals using the following syntax.
  
  

  //synopsys sync_set_reset ”signal_name_list”

  
  
  
• sync_set_reset_local
  
  Foundation Express treats listed signals in the specified block as if they have the sync_set_reset directive set to TRUE.
  
  Attach the sync_set_reset_local directive to a block label using the following syntax.
  
  

  /* synopsys sync_set_reset_local block_label ”signal_name_list” */

  
  
  
• sync_set_reset_local_all
  
  Foundation Express treats all signals in the specified blocks as if they have the sync_set_reset directive set to TRUE.
  
  Attach the sync_set_reset_local_all directive to block labels using the following syntax.
  
  

  /* synopsys sync_set_reset_local_all ”block_label_list” */

  
  
  
• one_cold
  
  A one-cold implementation means that all signals in a group are active low and that only one signal can be active at a given time. The one_cold directive prevents Foundation Express from implementing priority encoding logic for the set and reset signals.
  
  Add a check to the Verilog code to ensure that the group of signals has a one-cold implementation. Foundation Express does not produce any logic to check this assertion.
  
  Attach the one_cold directive to set or reset signals on sequential devices using the following syntax.
  
  

  // synopsys one_cold ”signal_name_list”

  
  
  
• one_hot
  
  

A one-hot implementation means that all signals in a group are active-high and that only one signal can be active at a given time. The one_cold directive prevents Foundation Express from implementing priority encoding logic for the set and reset signals.

Add a check to the Verilog code to ensure that the group of signals has a one-hot implementation. Foundation Express does not produce any logic to check this assertion.

Attach the one_hot directive to set or reset signals on sequential devices using the following syntax.

// synopsys one_hot ”signal_name_list”

Inferring Latches

In simulation, a signal or variable holds its value until that output is reassigned. In hardware, a latch implements this holding-of-state capability. Foundation Express supports inference of the following types of latches.

• SR latch
  
  
• D latch
  
  
• Master-slave latch
  
  

The following sections provide details about each of these latch types.

Inferring SR Latches

Use SR latches with caution, because they are difficult to test. If you decide to use SR latches, you must verify that the inputs are hazard-free (do not glitch). During synthesis, Foundation Express does not ensure that the logic driving the inputs is hazard-free.

The example of a SR latch below shows the Verilog code that implements the inferred SR latch shown in the following figure and described in the “SR Latch Truth Table (Nand Type).” Because the output y is unstable when both inputs have a logic 0 value, include a check in the Verilog code to detect this condition during simulation.

Synthesis does not support such checks, so you must put the translate_on and translate_off directives around the check. See the “translate_off and translate_on Directives” section of the “Foundation Express Directives” chapter for more information about special comments in the Verilog source code. The inference report for an SR latch shows the inference report that Foundation Express generates.

The following example shows an SR latch.

module sr_latch (SET, RESET, Q);

   input SET, RESET;

   output Q;

   reg Q;

//synopsys async_set_reset ”SET, RESET”

always @(RESET or SET)

   if (~RESET)

      Q = 0;

   else if (~SET)

      Q = 1;

endmodule

The following example shows an inference report for an SR latch.

y_reg

   Async-reset: RESET'

   Async-set: SET'

   Async-set and Async-reset ==> Q: 1

Figure 6.1 SR Latch

Inferring D Latches

When you do not specify the resulting value for a signal under all conditions, as in an incompletely specified if or case statement, Foundation Express infers a D latch.

For example, the if statement in the following example infers a D latch because there is no else clause. The Verilog code specifies a value for output Q only when input GATE has a logic 1 value. As a result, output Q becomes a latched value.

always @ (DATA or GATE) begin

   if (GATE) begin

      Q = DATA;

   end

end

The case statement in the following example infers D latches, because the case statement does not provide assignments to decimal for values of I between 10 and 15.

always @(I) begin

   case(I)

      4'h0: decimal= 10'b0000000001;

      4'h1: decimal= 10'b0000000010;

      4'h2: decimal= 10'b0000000100;

      4'h3: decimal= 10'b0000001000;

      4'h4: decimal= 10'b0000010000;

      4'h5: decimal= 10'b0000100000;

      4'h6: decimal= 10'b0001000000;

      4'h7: decimal= 10'b0010000000;

      4'h8: decimal= 10'b0100000000;

      4'h9: decimal= 10'b1000000000;

   endcase

end

To avoid latch inference, assign a value to the signal under all conditions. To avoid latch inference by the if statement in the above example, modify the block as shown in the following examples. To avoid latch inference by the case statement in the above example, add the following statement before the endcase statement.

default: decimal= 10'b0000000000;

The following example shows how to avoid latch inference.

always @ (DATA, GATE) begin

   Q = 0;

   if (GATE) 

      Q = DATA;

end

The following example shows another way to avoid latch inference.

always @ (DATA, GATE) begin

   if (GATE) 

      Q = DATA;

   else 

      Q = 0;

end

Variables declared locally within a subprogram do not hold their value over time, because every time a subprogram is called, its variables are reinitialized. Therefore, Foundation Express does not infer latches for variables declared in subprograms. In the following example, Foundation Express does not infer a latch for output Q.

function MY_FUNC

   input DATA, GATE;

   reg STATE;

   begin

      if (GATE) begin

         STATE = DATA;

      end

      MY_FUNC = STATE;

   end

end function

. . .

Q = MY_FUNC(DATA, GATE);

The following sections provide truth tables, code examples, and figures for these types of D latches.

• Simple D latch
  
  
• D latch with asynchronous set or reset
  
  
• D latch with asynchronous set and reset
  
  

When you infer a D latch, control the gate and data signals from the top-level design ports or through combinatorial logic. Gate and data signals that can be controlled ensure that simulation can initialize the design.

The following example provides the Verilog template for a D latch. Foundation Express generates the inference report shown following the example for a D latch. The figure “D Latch” shows the inferred latch.

module d_latch (GATE, DATA, Q);

   input GATE, DATA;

   output Q;

   reg Q;

always @(GATE or DATA)

   if (GATE)

      Q = DATA;

endmodule

The following example shows an inference report for a D latch.

Q_reg

   reset/set:none

Figure 6.2 D Latch

The templates in this section use the async_set_reset directive to direct Foundation Express to the asynchronous set or reset pins of the inferred latch.

The following example provides the Verilog template for a D latch with an asynchronous set. Foundation Express generates the inference report shown following the example for a D latch with asynchronous set. The figure “D Latch with Asynchronous Set” shows the inferred latch.

module d_latch_async_set (GATE, DATA, SET, Q);

   input GATE, DATA, SET;

   output Q;

   reg Q;

//synopsys async_set_reset ”SET”

always @(GATE or DATA or SET)

   if (~SET)

      Q = 1'b1;

   else if (GATE)

      Q = DATA;

endmodule

The following example shows an inference report for a D latch with asynchronous set.

Q_reg

   Async-set: SET'

Figure 6.3 Latch with Asynchronous Set

Note: When the target technology library does not contain a latch with an asynchronous set, Foundation Express synthesizes the set logic using combinatorial logic.

The following example provides the Verilog template for a D latch with an asynchronous reset. Foundation Express generates the inference report shown following the example for a D latch with asynchronous reset. The figure “D Latch with Asynchronous Reset” shows the inferred latch.

module d_latch_async_reset (RESET, GATE, DATA, Q);

   input RESET, GATE, DATA;

   output Q;

   reg Q;

//synopsys async_set_reset ”RESET”

always @ (RESET or GATE or DATA)

   if (~RESET) 

      Q = 1'b0;

   else if (GATE) 

      Q = DATA;

endmodule 

The following example shows an inference report for a D latch with asynchronous reset.

Q_reg

   Async-reset: RESET'

Figure 6.4 D Latch with Asynchronous Reset

The following example provides the Verilog template for a D latch with an active-low asynchronous set and reset. This template uses the async_set_reset_local directive to direct Foundation Express to the asynchronous signals in block infer and uses the one_cold directive to prevent priority encoding of the set and reset signals. For this template, if you do not specify the one_cold directive, the set signal has priority, because it serves as the condition for the if clause. Foundation Express generates the inference report shown following the example for a D latch with asynchronous set and reset. The figure “D Latch with Asynchronous Set and Reset” shows the inferred latch.

module d_latch_async (GATE, DATA, RESET, SET, Q);

   input GATE, DATA, RESET, SET;

   output Q;

   reg Q;

// synopsys async_set_reset_local infer ”RESET, SET”

// synopsys one_cold ”RESET, SET”

always @ (GATE or DATA or RESET or SET)

begin : infer

   if (!SET) 

      Q = 1'b1;

   else if (!RESET)

      Q = 1'b0;

   else if (GATE) 

      Q = DATA;

end

// synopsys translate_off

always @ (RESET or SET)

   if (RESET == 1'b0 & SET == 1'b0)

   $write (”ONE-COLD violation for RESET and SET.”);

// synopsys translate_on

endmodule 

The following example shows an inference report for a D latch with asynchronous set and reset.

Q_reg

   Async-reset: RESET'

   Async-set: SET'

   Async-set and Async-reset ==> Q: X

Figure 6.5 D Latch with Asynchronous Set and Reset

Understanding the Limitations of D Latch Inference

A variable must always have a value before it is read. As a result, a conditionally assigned variable cannot be read after the if statement in which it is assigned. A conditionally assigned variable is assigned a new value under some, but not all, conditions. The following example shows an invalid use of the conditionally assigned variable VALUE.

begin

   if (condition) then

      VALUE <= X;

   Y <= VALUE; // Invalid read of variable VALUE

end

Inferring Master-Slave Latches

You can infer two-phase systems by using D latches. The following example shows a simple two-phase system with clocks MCK and SCK. The figure “Two-Phase Clocks” shows the inferred latches.

module latch_verilog (DATA, MCK, SCK, Q);

   input DATA, MCK, SCK;

   output Q;

   reg Q;

   reg TEMP;

always @(DATA or MCK)

   if (MCK) 

      TEMP = DATA;

always @(TEMP or SCK)

   if (SCK)

      Q = TEMP;

endmodule

Figure 6.6 Two-Phase Clocks

Inferring Flip-Flops

Foundation Express can infer D flip-flops, JK flip-flops, and toggle flip-flops. The following sections provide details about each of these flip-flop types.

Many FPGA devices have a dedicated set/reset hardware resource that should be used. For this reason, you should infer asynchronous set/reset signals for all flip-flops in the design. Foundation Express will then use the global set/reset lines.

Inferring D Flip-Flops

Foundation Express infers a D flip-flop whenever the sensitivity list of an always block includes an edge expression (a test for the rising or falling edge of a signal). Use the following syntax to describe a rising edge.

posedge SIGNAL

Use the following syntax to describe a falling edge.

negedge SIGNAL

When the sensitivity list of an always block contains an edge expression, Foundation Express creates flip-flops for all variables assigned values in the block. The following example shows the most common way of using an always block to infer a flip-flop.

always @(edge)

begin

   .

end

When you infer a D flip-flop, control the clock and data signals from the top-level design ports or through combinatorial logic. Clock and data signals that can be controlled ensure that simulation can initialize the design. If you cannot control the clock and data signals, infer a D flip-flop with asynchronous reset or set or with a synchronous reset or set.

When you are inferring a simple D flip-flop, the always block can contain only one edge expression.

The following example provides the Verilog template for a positive edge-triggered D flip-flop. Foundation Express generates the inference report shown following the example for a positive edge-triggered D flip-flop. The figure “Positive-Edge-Triggered D Flip-flop” shows the inferred flip-flop.

module dff_pos (DATA, CLK, Q);

   input DATA, CLK;

   output Q;

   reg Q;

always @(posedge CLK)

   Q = DATA;

endmodule

The following example shows an inference report for a positive edge-triggered D flip-flop.

Q_reg

   set/reset/toggle: none

Figure 6.7 Positive Edge-Triggered D Flip-Flop

The following example provides the Verilog template for a negative edge-triggered D flip-flop. Foundation Express generates the inference report shown following the example for a negative edge-triggered D flip-flop. The figure “Negative Edge-Triggered D Flip-Flop” shows the inferred flip-flop.

module dff_neg (DATA, CLK, Q);

   input DATA, CLK;

   output Q;

   reg Q;

always @(negedge CLK)

   Q = DATA;

endmodule

The following example shows an inference report for a negative edge-triggered D flip-flop.

Q_reg

   set/reset/toggle: none

Figure 6.8 Negative Edge-Triggered D Flip-Flop

When inferring a D flip-flop with an asynchronous set or reset, include edge expressions for the clock and the asynchronous signals in the sensitivity list of the always block. Specify the asynchronous conditions using if statements. Specify the branches for the asynchronous conditions before the branches for the synchronous conditions.

The following example provides the Verilog template for a D flip-flop with an asynchronous set. Foundation Express generates the inference report shown following the example for a D flip-flop with asynchronous set. The figure “D Flip-Flop with Asynchronous Set” shows the inferred flip-flop.

module dff_async_set (DATA, CLK, SET, Q);

   input DATA, CLK, SET;

   output Q;

   reg Q;

always @(posedge CLK or negedge SET)

   if (~SET)

      Q = 1'b1;

   else 

      Q = DATA;

endmodule

The following example shows an inference report for a D flip-flop with asynchronous set.

Q_reg

   Async-set: SET'

Figure 6.9 D Flip-Flop with Asynchronous Set

The following example provides the Verilog template for a D flip-flop with an asynchronous reset. Foundation Express generates the inference report shown following the example for a D flip-flop with asynchronous reset. The figure “D Flip-Flop with Asynchronous Reset” shows the inferred flip-flop.

module dff_async_reset (DATA, CLK, RESET, Q);

   input DATA, CLK, RESET;

   output Q;

   reg Q;

always @(posedge CLK or posedge RESET)

   if (RESET)

      Q = 1'b0;

   else

      Q = DATA;

endmodule

The following example shows an inference report for a D flip-flop with asynchronous reset.

Q_reg

   Async-reset: RESET

Figure 6.10 D Flip-Flop with Asynchronous Reset

The following example provides the Verilog template for a D flip-flop with active high asynchronous set and reset pins. The template uses the one_hot directive to prevent priority encoding of the set and reset signals. For this template, if you do not specify the one_hot directive, the reset signal has priority, because it is used as the condition for the if clause. Foundation Express generates the inference report shown in the inference report example for a D flip-flop with asynchronous set and reset. The figure “D Flip-Flop with Asynchronous Set and Reset” shows the inferred flip-flop.

Note: Most FPGA architectures do not have a register with an asynchronous set and asynchronous reset cell available. For this reason, avoid this construct.

module dff_async (RESET, SET, DATA, Q, CLK);

   input CLK;

   input RESET, SET, DATA;

   output Q;

   reg Q;

// synopsys one_hot ”RESET, SET”

always @(posedge CLK or posedge RESET or posedge SET)

   if (RESET)

      Q = 1'b0;

   else if (SET)

      Q = 1'b1;

   else Q = DATA;

// synopsys translate_off

always @ (RESET or SET)

   if (RESET + SET > 1)

   $write (”ONE-HOT violation for RESET and SET.”);

// synopsys translate_on

endmodule

The following example shows an inference report for a D flip-flop with asynchronous set and reset.

Q_reg

   Async-reset: RESET

   Async-set: SET

   Async-set and Async-reset ==> Q: X

Figure 6.11 D Flip-flop with Asynchronous Set and Reset

The previous examples illustrate how to infer a D flip-flop with asynchronous controls - one way to initialize or control the state of a sequential device. You can also synchronously reset or set the flip-flop (see the examples in this section). The sync_set_reset directive directs Foundation Express to the synchronous controls of the sequential device.

When the target technology library does not have a D flip-flop with synchronous reset, Foundation Express infers a D flip-flop with synchronous reset logic as the input to the D pin of the flip-flop. If the reset (or set) logic is not directly in front of the D pin of the flip-flop, initialization problems can occur during gate-level simulation of the design.

The following example provides the Verilog template for a D flip-flop with synchronous set. Foundation Express generates the inference report shown following the example for a D flip-flop with synchronous set. The figure “D Flip-Flop with Synchronous Set” shows the inferred flip-flop.

module dff_sync_set (DATA, CLK, SET, Q);

   input DATA, CLK, SET;

   output Q;

   reg Q;

//synopsys sync_set_reset ”SET”

always @(posedge CLK)

   if (SET)

      Q = 1'b1;

   else 

      Q = DATA;

endmodule

The following example shows an inference report for a D flip-flop with synchronous set.

Q_reg

   Sync-set: SET

Figure 6.12 D Flip-Flop with Synchronous Set

The following example provides the Verilog template for a D flip-flop with synchronous reset. Foundation Express generates the inference report shown following the example for a D flip-flop with synchronous reset. The figure “D Flip-Flop with Synchronous Reset” shows the inferred flip-flop.

module dff_sync_reset (DATA, CLK, RESET, Q);

   input DATA, CLK, RESET;

   output Q;

   reg Q;

//synopsys sync_set_reset ”RESET”

always @(posedge CLK)

   if (~RESET)

      Q = 1'b0;

   else 

      Q = DATA;

endmodule

The following example shows an inference report for a D flip-flop with synchronous reset.

Q_reg

   Sync-reset: RESET'

Figure 6.13 D Flip-Flop with Synchronous Reset

D flip-flops can have asynchronous or synchronous controls. To infer a component with both synchronous and asynchronous controls, you must check the asynchronous conditions before you check the synchronous conditions.

The following example provides the Verilog template for a D flip-flop with synchronous load (called SLOAD) and an asynchronous load (called ALOAD). Foundation Express generates the inference report shown following the example for a D flip-flop with synchronous and asynchronous load. The figure “D Flip-Flop with Synchronous and Asynchronous Load” shows the inferred flip-flop.

module dff_a_s_load (ALOAD, SLOAD, ADATA, SDATA, CLK, Q);

   input ALOAD, ADATA, SLOAD, SDATA, CLK;

   output Q;

   reg Q;

always @ (posedge CLK or posedge ALOAD)

   if (ALOAD)

      Q = ADATA;

   else if (SLOAD)

      Q = SDATA;

endmodule 

The following example shows an inference report for a D flip-flop with synchronous and asynchronous load.

Q_reg

   set/reset/toggle: none

Figure 6.14 D Flip-Flop with Synchronous and Asynchronous Load

If a signal is synchronous in one block but asynchronous in another block, use the sync_set_reset_local and async_set_reset_local directives to direct Foundation Express to the correct implementation.

In the following example, block infer_sync uses the reset signal as a synchronous reset, while block infer_async uses the reset signal as an asynchronous reset. Foundation Express generates the inference report shown in the inference reports example for multiple flip-flops with asynchronous and synchronous controls. The figure “Multiple Flip-flops with Asynchronous and Synchronous Controls” shows the resulting design.

module multi_attr (DATA1, DATA2, CLK, RESET, SLOAD, Q1, Q2);

   input DATA1, DATA2, CLK, RESET, SLOAD;

   output Q1, Q2;

   reg Q1, Q2;

//synopsys sync_set_reset_local infer_sync ”RESET”

always @(posedge CLK)

begin : infer_sync

   if (~RESET)

      Q1 = 1'b0;

   else if (SLOAD)

      Q1 = DATA1;   // note: else hold Q

end

//synopsys async_set_reset_local infer_async ”RESET”

always @(posedge CLK or negedge RESET)

begin: infer_async

   if (~RESET)

      Q2 = 1'b0;

   else if (SLOAD)

      Q2 = DATA2;

end

endmodule

The following example shows inference reports for multiple flip-flops with asynchronous and synchronous controls.

Q1_reg

   Sync-reset: RESET'

Q2_reg

   Async-reset: RESET'

Figure 6.15 Multiple Flip-Flops with Asynchronous and Synchronous Controls

Understanding the Limitations of D Flip-Flop Inference

If you use an if statement to infer D flip-flops, your design must meet the following requirements.

• The signal in an edge expression cannot be an indexed expression.
  
  The following always block is invalid because it uses an indexed expression.
  
  

  always @(posedge clk[1])

  
  
  Foundation Express generates the following message when you use an indexed expression in the always block.
  
  

  Error: In an event expression with 'posedge' and 'negedge' qualifiers, only simple identifiers are allowed %s. (VE-91)

  
  
  
• Set and reset conditions must be single-bit variables.
  
  The following reset condition is invalid because it uses a bused variable.
  
  

  always @(posedge clk and negedge reset_bus)
  
     if (!reset_bus[1])
  
     .
  
  end

  
  
  Foundation Express generates the following message when you use a bused variable in a set or reset condition.
  
  

  Error: The expression for the reset condition of the 'if' statement in this 'always' block can only be a simple identifier or its negation (%s). (VE-92)

  
  
  
• Set and reset conditions cannot use complex expressions.
  
  The following reset condition is invalid because it uses a complex expression.
  
  

  always @(posedge clk and negedge reset)
  
     if (reset == (1-1))
  
     .
  
  end

  
  
  Foundation Express generates the VE-92 message when you use a complex expression in a set or reset condition.
  
  
• An if statement must occur at the top level of the always block.
  
  The following example is invalid because the if statement does not occur at the top level.
  
  

  always @(posedge clk or posedge reset) begin
  
     #1;
  
     if (reset)
  
     .
  
  end

  
  
  Foundation Express generates the following message when the if statement does not occur at the top level.
  
  

  Error: The statements in this 'always' block are outside the scope of the synthesis policy (%s). Only an 'if' statement is allowed at the top level in this 'always' block. Please refer to the HDL Compiler reference manual for ways to infer flip-flops and latches from 'always' blocks. (VE-93)

  
  
  

Inferring JK Flip-Flops

When you infer a JK flip-flop, make sure you can control the J, K, and clock signals from the top-level design ports to ensure that simulation can initialize the design.The following sections provide code examples, inference reports, and figures for these types of JK flip-flops:

• JK flip-flop
  
  
• JK flip-flop with asynchronous set and reset
  
  

In the JK flip-flop, the J and K signals act as active-high synchronous set and reset. Use the sync_set_reset directive to indicate that the J and K signals are the synchronous set and reset for the design. The following table shows the inferred flip-flop..

Table 6_1 Truth Table for JK Flip-Flop

The following example provides the Verilog code that implements the JK flip-flop described in the ”Truth Table for JK Flip-Flop.”

module JK(J, K, CLK, Q);

   input J, K;

   input CLK;

   output Q;

   reg Q;

// synopsys sync_set_reset ”J, K”

always @ (posedge CLK)

   case ({J, K})

      2'b01 : Q = 0;

      2'b10 : Q = 1;

      2'b11 : Q = ~Q;

   endcase

endmodule 

The following example shows the inference report generated by Foundation Express for a JK flip-flop, and the figure following the report, “JK Flip-Flop,” shows the inferred flip-flop.

Q_reg

Sync-reset: J' K

Sync-set: J K'

Sync-toggle: J K

Sync-set and Sync-reset ==> Q: X

Figure 6.16 JK Flip-Flop

Use the sync_set_reset directive to indicate the JK function. Use the one_hot directive to prevent priority encoding of the J and K signals.

The following example provides the Verilog template for a JK flip-flop with asynchronous set and reset.

module jk_async_sr (RESET, SET, J, K, CLK, Q);

   input RESET, SET, J, K, CLK;

   output Q;

   reg Q;

// synopsys sync_set_reset ”J, K”

// synopsys one_hot ”RESET, SET”

always @ (posedge CLK or posedge RESET or posedge SET)

   if (RESET)

      Q = 1'b0;

   else if (SET)

      Q = 1'b1;

else

   case ({J, K})

      2'b01 : Q = 0;

      2'b10 : Q = 1;

      2'b11 : Q = ~Q;

   endcase

//synopsys translate_off

always @(RESET or SET)

   if (RESET + SET > 1)

      $write (”ONE-HOT violation for RESET and       SET.”);

// synopsys translate_on

endmodule

The following table shows the inference report Foundation Express generates for a JK flip-flop with asynchronous set and reset, and the figure following the report, “JK Flip-Flop with Asynchronous Set and Reset,” shows the inferred flip-flop.

Q_reg

    Async-reset: RESET

    Async-set: SET

    Sync-reset: J' K

    Sync-set: J K'

    Sync-toggle: J K

    Async-set and Async-reset ==> Q: X

    Sync-set and Sync-reset ==> Q: X

Figure 6.17 JK Flip-Flop with Asynchronous Set and Reset

Inferring Toggle Flip-Flops

To infer toggle flip-flops, follow the coding style in the following examples.

You must include asynchronous controls in the toggle flip-flop description. Without them, you cannot initialize toggle flip-flops to a known state.

This section describes toggle flip-flops with an asynchronous set or reset and toggle flip-flops with an enable and an asynchronous reset.

The following example shows the template for a toggle flip-flop with asynchronous set. Foundation Express generates the inference report shown following the example, and the figure “Toggle Flip-Flop with Asynchronous Set” shows the flip-flop.

module t_async_set (SET, CLK, Q);

   input SET, CLK;

   reg Q;

always @ (posedge CLK or posedge SET)

   if (SET)

      Q = 1;

   else 

      Q = ~Q;

endmodule

TMP_Q_reg

Async-set: SET

Sync-toggle: true

Figure 6.18 Toggle Flip-Flop with Asynchronous Set

The following example provides the Verilog template for a toggle flip-flop with asynchronous reset. The table following the example shows the inference report, and the figure following the report, “Toggle Flip-Flop with Asynchronous Reset,” shows the inferred flip-flop.

module t_async_reset (RESET, CLK, Q);

   input RESET, CLK;

   output Q;

   reg Q;

always @ (posedge CLK or posedge RESET)

   if (RESET) 

      Q = 0;

   else 

      Q = ~Q;

endmodule

TMP_Q_reg

Async-reset: RESET

    Sync-toggle: true

Figure 6.19 Toggle Flip-Flop with Asynchronous Reset

The following example provides the Verilog template for a toggle flip-flop with an enable and an asynchronous reset. The flip-flop toggles only when the enable (TOGGLE signal) has a logic 1 value.

Foundation Express generates the inference report shown following the example, and the figure following the report, “Toggle Flip-Flop with Enable and Asynchronous Reset,” shows the inferred flip-flop.

module t_async_en_r (RESET, TOGGLE, CLK, Q);

   input RESET, TOGGLE, CLK;

   output Q;

   reg Q;

always @ (posedge CLK or posedge RESET)

begin : infer

   if (RESET) 

      Q = 0;

   else if (TOGGLE)

      Q = ~Q;

end 

endmodule

TMP_Q_reg

Async-reset: RESET

Sync-toggle: TOGGLE

Figure 6.20 Toggle Flip-Flop with Enable and Asynchronous Reset

Getting the Best Results

This section provides tips for improving the results you achieve during flip-flop inference. The following topics are covered.

• Minimizing flip-flop count
  
  
• Correlating synthesis results with simulation results
  
  

Minimizing Flip-Flop Count

An always block that contains a clock edge in the sensitivity list causes Foundation Express to infer a flip-flop for each variable assigned a value in that block. Make sure your HDL description builds only as many flip-flops as the design requires.

The description in the following example builds six flip-flops, one for each variable assigned a value in the block (COUNT(2:0), AND_BITS, OR_BITS, and XOR_BITS).

module count (CLK, RESET, AND_BITS, OR_BITS, XOR_BITS);

   input CLK, RESET;

   output AND_BITS, OR_BITS, XOR_BITS;

   reg AND_BITS, OR_BITS, XOR_BITS;

   reg [2:0] COUNT;

always @(posedge CLK) begin

   if (RESET)

      COUNT = 0;

   else

      COUNT = COUNT + 1;

   AND_BITS = & COUNT;

   OR_BITS = | COUNT;

   XOR_BITS = ^ COUNT;

end

endmodule

In the above design, the outputs AND_BITS, OR_BITS, and XOR_BITS depend solely on the value of variable COUNT. If the variable COUNT is registered, these three outputs do not need to be registered.

To compute values synchronously and store them in flip-flops, set up an always block with a signal edge trigger. To let other values change asynchronously, make a separate always block with no signal edge trigger. Put the assignments you want clocked in the always block with the signal edge trigger, and put the other assignments in the other always block. You use this technique to create Mealy machines.

To avoid inferring extra registers, assign the outputs in an always block that does not have a clock edge in its condition expression. The following example shows a description with two always blocks, one with a clock edge condition and one without. Put the registered (synchronous) assignments into the block with the clock edge condition. Put the other (asynchronous) assignments in the other block. This description style lets you choose the variables that are registered and those that are not.

module count (CLK, RESET, AND_BITS, OR_BITS, XOR_BITS);

   input CLK, RESET;

   output AND_BITS, OR_BITS, XOR_BITS;

   reg AND_BITS, OR_BITS, XOR_BITS;

   reg [2:0] COUNT;

//synchronous block

always @(posedge CLK) begin

   if (RESET)

      COUNT = 0;

   else

      COUNT = COUNT + 1;

end

//asynchronous block

always @(COUNT) begin

   AND_BITS = & COUNT;

   OR_BITS = | COUNT;

   XOR_BITS = ^ COUNT;

end

endmodule

The technique of separating combinatorial logic from registered or sequential logic is useful to describe state machines. See the following examples in Appendix A.

• “Count Zeros - Combinatorial Version”
  
  
• “Count Zeros - Sequential Version”
  
  
• “Drink Machine - State Machine Version”
  
  
• “Drink Machine - Count Nickels Version”
  
  
• “Carry-Lookahead Adder”
  
  

Correlating with Simulation Results

Using delay specifications with registered values can cause the simulation to behave differently from the logic Foundation Express synthesizes. For example, the description in the following example contains delay information that causes Foundation Express to synthesize a circuit that behaves unexpectedly (the post-synthesis simulation results do not match the pre-synthesis simulation results).

module flip_flop (D, CLK, Q);

   input D, CLK;

   output Q;

   .

endmodule

module top (A, C, D, CLK);

   .

   reg B;

always @ (A or C or D or CLK)

begin

   B <= #100 A;

   flip_flop F1(A, CLK, C);

   flip_flop F2(B, CLK, D);

end

endmodule

In the above example, B changes 100 nanoseconds after A changes. If the clock period is less than 100 nanoseconds, output D is one or more clock cycles behind output C during simulation of the design. However, because Foundation Express ignores the delay information, A and B change values at the same time and so do C and D. This behavior is not the same as in the post-synthesis simulation.

When using delay information in your designs, make sure that the delays do not affect registered values. In general, you can safely include delay information in your description if it does not change the value that gets clocked into a flip-flop.

Understanding Limitations of Register Inference

Foundation Express cannot infer the following components. You must instantiate these components in your Verilog description.

• Flip-flops and latches with three-state outputs
  
  
• Flip-flops with bidirectional pins
  
  
• Flip-flips with multiple clock inputs
  
  
• Multiport latches
  
  
• Register banks
  
  

  Note: Although you can instantiate flip-flops with bidirectional pins, Foundation Express interprets these cells as black boxes.