Visible to Intel only — GUID: mwh1409959627791
Ixiasoft
1.1. Using Provided HDL Templates
1.2. Instantiating IP Cores in HDL
1.3. Inferring Multipliers and DSP Functions
1.4. Inferring Memory Functions from HDL Code
1.5. Register and Latch Coding Guidelines
1.6. General Coding Guidelines
1.7. Designing with Low-Level Primitives
1.8. Recommended HDL Coding Styles Revision History
1.4.1.1. Use Synchronous Memory Blocks
1.4.1.2. Avoid Unsupported Reset and Control Conditions
1.4.1.3. Check Read-During-Write Behavior
1.4.1.4. Controlling RAM Inference and Implementation
1.4.1.5. Single-Clock Synchronous RAM with Old Data Read-During-Write Behavior
1.4.1.6. Single-Clock Synchronous RAM with New Data Read-During-Write Behavior
1.4.1.7. Simple Dual-Port, Dual-Clock Synchronous RAM
1.4.1.8. True Dual-Port Synchronous RAM
1.4.1.9. Mixed-Width Dual-Port RAM
1.4.1.10. RAM with Byte-Enable Signals
1.4.1.11. Specifying Initial Memory Contents at Power-Up
1.6.6.1. If Performance is Important, Optimize for Speed
1.6.6.2. Use Separate CRC Blocks Instead of Cascaded Stages
1.6.6.3. Use Separate CRC Blocks Instead of Allowing Blocks to Merge
1.6.6.4. Take Advantage of Latency if Available
1.6.6.5. Save Power by Disabling CRC Blocks When Not in Use
1.6.6.6. Initialize the Device with the Synchronous Load (sload) Signal
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.8. Intel® Quartus® Prime Pro Edition User Guide: Design Recommendations Archive
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. Increase the Number of Stages Used in Synchronizers
3.4.7. Select a Faster Speed Grade Device
Visible to Intel only — GUID: mwh1409959627791
Ixiasoft
1.6.6.3. Use Separate CRC Blocks Instead of Allowing Blocks to Merge
Synthesis tools often attempt to optimize CRC designs by sharing resources and extracting duplicates in two different CRC blocks because of the factoring options in the XOR logic.
CRC logic allows significant reductions, but this works best when the Compiler optimizes CRC function separately. Check for duplicate extraction behavior if for designs with different CRC functions that are driven by common data signals or that feed the same destination signals.
For designs with poor quality results that have two CRC functions sharing logic you can ensure that the blocks are synthesized independently with one of the following methods:
- Define each CRC block as a separate design partition in a hierarchical compilation design flow.
- Synthesize each CRC block as a separate project in a third-party synthesis tool and then write a separate Verilog Quartus Mapping (.vqm) or EDIF netlist file for each.