Intel® Quartus® Prime Standard Edition User Guide: Design Recommendations

ID 683323
Date 9/24/2018
Public
Download
Document Table of Contents
Document Table of Contents
1. Recommended Design Practices 2. Recommended HDL Coding Styles 3. Managing Metastability with the Intel® Quartus® Prime Software A. Intel® Quartus® Prime Standard Edition User Guides
1. Recommended Design Practices
1.1. Following Synchronous FPGA Design Practices 1.2. HDL Design Guidelines 1.3. Checking Design Violations 1.4. Use Clock and Register-Control Architectural Features 1.5. Implementing Embedded RAM 1.6. Recommended Design Practices Revision History
1.1. Following Synchronous FPGA Design Practices
1.1.1. Implementing Synchronous Designs 1.1.2. Asynchronous Design Hazards
1.2. HDL Design Guidelines
1.2.1. Optimizing Combinational Logic 1.2.2. Optimizing Clocking Schemes 1.2.3. Optimizing Physical Implementation and Timing Closure 1.2.4. Optimizing Power Consumption 1.2.5. Managing Design Metastability
1.2.1. Optimizing Combinational Logic
1.2.1.1. Avoid Combinational Loops 1.2.1.2. Avoid Unintended Latch Inference 1.2.1.3. Avoid Delay Chains in Clock Paths 1.2.1.4. Use Synchronous Pulse Generators
1.2.2. Optimizing Clocking Schemes
1.2.2.1. Register Combinational Logic Outputs 1.2.2.2. Avoid Asynchronous Clock Division 1.2.2.3. Avoid Ripple Counters 1.2.2.4. Use Multiplexed Clocks 1.2.2.5. Use Gated Clocks 1.2.2.6. Use Synchronous Clock Enables
1.2.2.5. Use Gated Clocks
1.2.2.5.1. Recommended Clock-Gating Methods
1.2.3. Optimizing Physical Implementation and Timing Closure
1.2.3.1. Planning Physical Implementation 1.2.3.2. Planning FPGA Resources 1.2.3.3. Optimizing for Timing Closure 1.2.3.4. Optimizing Critical Timing Paths
1.3. Checking Design Violations
1.3.1. Validating Against Design Rules 1.3.2. Creating Custom Design Rules
1.3.2. Creating Custom Design Rules
1.3.2.1. Custom Design Rule Examples Detecting SR Latches in a Design=mwh1409959543887__example_B9BD88AB882B4EFEA0F65A288721FA9A Detecting Incorrect Synchronizer Configuration=mwh1409959543887__example_81F95DD16A7644C98803158EC697B327 Undesired Condition 3=mwh1409959543887__example_4056AFBC84904B0690EF48007CB3CFFC Undesired Condition 4=mwh1409959543887__example_389E307FC60149A894C72B4CEF9C94F0
1.4. Use Clock and Register-Control Architectural Features
1.4.1. Use Global Reset Resources 1.4.2. Use Global Clock Network Resources 1.4.3. Use Clock Region Assignments to Optimize Clock Constraints 1.4.4. Avoid Asynchronous Register Control Signals
1.4.1. Use Global Reset Resources
1.4.1.1. Use Synchronous Resets 1.4.1.2. Using Asynchronous Resets 1.4.1.3. Use Synchronized Asynchronous Reset
1.4.3. Use Clock Region Assignments to Optimize Clock Constraints
1.4.3.1. Clock Region Assignments in Intel® Arria® 10 and Older Device Families
2. Recommended HDL Coding Styles
2.1. Using Provided HDL Templates 2.2. Instantiating IP Cores in HDL 2.3. Inferring Multipliers and DSP Functions 2.4. Inferring Memory Functions from HDL Code 2.5. Register and Latch Coding Guidelines 2.6. General Coding Guidelines 2.7. Designing with Low-Level Primitives 2.8. Recommended HDL Coding Styles Revision History
2.1. Using Provided HDL Templates
2.1.1. Inserting HDL Code from a Provided Template
2.3. Inferring Multipliers and DSP Functions
2.3.1. Inferring Multipliers 2.3.2. Inferring Multiply-Accumulator and Multiply-Adder Functions
2.4. Inferring Memory Functions from HDL Code
2.4.1. Inferring RAM functions from HDL Code 2.4.2. Inferring ROM Functions from HDL Code 2.4.3. Inferring Shift Registers in HDL Code
2.4.1. Inferring RAM functions from HDL Code
2.4.1.1. Use Synchronous Memory Blocks 2.4.1.2. Avoid Unsupported Reset and Control Conditions 2.4.1.3. Check Read-During-Write Behavior 2.4.1.4. Controlling RAM Inference and Implementation 2.4.1.5. Single-Clock Synchronous RAM with Old Data Read-During-Write Behavior 2.4.1.6. Single-Clock Synchronous RAM with New Data Read-During-Write Behavior 2.4.1.7. Simple Dual-Port, Dual-Clock Synchronous RAM 2.4.1.8. True Dual-Port Synchronous RAM 2.4.1.9. Mixed-Width Dual-Port RAM 2.4.1.10. RAM with Byte-Enable Signals 2.4.1.11. Specifying Initial Memory Contents at Power-Up
2.4.3. Inferring Shift Registers in HDL Code
2.4.3.1. Simple Shift Register 2.4.3.2. Shift Register with Evenly Spaced Taps
2.5. Register and Latch Coding Guidelines
2.5.1. Register Power-Up Values 2.5.2. Secondary Register Control Signals Such as Clear and Clock Enable 2.5.3. Latches
2.5.1. Register Power-Up Values
2.5.1.1. Specifying a Power-Up Value
2.5.3. Latches
2.5.3.1. Avoid Unintentional Latch Generation 2.5.3.2. Inferring Latches Correctly
2.6. General Coding Guidelines
2.6.1. Tri-State Signals 2.6.2. Clock Multiplexing 2.6.3. Adder Trees 2.6.4. State Machine HDL Guidelines 2.6.5. Multiplexer HDL Guidelines 2.6.6. Cyclic Redundancy Check Functions 2.6.7. Comparator HDL Guidelines 2.6.8. Counter HDL Guidelines
2.6.3. Adder Trees
2.6.3.1. Architectures with 4-Input LUTs in Logic Elements 2.6.3.2. Architectures with 6-Input LUTs in Adaptive Logic Modules
2.6.4. State Machine HDL Guidelines
2.6.4.1. Verilog HDL State Machines 2.6.4.2. VHDL State Machines
2.6.4.1. Verilog HDL State Machines
2.6.4.1.1. Verilog-2001 State Machine Coding Example 2.6.4.1.2. SystemVerilog State Machine Coding Example
2.6.4.2. VHDL State Machines
2.6.4.2.1. VHDL State Machine Coding Example
2.6.5. Multiplexer HDL Guidelines
2.6.5.1. Intel® Quartus® Prime Software Option for Multiplexer Restructuring 2.6.5.2. Multiplexer Types 2.6.5.3. Implicit Defaults in IF Statements 2.6.5.4. default or OTHERS CASE Assignment
2.6.5.2. Multiplexer Types
2.6.5.2.1. Binary Multiplexers 2.6.5.2.2. Selector Multiplexers 2.6.5.2.3. Priority Multiplexers
2.6.6. Cyclic Redundancy Check Functions
2.6.6.1. If Performance is Important, Optimize for Speed 2.6.6.2. Use Separate CRC Blocks Instead of Cascaded Stages 2.6.6.3. Use Separate CRC Blocks Instead of Allowing Blocks to Merge 2.6.6.4. Take Advantage of Latency if Available 2.6.6.5. Save Power by Disabling CRC Blocks When Not in Use 2.6.6.6. Initialize the Device with the Synchronous Load (sload) Signal
3. Managing Metastability with the Intel® Quartus® Prime Software
3.1. Metastability Analysis in the Intel® Quartus® Prime Software 3.2. Metastability and MTBF Reporting 3.3. MTBF Optimization 3.4. Reducing Metastability Effects 3.5. Scripting Support 3.6. Managing Metastability 3.7. Managing Metastability with the Intel® Quartus® Prime Software Revision History
3.1. Metastability Analysis in the Intel® Quartus® Prime Software
3.1.1. Synchronization Register Chains 3.1.2. Identify Synchronizers for Metastability Analysis 3.1.3. How Timing Constraints Affect Synchronizer Identification and Metastability Analysis
3.2. Metastability and MTBF Reporting
3.2.1. Metastability Reports 3.2.2. Synchronizer Data Toggle Rate in MTBF Calculation
3.2.1. Metastability Reports
3.2.1.1. MTBF Summary Report 3.2.1.2. Synchronizer Summary Report 3.2.1.3. Synchronizer Chain Statistics Report in the Timing Analyzer
3.2.1.1. MTBF Summary Report
3.2.1.1.1. Typical and Worst-Case MTBF of Design 3.2.1.1.2. Synchronizer Chains 3.2.1.1.3. Increasing Available Settling Time
3.3. MTBF Optimization
3.3.1. Synchronization Register Chain Length
3.4. Reducing Metastability Effects
3.4.1. Apply Complete System-Centric Timing Constraints for the Timing Analyzer 3.4.2. Force the Identification of Synchronization Registers 3.4.3. Set the Synchronizer Data Toggle Rate 3.4.4. Optimize Metastability During Fitting 3.4.5. Increase the Length of Synchronizers to Protect and Optimize 3.4.6. Set Fitter Effort to Standard Fit instead of Auto Fit 3.4.7. Increase the Number of Stages Used in Synchronizers 3.4.8. Select a Faster Speed Grade Device
3.5. Scripting Support
3.5.1. Identifying Synchronizers for Metastability Analysis 3.5.2. Synchronizer Data Toggle Rate in MTBF Calculation 3.5.3. report_metastability and Tcl Command 3.5.4. MTBF Optimization 3.5.5. Synchronization Register Chain Length
1. Recommended Design Practices
2. Recommended HDL Coding Styles
3. Managing Metastability with the Intel® Quartus® Prime Software
A. Intel® Quartus® Prime Standard Edition User Guides

