1. Enhance conciseness and expressiveness of designs.
2. Add built-in checks to avoid design issues.
3. Design efficient FSM and RAM/ROM memory models.
4. Graduate to object oriented generic hardware designs.

In Part 1 we examined Steps1 and 2 – conciseness of expression and built-in code verification. Now, in Part 2, we will elaborate on Steps 3 and 4 and demonstrate how designers can improve code encapsulation, re-use, and consistency in model behavior – all without adversely affecting the quality of results.

Step 3: Design efficient FSMs and RAM/ROM memory models
#1 – Designing finite state machines
SystemVerilog enables modelling at higher levels of abstraction through the use of the following:

1. Strongly typed enumerated types with state encoding.
2. 2-state data types and user defined types.
3. Specialized always_comb, always_latch, and always_ff blocks.
4. Unique and priority case statements.

These enhancements enable accurate modelling that simulate and synthesize correctly with consistent behaviour across all tools.

The new SystemVerilog coding style is also easy to read and maintain compared to the Verilog method of modelling FSM's.

Example 1. FSM Modelling with SystemVerilog.
(Click this image to view a larger, more detailed version)

#2 – Designing RAM and ROM models
SystemVerilog also provides an enhanced method to model highly generic and complex memories with a very simple and readable representation. With the usage of powerful features like parameter types and user defined data types memory modelling gets very simplified.

Example shows how to effectively model RAM or ROM memories with SystemVerilog.

Example 2. Modeling RAM and ROM memories with SystemVerilog.
(Click this image to view a larger, more detailed version)

Step 4: Graduate to object oriented generic hardware designs
Collecting objects and their functionality together in the form of object-oriented programming has been one of the biggest recent advancements in software design. It allows one individual to be responsible for the description and maintenance of an object, rather than spreading that knowledge diffusely throughout a design, creating a risk that integration will expose differences in understanding. With the advent of SystemVerilog, this unification is now available for hardware design.

The following three ways can be used to employ object oriented modelling techniques in hardware designs.

#1 – SystemVerilog interfaces for encapsulation
The Verilog language connects modules through module ports. For large designs, using module ports to connect blocks of a design together can result in duplication of port declarations and communication protocols, increasing the risk of mismatched declarations and reducing the flexibility to modify or scale up or scale down in the future.

a) Communication models
SystemVerilog interfaces offer an object oriented paradigm for abstraction in communication models by focusing the description in one location. This ability to localize the description of an interface, use it as abstract port type, and let the synthesis process appropriately spread the hardware through the design, provides a big advantage to the design process.

An interface can contain data type declarations, tasks, functions, continuous assign statements, and procedural blocks to specify communication protocols based on bus signals. This can be an API that other engineers can use to connect to the bus, hiding the details of the data transfer onto and off of the bus.

This provides an advantage in terms of scalability. For example, if another signal needs to be added to the interface, this can be done without requiring every module that passes the bus through it to be modified to add the signal. Another example is if a design was originally developed with a serial bus and it is discovered that a parallel bus is needed, the interface can be exchanged, leaving the rest of the design unchanged.

SystemVerilog allows multiple views of the interface to be defined using modports. For example, each module connected to the interface can specify and share direction of the signal local to the interface port. Significant code size reduction is possible when multiple modules refer to the same interface; rather than listing all of the ports on each module, the single port reflecting the interface is sufficient.

1. Interface connecting two modules (MY_INTER1, MY_INTER2).
(Click this image to view a larger, more detailed version)

b) Transaction level modelling
Verilog-2001 and VHDL-2000 do not provide the ability to define an interface method; hence transaction level modelling technique can only be used in system modelling and in the verification domain.

With SystemVerilog, interfaces can represent both pin level signals for structural communication with RTL blocks and TLM in the form of tasks, functions, and procedural blocks. This allows hardware designers to take advantage of the TLM concept and represent the design at a more abstract level. This will assist verification of SystemVerilog designs due to better integration with transaction level test benches, with the benefits of ease of design, code reuse, and simulation performance.

Example 3. TLM design methodology.
(Click this image to view a larger, more detailed version)

Parameter types are used when multiple copies of RTL code for different data types with the same logic is being written. If a set of functions, interfaces, or modules have the same functionality for different data types, they become good candidates for parameter type usage. The synthesis compiler automatically generates functions, interfaces and modules for all used types; it reduces the designer's effort on coding for different data types, testing and debugging RTL code.

Example 4. Generic CPU design.
(Click this image to view a larger, more detailed version)

