|
With the advent of advanced HDLs – such as SystemVerilog – that provide new and powerful language constructs, current hardware modeling styles can now be enhanced both in terms of abstraction level and overall efficiency.
Developing concise, accurate designs entails learning how SystemVerilog features can be effectively used to design efficient and synthesizable models for both ASICs and FPGAs. This paper will focus on the impact of new extensions and constructs in SystemVerilog on hardware designs and describe the usefulness and compatibility of these constructs vis-à-vis pure Verilog constructs.
The following four steps are proposed to raise the abstraction level of current Verilog HDL designs and provide a phase wise approach for Verilog designers to gradually migrate to SystemVerilog:
- Enhance conciseness and expressiveness of designs.
- Add built-in checks to avoid design issues.
- Design efficient FSM and RAM/ROM memory models.
- Graduate to object oriented generic hardware designs.
Part 1 of this article will examine Steps1 and 2 – conciseness of expression and built-in code verification. Adopting these first two steps can contribute to descriptiveness of the design and correlation of the RTL and gate-level netlist.
Step 1: Enhance conciseness and expressiveness of design
Conciseness of expression is achieved through the addition of coding shortcuts from C, the simplification of port expressions, and the collection of related data. Several studies have shown that the number of bugs in a piece of software directly correlates to the number of lines of code.
Using constructs that reduce the number of lines necessary to describe functionality is an important tool to reduce the pre and post tape-out issues found in a design.
Following are four ways to achieve conciseness in Verilog Designs using SystemVerilog features:
#1 – New built-in data types
Verilog provides reg and integer data types with 4 logic values for each bit. These multi-value data types are not always required for RTL-level modelling, where most logic can be represented using only 2-state values. Tri-state buses are the only places where 4 state values are required.
Intended for modelling at RTL levels, SystemVerilog adds several 2-state data types as illustrated in Table 1
Table 1. SystemVerilog built-in 2-state data types.
All the above 2-state logic types are synthesizable; synthesis tools can optimize on system memory and compile times for 2 state variables.
#2 – New abstract and user-defined types
By using SystemVerilog user-defined types, designers can model complex designs at more abstract levels that are still accurate and synthesizable, with the added advantage of making the code more self documenting and easier to debug.
To represent a large amount of data, Verilog array constructs are extended both in terms of representation and access methods. Structure and union types can also be used to represent grouping of variables.
Both packed and unpacked structures (packed structures can only contain integral values), and packed unions (same sized members using common storage and bit alignment) are synthesizable. Synthesis tools like Precision allow passing structures and unions through module ports and to task and function as arguments. Values can be assigned by member names or as a list of values.
Example 1. Design modeling with structure/union.
(Click this image to view a larger, more detailed version)
#3 – Relaxation of data type rules
SystemVerilog relaxes the Verilog strict semantic restrictions of variable data types such as where reg and net data type wire can be used.
Any SystemVerilog variable can be assigned a value from any number of initial or always procedural blocks (only one driver is recommended); single always_comb, always_ff, always_latch blocks; and continuous assignment statement or single module or primitive output.
The data type (e.g., bit, logic) of the signal is not dependent on the context in which it is used, hence the model can evolve from system to RTL to gate level without changing the data type of the signals used.
1. Relaxed semantics for SystemVerilog variables.
(Click this image to view a larger, more detailed version)
Example 2. Relaxed restrictions on variables.
(Click this image to view a larger, more detailed version)
#4 – Concise hierarchy connections
Implicit port connections reduce the redundant nature 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 SystemVerilog .name implicit port connections. When using the .name implicit port connection technique, any sub-block port that does not match in size or name to the module net or bus connected to the port, must be connected using a named-port connection.
SystemVerilog introduces the capability to instantiate modules with highly abbreviated (.*) implicit port connections. Implicit (.*) port connections are intended to facilitate the process of instantiating large sub-blocks into upper-level modules without having to type multiple lines of named port connections where the sub-blocks are instantiated.
Note: Since the (.*) implicit port connections style reduces the self-documentation and debugging capability of a tool, it is not recommended by the authors.
Example 3. .name port and (.*) port connections.
(Click this image to view a larger, more detailed version)
|