1.3.2.1. Custom Design Rule Examples

The following examples of custom rules show how to check node relationships and clock relationships in a design.

This example shows the XML codes for checking SR latch structures in a design.

Detecting SR Latches in a Design


<DA_RULE ID="EX01" SEVERITY="CRITICAL" NAME="Checking Design for SR Latch" DEFAULT_RUN="YES">
<RULE_DEFINITION>
   <FORBID>
   <OR>
      <NODE NAME="NODE_1" TYPE="SRLATCH" />
      <HAS_NODE NODE_LIST="NODE_1" />
      <NODE NAME="NODE_1" TOTAL_FANIN="EQ2" /> 
      <NODE NAME="NODE_2" TOTAL_FANIN="EQ2" />
      <AND>
         <NODE_RELATIONSHIP FROM_NAME="NODE_1" FROM_TYPE="NAND" TO_NAME="NODE_2" TO_TYPE="NAND" /> 
         <NODE_RELATIONSHIP FROM_NAME="NODE_2" FROM_TYPE="NAND" TO_NAME="NODE_1" TO_TYPE="NAND" /> 
      </AND>
      <AND>
         <NODE_RELATIONSHIP FROM_NAME="NODE_1" FROM_TYPE="NOR" TO_NAME="NODE_2" TO_TYPE="NOR" /> 
         <NODE_RELATIONSHIP FROM_NAME="NODE_2" FROM_TYPE="NOR" TO_NAME="NODE_1" TO_TYPE="NOR" /> 
      </AND>
      </OR>
   </FORBID>
