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 D Flip-flops” section of this chapter.

Reporting Register Inference

Foundation Express generates an inference report for inferred devices.

Foundation Express generates a general inference report when building a design and also supplies 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. The inference report appears on the Messages page of the output window for a pre-optimized chip.

Example 6-1: Inference Report for JK Flip-flop


   =========================================================================
   | Register Name | Type | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg | Flip-flop |   1   |  -  | N  | N  | Y  | Y  | Y  |
   =========================================================================


   Q_reg
   -----
      Sync-reset: J' K
      Sync-set: J K'
      Sync-toggle: J K
      Sync-set and Sync-reset ==> Q: X

The inference report in the above example consists of two sections - the first section contains tables of the inferenced registers and three-state devices, and the second section reports detailed register behavior. The 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 signals that control the synchronous reset and set conditions. In this example (Inference Report for JK Flip-Flop), register Q_reg synchronously resets 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 the output value is undefined

The “Inferring Latches” section and “Inferring D Flip-flops” section provide inference reports for each register template.

Foundation Express generates a warning message when it infers a latch. Foundation Express sends the warning in case the designer intended to describe combinatorial logic in a process but, instead, has inferred latches by not assigning a value to a signal in all cases in the process.The warning message is useful for verifying that a combinatorial design does not contain latches.

Controlling Register Inference

Direct Foundation Express to the type of sequential device you want to infer by using Foundation Express compiler directives, which give you control over individual signals.

Foundation Express provides the following compiler directives for controlling register inference.

async_set_reset

When a signal has this directive set to TRUE, Foundation Express looks for a branch that uses the signal as a condition. Foundation Express then checks to see whether the branch contains an assignment to a constant value. If so, 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”

The one_cold and one_hot directives cannot be used for FSM state vector encoding. For information about controlling state vector encoding, see “How to Specify Finite State Machines” in the Foundation Express online help.

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

If the target technology does not contain latches of the proper type, optimization may not complete, or it may build combinatorial feedback circuits to achieve the desired functionality.

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). Foundation Express does not ensure that the logic driving the inputs is hazard-free.

The example of a SR latch below provides the Verilog code that implements the SR latch 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 synthesis_on and synthesis_off directives around the check. See the “Foundation Express Compiler Directives” chapter for more information. The example of a SR Latch includes the check and the synthesis_on and synthesis_off directives. The inference report for an SR latch shows the inference report generated by Foundation Express.

Table 6_1 SR Latch Truth Table (Nand Type)

set	reset	y
0	0	Not stable
0	1	1
1	0	0
1	1	y

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 example below shows an inference report for an SR latch.


   ========================================================================= 
   |   Register Name   |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   |       Q_reg       |   Latch   |   1   |  -  | Y  | Y  | -  | -  | -  |
   =========================================================================


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

Simple D Latch

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 generates the verbose inference report shown in the inference report 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 example below shows an inference report for a D latch.


   =========================================================================
   |      Register Name |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   |          Q_reg |   Latch   |   1   |  -  | N  | N  | -  | -  | -  |
   =========================================================================


   Q_reg
   -----
      reset/set: none

Figure 6.2 D Latch

D Latch with Asynchronous Set or Reset

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 shows the Verilog template for a D latch with an asynchronous set. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   | Register Name | Type | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg |   Latch   |   1   |  -  | N  | Y  | -  | -  | -  |
   =========================================================================


   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 shows the Verilog template for a D latch with an asynchronous reset. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   | Register Name | Type | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg |   Latch   |   1   |  -  | Y  | N  | -  | -  | -  |
   =========================================================================


   Q_reg
   -----
      Async-reset: RESET'

Figure 6.4 D Latch with Asynchronous Reset

D Latch with Asynchronous Set and Reset

The following example shows 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 is used as the condition for the if clause. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   | Register Name       |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg           |   Latch   |   1   |  -  | Y  | Y  | -  | -  | -  |
   =========================================================================


   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

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_expression)
   begin
      assignment statements
   end

Simple D Flip-flop

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 inferring a simple D flip-flop, the always block can contain only one edge expression.