#3 – SystemVerilog packages and compilation unit scope for code reuse
Unlike Verilog, SystemVerilog provides an additional mechanism for sharing parameters, data, type, task, function amongst multiple SystemVerilog modules and interfaces, through the package construct. Packages are explicitly named scopes appearing at the outermost level of the source text (at the same level as top level modules and primitives).

a) Explicit named packages
There are two methods for referencing data in packages as follows:

1. The first is the scope resolution operator, "::". 
    
2. The second method is the import statement, of which there are two types:
   • An explicit import (import Pkg::func ;)
   • A wildcard import (import Pkg::* ;)

The explicit import only imports the symbols specifically referenced. By comparison, when using a wildcard import, a reference to any undefined identifier that is declared within the package causes that identifier to be imported into the local scope.

Packages allow encapsulation and code reuse for data types, parameters, tasks and functions by defining them once and referencing them throughout multiple modules and designs as needed.

b) Implicit packages : compilation unit support
SystemVerilog supports separate compilation using compiled units. A compilation-unit scope is a scope that is local to the compilation unit. It contains all declarations that lie outside of any other scope.

The Precision FPGA Synthesis tools from Mentor Graphics provide two use models for defining which files constitute a compilation unit:

1. Each file is a separate compilation unit in which case the declarations in each compilation-unit scope are accessible only within its corresponding file. (Default flow).
2. All files on a given compilation command line make a single compilation unit in which case the declarations within those files are accessible anywhere else within the constructs defined within those files.

The compilation-unit scope allows users to easily share declarations (e.g., types) across the unit of compilation, but without having to declare a package from which the declarations are subsequently imported. Thus, the compilation-unit scope is similar to an implicitly defined anonymous package. Because it has no name, the compilation-unit scope cannot be used with an import statement.

The authors recommend the use of packages instead of compilation unit scopes wherever possible to avoid compile time dependencies across different runs with different file order or across different tools.

Example 5. Compilation unit scope.
(Click this image to view a larger, more detailed version)

SystemVerilog backward compatibility with Verilog-2001
A primary goal of the SystemVerilog standardization effort has been to ensure that SystemVerilog is fully compatible with the IEEE 1364-2001 Verilog standard. All existing Verilog models should work with software tools that implement the SystemVerilog enhancements.

There are two caveats to this backward compatibility as follows:

1. 'define semantics in Verilog and SystemVerilog
2. SystemVerilog adds several new keywords to the Verilog language. There is the possibility that an existing model may have used one or more of these new keywords as a regular identifier. This is a relatively minor problem that software tools can easily deal with using compatibility switches.

Table 1. Comparison of Verilog and SystemVerilog RTL modelling styles.
(Click this image to view a larger, more detailed version)

Conclusion
All of the features like Conciseness and Expressiveness, Built-in Lint Checks, Object Oriented Design, and High level RTL block modelling discussed in this paper focus on design benefits with new SystemVerilog constructs.

A number of Verilog designs were compared with their SystemVerilog equivalents implemented using all the features mentioned above. No impact on the timing or area of the designs was observed on using Precision FPGA synthesis on these two sets of designs.

References

1. IEEE Std. 1364-2001 standard for the Verilog Hardware Description Language, IEEE, Pascataway, NJ, 2001.
2. IEEE P1800 Std. for SystemVerilog Hardware Description Language.
3. SystemVerilog for Design: A Guide to Using SystemVerilog for Hardware Design and Modeling, Stuart Sutherland, Kluwer Academic Publishers, Boston, MA, 2004, 0-4020-7530-8.

Sachin Kakkar is working as a member consulting staff with Mentor Graphics. He holds a Bachelor's degree 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 teams. Sachin can be contacted at sachin_kakkar@mentor.com.

Sanjay Gupta works as the director – engineering with Mentor Graphics' Noida Development Center. Sanjay joined Mentor Graphics in 1998. Sanjay completed his B.Tech degree in Electronics from IIT-Delhi in 1991. He has 15 years experience in the EDA Industry and has two US Patents to his name. Sanjay can be contacted at sanjay_gupta@mentor.com.

Ayan Banerjee is working as a lead member technical staff with Mentor Graphics. He received his Bachelor's degree in Electronics and Electrical Communication Engineering from Indian Institute of Technology, Kharagpur. He has 5 years of EDA experience working in System Verilog synthesis R&D teams. Ayan can be contacted at ayan_banerjee@mentor.com.

Rohit Goel is working as a lead member technical staff with Mentor Graphics. He holds a Bachelor's degree in Electrical Engineering from Institute of Technology, Banaras Hindu University. He has 4 years of experience in the EDA industry. Rohit can be contacted at rohit_goel@mentor.com.