</RULE_DEFINITION>

<REPORTING_ROOT>
   <MESSAGE NAME="Rule %ARG1%: Found %ARG2% node(s) related to this rule.">
      <MESSAGE_ARGUMENT NAME="ARG1" TYPE="ATTRIBUTE" VALUE="ID" /> 
      <MESSAGE_ARGUMENT NAME="ARG2" TYPE="TOTAL_NODE" VALUE="NODE_1" /> 
   </MESSAGE>
</REPORTING_ROOT>
</DA_RULE>

The possible SR latch structures are specified in the rule definition section. Codes defined in the <AND></AND> block are tied together, meaning that each statement in the block must be true for the block to be fulfilled (AND gate similarity). In the <OR></OR> block, as long as one statement in the block is true, the block is fulfilled (OR gate similarity). If no <AND></AND> or <OR></OR> blocks are specified, the default is <AND></AND>.

The <FORBID></FORBID> section contains the undesirable condition for the design, which in this case is the SR latch structures. If the condition is fulfilled, the Design Assistant highlights a rule violation.

Detecting SR Latches in a Design


<AND>
  <NODE_RELATIONSHIP FROM_NAME="NODE_1" FROM_TYPE="NAND" TO_NAME="NODE_2"
   TO_TYPE="NAND" /> 
  <NODE_RELATIONSHIP FROM_NAME="NODE_2" FROM_TYPE="NAND" TO_NAME="NODE_1"
   TO_TYPE="NAND" />
</AND>
Figure 10. Undesired Condition 1 

<AND>
 <NODE_RELATIONSHIP FROM_NAME="NODE_1" FROM_TYPE="NOR" TO_NAME="NODE_2" TO_TYPE="NOR" />
 <NODE_RELATIONSHIP FROM_NAME="NODE_2" FROM_TYPE="NOR" TO_NAME="NODE_1" TO_TYPE="NOR" />