The following example shows the Verilog template for a positive-edge-triggered D flip-flop. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   |      Register Name |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg           | Flip-flop |   1   |  -  | N  | N  | N  | N  | N  |
   =========================================================================


   Q_reg
   -----
      set/reset/toggle: none

Figure 6.6 Positive-Edge-Triggered D Flip-flop

The following example shows the Verilog template for a negative-edge-triggered D flip-flop. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   |      Register Name |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   |          Q_reg | Flip-flop |   1   |  -  | N  | N  | N  | N  | N  |
   =========================================================================


   Q_reg
   -----
      set/reset/toggle: none

Figure 6.7 Negative-Edge-Triggered D Flip-flop

D Flip-flop with Asynchronous Set or Reset

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 shows the Verilog template for a D flip-flop with an active-low asynchronous set. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   | Register Name       |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   |          Q_reg | Flip-flop |   1   |  -  | N  | Y  | N  | N  | N  |
   =========================================================================


   Q_reg
   -----
      Async-set: SET'

Figure 6.8 D Flip-flop with Asynchronous Set

The following example shows the Verilog template for a D flip-flop with an active-high asynchronous reset. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   |      Register Name |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg           | Flip-flop |   1   |  -  | Y  | N  | N  | N  | N  |
   =========================================================================


   Q_reg
   -----
      Async-reset: RESET

Figure 6.9 D Flip-flop with Asynchronous Reset

D Flip-flop with Asynchronous Set and Reset

The following example shows 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 verbose 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.

   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.


   =========================================================================
   | Register Name       |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg           | Flip-flop |   1   |  -  | Y  | Y  | N  | N  | N  |
   =========================================================================


   Q_reg
   -----
      Async-reset: RESET
      Async-set: SET
      Async-set and Async-reset ==> Q: X

Figure 6.10 D Flip-flop with Asynchronous Set and Reset

D Flip-flop with Synchronous Set or 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 shows the Verilog template for a D flip-flop with synchronous set. Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   |      Register Name |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   |          Q_reg | Flip-flop |   1   |  -  | N  | N  | N  | Y  | N  |
   =========================================================================


   Q_reg
   -----
      Sync-set: SET

Figure 6.11 D Flip-flop with Synchronous Set

The following example shows the Verilog template for a D flip-flop with synchronous reset. Foundation Express generates the verbose inference report shown in the example of an inference report 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.


   =========================================================================
   | Register Name       |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg           | Flip-flop |   1   |  -  | N  | N  | Y  | N  | N  |
   =========================================================================

   Q_reg
   -----
      Sync-reset: RESET'

Figure 6.12 D Flip-flop with Synchronous Reset

D Flip-flop with Synchronous and Asynchronous Load

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 shows the Verilog template for a D flip-flop with synchronous load (called SLOAD) and an asynchronous load (called ALOAD). Foundation Express generates the verbose inference report shown in the inference report 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.


   =========================================================================
   | Register Name       |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q_reg           | Flip-flop |   1   |  -  | N  | N  | N  | N  | N  |
   =========================================================================


   Q_reg
   -----
      set/reset/toggle: none

Figure 6.13 D Flip-flop with Synchronous and Asynchronous Load

Multiple Flip-flops with Asynchronous and Synchronous Controls

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


   =========================================================================
   | Register Name       |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   | Q1_reg          | Flip-flop |   1   |  -  | N  | N  | Y  | N  | N  |
   =========================================================================


   Q1_reg
   ------
      Sync-reset: RESET'


   =========================================================================
   |      Register Name |   Type    | Width | Bus | AR | AS | SR | SS | ST |
   =========================================================================
   |          Q2_reg | Flip-flop |   1   |  -  | Y  | N  | N  | N  | N  |
   =========================================================================


   Q2_reg
   ------
      Async-reset: RESET'

Figure 6.14 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, you 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)

Describe all sequential functionality in an always block. If you haven't described a flip-flop in an always block, you will get the above error message.

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

It might not be necessary to register all variables in the block. 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 the other assignments in the other always block. This technique is used for creating 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 when describing finite-state machines.

Correlating with Simulation Results

Using delay specifications with registered values can cause the simulation to behave differently from the logic synthesized by Foundation Express. 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 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.