April 28, 2008 -- Due to the increased complexity of recent designs, synthesis-simulation mismatches have become one of the most significant design issues during the verification phase. Most of the time, these mismatches are detected after silicon has been generated, requiring multiple respins. These mismatches can be very hard to detect as designs reach into the millions of gates and integrate IP from different vendors.
Verilog designers follow standard rules to avoid synthesis-simulation mismatches. A failure to follow these rules, however, is not detected early in the verification process. There are no language features available in Verilog that help designers avoid these mismatches in the first place.
This article proposes six hardware-modeling guidelines that use standard SystemVerilog features to avoid RTL-to-gate-level simulation mismatches. The basic premise behind all of these guidelines is that the same design information should be supplied to both verification and synthesis tools. Therefore, the guidelines help designers effectively use SystemVerilog synthesizable features.
Each of the following six guidelines covers basic building blocks of hardware design:
- Modeling registers and latches
- Modeling combinational logic
- Modeling finite state machines
- Modeling RAM and ROM
- Modeling generic reusable designs
- Modeling hierarchy connections
|
Each modeling guideline recommends which SystemVerilog features should be used, helps designers understand the capabilities and benefits of SystemVerilog enhancements in the context of the modeling examples, and emphasizes the correct usage of SystemVerilog constructs during logic synthesis and verification.
1. Modeling registers and latches
Registers (flip flops) and latches form common building blocks of any sequential circuit. Verilog designers use general-purpose always blocks where the design intent is not clearly apparent. SystemVerilog adds new forms of always blocks as well as qualifiers to allow designers to specify the design intent in a way that tools can easily infer and verify.
|
|
Code Example 1. Recommended SystemVerilog features: (i) always_latch, (ii) always_ff, (iii) iff qualifier. |
Benefits of always_latch, always_ff, and iff qualifier.
SystemVerilog always_ff block imposes the restriction that the block contains one and only one event control and no blocking timing controls. Verification and synthesis tools perform additional checks to warn if the behavior within an always_ff procedure does not represent sequential logic.
The activation expression for an always_latch is automatically inferred by the tools, ensuring that simulation and synthesis results behave similarly. The tools warn if latch behavior is not inferred from the always_latch blocks.
iff qualifiers explicitly separate the enable logic from the data path. This helps the synthesis tools infer specific enables across all registers and enables simulators to suppress redundant process invocations based on enable logic.
2. Modeling combinational logic
Using always block, task, and functions are common ways of modeling combinatorial logic. Since these blocks can support sequential logic, no lint checks on these constructs can be applied by tools in the design process. Using SystemVerilog void functions and always_comb blocks, instead of Verilog task and always blocks, to represent combinational logic, allows verification and synthesis tools to verify the designer’s intent.
|
|
Code Example 2. Recommended SystemVerilog features: (i) void functions, (ii) always_comb. |
|
|
Figure 1. SystemVerilog void functions and always_comb blocks allow verification and synthesis tools to verify the designer’s intent. SystemVerilog always_ff/ latch block imposes the restriction that the block contains one and only one event control and no blocking timing controls. |
Benefits of void functions and always_comb
Void functions are called as statements, like a Verilog task, but have the syntax and semantic restrictions of Verilog functions (for example, they cannot have delays, event controls, or non-blocking assignments). always_comb helps tools to automatically infer activation expressions and check that the hardware synthesized from the block does not contain any sequential elements.
3. Modeling Finite State Machines
With SystemVerilog, features such as strongly typed data types, new case modifiers, and specialized blocks, FSM can be modeled at higher levels of abstraction, which makes them easier to read and maintain.
|
|
Code Example 3. Recommended SystemVerilog features: (i) enumeration data types with state encoding, (ii) 2-state and user-defined data types, (iii) unique and priority modifiers, (iv) specialized always_comb and always_ff blocks. |
|
|
Figure 2. SystemVerilog enum data types with a restricted set of legal values and unique and priority modifiers reduce the chances of simulation synthesis mismatches. |
Benefits of enum data types and unique and priority modifiers
SystemVerilog enum data types are strongly typed, having a restricted set of legal values. The literal values can be changed based on the encoding style desired and can be used as names instead of digital logic values.
Unique and priority modifiers to the case statements in the state machine logic helps confirm that all possible values of the state variables are covered. Unlike full_case and parallel_case pragmas (hidden within Verilog comments), unique and priority modifiers provide a unified view of the hardware description to synthesis and verification tools, reducing the chances of simulation synthesis mismatches. 2-state and user-defined types can store 2-state values of 0 and 1, making them ideal for modeling FSM at higher levels of abstraction.
4. Modeling RAMs and ROMs
Most Verilog designers use two dimensional arrays to model memories and readmemh/b to initialize them. SystemVerilog significantly enhances Verilog arrays by allowing multiple packed and unpacked dimensions, with new constructs to initialize and access them.
|
|
Code Example 4. Recommended SystemVerilog features: (i) unpacked struct/union and user define types, (ii) multiple packed and unpacked dimensions, (iii) const declarations, (iv) array initialization operators. |
Benefits of unpacked struct/union and user define types, multiple packed and unpacked dimensions, const declarations, and array initialization operators
Unpacked struct/union and user defined types introduced by SystemVerilog are strongly typed. Unlike with Verilog, verification tools will issue an error if a strict type variable is assigned by a variable/value of different type. Multiple packed and unpacked dimensions can be used to concisely design highly generic and complex memories. const declarations (unlike Verilog parameter and localparam) can receive their value at run time instead of during elaboration to assist in verification and can be used to model ROM in a design. Array initialization operators (unlike Verilog $readmemh/b) help initialize multi-dimensional packed and unpacked arrays using nested sets of braces {} that exactly match the dimensions of the array.
5. Modeling Generic Reusable Designs
Generic models cut down on unintentional mistakes by reducing the effort required to code for different data types, test, and debug the RTL code. SystemVerilog adds the ability to develop generic models that can be reused in various contexts, independent of the size, signed, and state of the types used.
|
|
Code Example 5. Recommended SystemVerilog features: (i) parameter type (ii) array querying functions (iii) enumeration methods. |
Benefits of parameter type, array querying functions, and enumeration methods
A SystemVerilog parameter type can be used to override data types (like C++ templates) during elaboration. Verification and design tools can then automatically generate functions, interfaces, and modules for all the used types. Also, SystemVerilog array querying functions and enumeration methods allow development of generic and abstract routines that can work with any size array and any encoding style.
6. Modeling Hierarchy Connections
Hierarchy connections of large complex designs can be a source of inadvertent design errors. SystemVerilog features reduce this risk by restricting access to signals, reducing verbosity and better documenting the intent of the design.
|
|
Code Example 6. Recommended SystemVerilog features: (i) interfaces with modports, (ii) .name port connections. |
Benefits of interfaces with modports allow multiple views of the bus interface
Interfaces modports allow multiple views of the bus interface. Each module connected to the interface can specify and share the direction of the signal at the interface port. Significant code size reduction is possible when multiple modules refer to the same interface. This also restricts access to only the signals present in the modport.
implicit port connections eliminate the redundancy of listing a name twice for each named port connection when the port name matches the variable name that is connected to the port. With a careful naming convention, instantiating large logic blocks into a higher-level module will be less tedious by using .name port connections.
Conclusion
New SystemVerilog features enable accurate modeling that simulates and synthesizes correctly with consistent behavior across all tools. The new SystemVerilog modeling styles are easier to read and maintain compared to Verilog. All of the modeling styles described in this article raise the level of abstraction to the RTL with built in lint checks. This helps designers to make significant contributions to the design process by improving the descriptiveness of the design, the correlation of the gate-level netlist to the RTL, the consistency of model behavior, and the ease of maintenance.
By Rudra Mukherjee
Sachin Kakkar
and Gaurav Sharma
Rudra Mukherjee is a senior engineering manager with Mentor Graphics. She holds a masters in computer science from Indian Institute of Technology, Kharagpur, and has over 14 years of experience in the EDA industry, with 5 years of experience in SystemVerilog synthesis and the verification domain.
Sachin Kakkar is working as a Member Consulting Staff with Mentor Graphics. He holds a bachelors in Electronic and Communication engineering from Delhi College of Engineering. He has over 7 years of experience in the EDA industry, with 5 years of experience in leading SystemVerilog Synthesis R&D team.
Gaurav Sharma is working as Lead Member Technical Staff with Mentor Graphics. He holds a bachelors in Computer Science and Engineering from Indian Institute of Technology, Kanpur. He has more than 4 years of experience in SystemVerilog verification.
Go to the Mentor Graphics Corp. website to learn more. |