</AND>
Figure 11. Undesired Condition 2

This example shows how to use the CLOCK_RELATIONSHIP attribute to relate nodes to clock domains. This example checks for correct synchronization in data transfer between asynchronous clock domains. Synchronization is done with cascaded registers, also called synchronizers, at the receiving clock domain. The code in This example checks for the synchronizer configuration based on the following guidelines:

  • The cascading registers need to be triggered on the same clock edge
  • There is no logic between the register output of the transmitting clock domain and the cascaded registers in the receiving asynchronous clock domain.

Detecting Incorrect Synchronizer Configuration


<DA_RULE ID="EX02" SEVERITY="HIGH" NAME="Data Transfer Not Synch Correctly" DEFAULT_RUN="YES">

<RULE_DEFINITION>
<DECLARE>
   <NODE NAME="NODE_1" TYPE="REG" /> 
   <NODE NAME="NODE_2" TYPE="REG" /> 
   <NODE NAME="NODE_3" TYPE="REG" /> 
</DECLARE>
<FORBID>
   <NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" /> 
   <NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" /> 
   <OR>
      <NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" REQUIRED_THROUGH="YES" THROUGH_TYPE="COMB" CLOCK_RELATIONSHIP="ASYN" /> 
      <CLOCK_RELATIONSHIP NAME="SEQ_EDGE|ASYN" NODE_LIST="NODE_2, NODE_3" /> 
   </OR>
</FORBID>
</RULE_DEFINITION>

<REPORTING_ROOT>
<MESSAGE NAME="Rule %ARG1%: Found %ARG2% node(s) related to this rule.">
   <MESSAGE_ARGUMENT NAME="ARG1" TYPE="ATTRIBUTE" VALUE="ID" /> 
   <MESSAGE_ARGUMENT NAME="ARG2" TYPE="TOTAL_NODE" VALUE="NODE_1" /> 
   <MESSAGE NAME="Source node(s): %ARG3%, Destination node(s): %ARG4%">
      <MESSAGE_ARGUMENT NAME="ARG3" TYPE="NODE" VALUE="NODE_1" />
      <MESSAGE_ARGUMENT NAME="ARG4" TYPE="NODE" VALUE="NODE_2" />
   </MESSAGE>
</MESSAGE>
</REPORTING_ROOT>
</DA_RULE>

The codes differentiate the clock domains. ASYN means asynchronous, and !ASYN means non-asynchronous. This notation is useful for describing nodes that are in different clock domains. The following lines from the example state that NODE_2 and NODE_3 are in the same clock domain, but NODE_1 is not. 


<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" /> 

<NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" />

The next line of code states that NODE_2 and NODE_3 have a clock relationship of either sequential edge or asynchronous. 

<CLOCK_RELATIONSHIP NAME="SEQ_EDGE|ASYN" NODE_LIST="NODE_2, NODE_3" />

The <FORBID></FORBID> section contains the undesirable condition for the design, which in this case is the undesired configuration of the synchronizer. If the condition is fulfilled, the Design Assistant highlights a rule violation.

The possible SR latch structures are specified in the rule definition section. Codes defined in the <AND></AND> block are tied together, meaning that each statement in the block must be true for the block to be fulfilled (AND gate similarity). In the <OR></OR> block, as long as one statement in the block is true, the block is fulfilled (OR gate similarity). If no <AND></AND> or <OR></OR> blocks are specified, the default is <AND></AND>.

The <FORBID></FORBID> section contains the undesirable condition for the design, which in this case is the SR latch structures. If the condition is fulfilled, the Design Assistant highlights a rule violation.

The following examples show the undesired conditions from with their equivalent block diagrams:

Undesired Condition 3


<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" /> 

<NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" /> 

<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" REQUIRED_THROUGH="YES" 
   THROUGH_TYPE="COMB" CLOCK_RELATIONSHIP="ASYN" />
Figure 12. Undesired Condition 3


Undesired Condition 4


<NODE_RELATIONSHIP FROM_NAME="NODE_1" TO_NAME="NODE_2" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="ASYN" />

<NODE_RELATIONSHIP FROM_NAME="NODE_2" TO_NAME="NODE_3" TO_PORT="D_PORT" CLOCK_RELATIONSHIP="!ASYN" />

<CLOCK_RELATIONSHIP NAME="SEQ_EDGE|ASYN" NODE_LIST="NODE_2, NODE_3" />
Figure 13. Undesired Condition 4


Level Two Title