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.