Archive for Dave Rich
Verification Horizons BLOG
What’s the deal with those wire’s and reg’s in Verilog
A unique concept most beginners have trouble grasping about the Verilog, and now the SystemVerilog, Hardware Description Language (HDL) is the difference between wire’s (networks) and reg‘s (variables). This concept is something that every experienced RTL designer should be familiar with, but there are now many verification engineers with no prior Verilog experience trying to pick up SystemVerilog for their testbench. Verification methodology courses tend to concentrate on the Object-Oriented programming aspects of testbench design, but do not cover this topic thinking that it is for designers only. Not true. If you have to communicate with a DUT then you need to understand the difference between wire’s and reg’s (nets and variables).
Anyone tasked with having to design or verify a piece of hardware should have some basic programming skills and understand the concept of a variable. If not, you had better stop right here and brush up on some programming basics. The key concept that you need to take away from programming is that you write a value into a variable and that value is saved until the next assignment to that variable. This concept is referred to as a procedural assignment which is part of executing an ordered set of statements. An HDL may add some notion of time in between assignments and other statements. The last assignment determines the current value of the variable.
| Combinatorial Logic | Sequential Logic |
|
|
Initially, Verilog used the keyword reg to declare variables representing sequential hardware registers. Eventually, synthesis tools began to use reg to represent both sequential and combinational hardware as shown above and the Verilog documentation was changed to say that reg is just what is used to declare a variable. SystemVerilog renamed reg to logic to avoid confusion with a register – it is just a data type (specifically reg is a 1-bit, 4-state data type). However people get confused because of all the old material that refers to reg. Just forget about it and use logic from now on.
Another distinctive characteristic of an HDL is that it models massive amounts of parallel processes. At the lowest level of digital design, every primitive gate (AND, OR, DFF) is an independent concurrent process. Modules are containers representing processes modeled at different levels of abstraction. Groups of primitives and modules pass values to each other via networks of signals. In Verilog, a wire declaration represents a network (net) of connections with each connection either driving a value or responding to the resolved value being driven on the net. The output of each of these concurrent processes drives a net in what is called a continuous assignment because the process continually updates the value it wants to drive on the net. There are various ways to declare a continuous assignment, all of which represent permanent behaviors:
wire A, B, C; assign A = B| C; // continuous assignment construct. or(A,B,C); // gate-level instance terminal connection mymodule m1(A,B,C); // module instance port connection 
Although these are all different forms of continuous assignment constructs, none of them directly assign a value to the net like a procedural assignment would. All of the values being concurrently driven onto the net are passed into a built-in resolution function. The result of that resolution function is based on the strengths of each driver representing the hardware technology in use. For example, an interrupt request signal might use the wired-or (wor) kind of net to indicate that at least one device is driving a ’1′, otherwise it will resolve to a ’0′. Some signals will have weaker pull-up/down resistors that will be overridden by the values of a stronger driver. Most technologies do not allow driving different values on the same net and the net will resolve to an unknown ‘x’ when that happens. In this case only one driver is actively assigning a ’0′ or ’1′ and the other drivers are effectively turned off by driving a high-impedance or ‘z’ state. The consequence of this is that a bi-directional port must be modeled using a net in order to have multiple drivers on either side of the port.
See my recent DVCon paper for an example of modeling bidirectional signals along with other tips for connecting the Testbench to your DUT.
It turns out that the vast majority of nets in a design will only have a single driver, so no strength information or resolution function is needed. SystemVerilog added a feature that allows a single continuous assignment to drive a variable. The expression driving the continuous assignment is assigned to the variable every time the expression changes its value. As soon as you have more than one driver or need strength information, you must go back to using a net. You cannot mix procedural and continuous assignments to the same variable. The reason for that restriction is that there is no way to resolve the “last write wins” semantics of a procedural assignment with a driver that wants to continually assign the variable (i.e. when is the last write finished and the continuous assignment supposed to take over?).
In summary, you should now be using logic for 4-state variables (or bit for 2-state variables) to represent all of your single drive signals. Any signal with more or the potential for more than one driver should be declared as a wire.
Tags: functional verification, SystemVerilog, Verification, verilog
Get your IEEE 1800-2012 SystemVerilog LRM at no charge
Today at this week’s DVCon 2013 conference, the IEEE Standards Association (IEEE-SA) and Accellera Systems Initiative (Accellera) have jointly announced the public availability of the IEEE 1800 SystemVerilog Language Reference Manual at no charge through the IEEE Get Program.
As I posted a few weeks ago, the 1800-2012 is not a major revision of the standard, but does contain a few enhancements that will be of interest to design and verification engineers alike. However, providing the standard as freely available download is major news.
Even though the relative cost of the LRM was minor compared to the cost of most projects utilizing the standard, there seemed to be a barrier in most engineer’s minds in justifying the expense. So most just continued to use the last freely available SystemVerilog 3.1a LRM, which was 9 years old and very obsolete for such a rapidly changing technology.
Thanks Accellera!
Tags: accellera, functional verification, IEEE, IEEE-SA, SystemVerilog
Get Ready for SystemVerilog 2012
The latest revision of the IEEE 1800-2012 SystemVerilog Language Reference Manual (LRM) is about to hit the press; though I doubt people will be printing the 1300+ pages on their own from the soon to be readily available online version. Here’s a little background into what’s in all those pages.
The first SystemVerilog LRM came from Accellera in 2002 as a set of extensions to the IEEE 1364-2001 LRM. This first LRM was called version 3.0 because it was considered the third generation of Verilog. Accellera released a few more versions and turned version 3.1a over to the IEEE in 2004. The IEEE released the 1800-2005 SystemVerilog LRM as a set of extensions to the 1364-2005 Verilog LRM, which became the last revision of the 1364 LRM. Four years later, the IEEE combined the SystemVerilog extensions with the Verilog LRM producing a single 1800-2009 SystemVerilog LRM.
Now, a short three years later, the SystemVerilog IEEE 1800-2012 LRM is ready having addressed 225 issues. The majority of these issues are clarifications and corrections to the existing LRM. However, a few enhancements ranging from the simple 
removal of the restriction on non-blocking assignments to class members to the major addition of multiple class interface inheritance made their way into the new LRM. A number of those enhancements will undoubtedly be presented at the upcoming Design & Verification Conference.
I’d like to demonstrate two enhancements that should be of value to most verification engineers. They address two of the more commonly asked SystemVerilog questions I receive: How do I generate an array of unique values? and How to I create covergroup bins to get toggle or one-hot functional coverage?
Generating unique array of random values
Many verification scenarios require creating sets of random instructions or addresses with no repeating values, usually represented as elements in a dynamic array. Earlier versions of SystemVerilog required you to use either nested foreach loops to constrain all combinations of array elements so that they would not be equal to each other. Or else repeatedly randomize one element at a time, and then constraining the next element to not be in the list of already generated values.
The new unique constraint lets you use one statement to constrain a set of variables or array elements to have unique values. When randomized, this class generates a set of ten unique values from 0 to 15.
You can also add other non-random variables to the set of unique values which has the effect of excluding the values of those variables from the set of unique values. When randomized, this class generates a set of ten unique values excluding the values 0, 7 and 15.
Complex coverpoint bin expressions
The previous SystemVerilog syntax for specifying functional coverage bins was very limiting. Unless you could explicitly state the individual bin values or range of bin values in your coverpoint definition, or could figure out a way to instantiate multiple copies of your covergroup passing in a different bin value as an argument, you were out of luck. This also made defining coverage crosses extremely difficult.
The new SystemVerilog bin syntax lets you specify a bin expression that is evaluated over the range of possible values of the coverpoint expression. The bin expression acts like a constraint, and the set of coverpoint values where the bin expression is true become the set of bins. The coverpoint below generates as set of bin values between 0 and 127 that are divisible by 3. The range is 0 to 127 because sbyte is a 7 bit variable.
Probably the most powerful feature is the coverpoint bin set that simply allows you to define an array of values that you want as bins. This is useful for specifying one-hot encodings, toggle coverage of a register, or any complex algorithm that can generate the set of bin values you want. The code below builds a list of onehot values in the encodings array, and then constructs the protocol_cg covergroup using the array as a set of bin values.
Available in the latest version of Questa
By the way, every feature discussed in this post is available in the latest version of Questa, 10.2.
Tags: Constrained Random Test, functional coverage, SystemVerilog, Verification
Get on the Fast Track to Advanced Verification with UVM Express
Advanced verification techniques including functional coverage and constrained random stimulus generation have proven themselves invaluable in the design of the smallest FPGAs to the largest SoCs today. Still many design and verification teams that need to and are willing to embrace these technologies have yet to do so. Verification environments written with basic hardware description languages like Verilog and VHDL, as well as home grown environments patched together with C, Tcl, or PERL scripts are entrenched and difficult to move away from. Adopting these new techniques requires training on several fronts. You need to learn the SystemVerilog language along with Object-Oriented programming skills. And to make your verification environments reusable and interchangeable with Verification IP (VIP) that you may want to get from outside sources, you need to learn the Universal Verification Methodology (UVM).
Or do you?
Maybe you can get started by using the minimal amount of things to get started. But how can you know what you need to know when there is so much to learn? That’s where the UVM Express comes in.
The UVM Express is a carefully planned path with a few key steps along the way to get you up and running. You learn just the things you need to be more productive at each step and advance at your own pace. There’s no need to digest everything at once to get up and running. The UVM Express path has four key steps:
Step #1 Organize your Testbench into a BFM
- Use a SystemVerilog Interface to group your Signals
- Write your test in terms of transactions
- Call tasks to execute transactions
Step #2 Add Functional Coverage
- Use Metrics to check Verification quality- How good are your tests?
- Add coverage agents
- Leverage pre-built VIP in passive mode
Step #3 Add Constrained Random Stimulus
Improve your test quality by generating stimulus efficiently- Leverage pre-built VIP in active mode
Step #4 Use the full power of the UVM
- Modify your environment to improve reusability and configurability
- Leverage all your code from the previous steps
The UVM Express adds to the many guides and examples in the UVM/OVM Online Methodology Cookbook on the Verification Academy. There is also a new UVM Express module that provides a multi-media walk through each of the steps. You can discuss this with me at next week’s DVCon 2012.
Tags: methodology, SystemVerilog, UVM, Verification
Getting started with the UVM – Using the Register Modeling package
Adopting SystemVerilog can be challenging to some, and learning the UVM at the same time might seem overwhelming. There is no getting over the fact that if you are going to develop any reasonably sized testbench in SystemVerilog, you need to learn how to declare and construct a class. You also need to learn a few Object-Oriented programming principles so you can extend a UVM class into something for your particular needs.
Once you lean those principals, adopting the UVM can significantly reduce the amount of time it takes to build your testbench because it provides the infrastructure to handle many of the common tasks used in functional verification today. Just a few examples of some of the features included in the UVM are:
- Coordinating stimulus across multiple interfaces in your design
- Setting “knobs” to configure your test from a single location without having to modify or re-compile lower level source code
- Determining when it is time to end the test
By using a common set of industry standard verification methodology and practices, engineers are given the ability to develop modular, reusable verification IP developed by project teams internal or external to their company. Another benefit of the UVM is that it is extensively documented as well as having a considerable amount of tutorial and example material readily available. Mentor Graphics provides the Verification Academy Cookbook and the Cookbook Recipe of the Month Seminar Series to get you started.
One of the significant features of the UVM that differentiates it from what was lacking in the OVM is its Register Layer (it was so lacking that Mentor back-ported the UVM Register Layer to the OVM for those users not yet able to migrate to the UVM). The compelling use model for the UVM Register Layer is that it abstracts away much of the UVM that one needs to learn as a test writer. You write much of your test as you would in software:
…
spi_rm.ctrl.read(status, read_data, .parent(this));
spi_rm.ctrl.write(status, write_data, .parent(this)); … Here we are issuing read and write commands to the control register of an SPI register model. All of the underlying translations to a specific DUT interface with its specific protocol are handled by Register Layer with configuration information set up by the testbench architect.
Our October Recipe of the Month gives a brief introduction to the UVM Register Layer. Our November Recipe will provide more details on implementing them in your environment.
Dave Rich
Tags: SystemVerilog, UVM, Verification Methodology
Using the UVM libraries with Questa
by Rich Edelman and Dave Rich
Introduction
The UVM is a derivative of OVM 2.1.1. It has similar use model, and is run in generally the same way.
One significant change is that the UVM requires a DPI compiled library in order to enable regular expression matching, backdoor access and other functionality.
When running UVM based testbenches, we recommend using the built-in, pre-compiled UVM and DPI compiled libraries. This will remove the need to install any compilers or create a “build” environment.
One other issue to mention if you are converting from OVM to UVM, and if you use stop_request() and/or global_stop_request(), then you will need to use the following plusarg, otherwise your testbench will end prematurely without awaiting your stop_request().
vsim +UVM_USE_OVM_RUN_SEMANTIC +UVM_TESTNAME=hello …
Simulating with UVM Out-Of-The-Box with Questa
The UVM base class libiraries can be used out of the box with Questa 10.0b or higher very easily. There is no need to compile the SystemVerilog UVM package or the C DPI source code yourself. The Questa 10.0b release and every release afterwards contains a pre-compiled DPI library, as well as a pre-compiled UVM library. The only dependency is that your host system requires glibc-2.3.4 or later installed. Questa 10.0c Windows users only, please read this important note about the location of the DPI libraries.
You can easily use these steps:
|
vlib work
vlog hello.sv
vsim hello …
|
Notice that we don’t have to specify +incdir+$(UVM_HOME)/src, $(UVM_HOME)/src/uvm_pkg.sv to vlog, or add a -sv_lib command to the vsim command to load the uvm_dpi shared object.
Controling UVM Versions
Each release of Questa comes with multiple versions of the UVM pre-compiled and ready to load. By default, a fresh install of Questa will load the latest version of UVM that is available in the release. If an older version of UVM is needed, this version can be selected in one of two ways.
Modify the modelsim.ini File
Inside the modelsim.ini file, it contains a line which defines a library mapping for Questa. That line is the mtiUvm line. It looks something like this:
mtiUvm = $MODEL_TECH/../uvm-1.1b |
This example is pointing to the UVM 1.1b release included inside the Questa release. If we wanted to downgrade to UVM 1.1a, then we would simply modify the line to look like this:
mtiUvm = $MODEL_TECH/../uvm-1.1a |
Command Line Switch
The Questa commands can also accept a switch on the command line to tell it which libraries to look for. This switch overrides what is specified in the modelsim.ini file if there is a conflict. The switch is ‘-L’. If this switch is used, then all Questa commands with the exception of vlib will need to use the switch.
vlib work vlog hello.sv -L $QUESTA_HOME/uvm-1.1a vsim hello -L $QUESTA_HOME/uvm-1.1a ...
If you are using some other platform, or you want to compile your own DPI library, please follow the directions below.
If you use an earlier Questa installation, like 6.6d or 10.0, then you must supply the +incdir, and you must compile the UVM.
For example, with 10.0a on linux, you can do
vlib work
vlog hello.sv
vsim -c -sv_lib $UVM_HOME/lib/uvm_dpi …
if you use your own UVM download, or you use Questa 6.6d or 10.0 you need to do the following:
vlib work
vlog +incdir+$UVM_HOME/src $UVM_HOME/src/uvm_pkg.sv
mkdir -p $UVM_HOME/lib
g++ -m32 -fPIC -DQUESTA -g -W -shared
-I/u/release/10.0a/questasim//include
$UVM_HOME/src/dpi/uvm_dpi.cc
-o $UVM_HOME/lib/uvm_dpi.so
vlog +incdir+$UVM_HOME/src hello.sv
vsim -c -sv_lib $UVM_HOME/lib/uvm_dpi …
Building the UVM DPI Shared Object Yourself
If you don’t use the built-in, pre-compiled UVM, then you must provide the vlog +incdir+ and you must compile the UVM yourself, including the DPI library.
In $UVM_HOME/examples, there is a Makefile.questa which can compile and link your DPI shared object.
For Linux (linux):
cd $UVM_HOME/examples
setenv MTI_HOME /u/release/10.0a/questasim/
make -f Makefile.questa dpi_lib
> mkdir -p ../lib
> g++ -m32 -fPIC -DQUESTA -g -W -shared
> -I/u/release/10.0a/questasim//include
> ../src/dpi/uvm_dpi.cc -o ../lib/uvm_dpi.so
For Linux 64 (linux_x86_64)
cd $UVM_HOME/examples
setenv MTI_HOME /u/release/10.0a/questasim/
make LIBNAME=uvm_dpi64 BITS=64 -f Makefile.questa dpi_lib
> mkdir -p ../lib
> g++ -m64 -fPIC -DQUESTA -g -W -shared
> -I/u/release/10.0a/questasim//include
> ../src/dpi/uvm_dpi.cc -o ../lib/uvm_dpi64.so
For Windows (win32):
cd $UVM_HOME/examples
setenv MTI_HOME /u/release/10.0a/questasim/
make -f Makefile.questa dpi_libWin
> mkdir -p ../lib
> c:/QuestaSim_10.0a/gcc-4.2.1-mingw32vc9/bin/g++.exe
> -g -DQUESTA -W -shared
> -Bsymbolic -Ic:/QuestaSim_10.0a/include
> ../src/dpi/uvm_dpi.cc -o
> ../lib/uvm_dpi.dll
> c:/QuestaSim_10.0a/win32/mtipli.dll -lregex
Note: For Windows, you must use the GCC provided on the Questa download page: (questasim-gcc-4.2.1-mingw32vc9.zip)
Save to /tmp/questasim-gcc-4.2.1-mingw32vc9.zip
cd $MTI_HOME
unzip /tmp/questasim-gcc-4.2.1-mingw32vc9.zip
<creates the GCC directories in the MTI_HOME>
Using the UVM DPI Shared Object
You should add the -sv_lib switch to your vsim invocation. You do not need to specify the extension, vsim will look for ‘.so’ on linux and linux_x86_64, and ‘.dll’ on Windows.
linux:
vsim -sv_lib $UVM_HOME/lib/uvm_dpi -do “run -all; quit -f”
linux_x86_64:
vsim -sv_lib $UVM_HOME/lib/uvm_dpi64 -do “run -all; quit -f”
win32:
cp $UVM_HOME/lib/uvm_dpi.dll .
vsim -sv_lib uvm_dpi -do “run -all; quit -f”
Running the examples from the UVM 1.1 Release
If you want to run the examples from the UVM 1.0 Release you need to get the Open Source kit – it contains the examples.
1. Download the UVM tar.gz and unpack it.
- Go to http://verificationacademy.com/verification-methodology - the download link is in the “UVM/OVM Downloads & Contributions” box.
- On the Accellera download page, click on “Download UVM”
2. set your UVM_HOME to point to the UVM installation.
- setenv UVM_HOME /tmp/uvm-<version#>
3. Go to the example that you want to run.
- cd $UVM_HOME/examples/simple/hello_world
4. Invoke make for your platform:
- For Windows (win32)
cd $UVM_HOME/examples/simple/hello_world make DPILIB_TARGET=dpi_libWin -f Makefile.questa all # Note: for windows, you need a "development area", with make, gcc/g++, etc. Using cygwin is the easiest solution |
- For Linux (linux)
cd $UVM_HOME/examples/simple/hello_world make -f Makefile.questa all |
- For Linux 64 (linux_x86_64)
cd $UVM_HOME/examples/simple/hello_world make BITS=64 -f Makefile.questa all |
Migration from OVM to UVM
An OVM design can be migrated to UVM using a script. Many OVM designs can work without any hand coded changes or other intervention. It is a good idea to first get your design running on the latest version of OVM 2.1.2, before starting the migration process.
These designs can be converted from OVM to UVM using the distributed conversion script:
cd $MY_TEST_BENCH
$UVM_HOME/bin/ovm2uvm
In certain cases hand coded changes might be required.
Using the ovm2uvm script, you can run a “dry run” try and see what must be changed. There are many options to the script. Before using it, you should study it carefully, and run it in ‘dry-run’ mode until you are comfortable with it. In all cases, make a backup copy of your source code, before you use the script to replace-in-place.
By default it does not change files.
Here is a simple script which copies the ovm code, then applies
the script.
# Copy my ovm-source to a new place.
(cd ovm-source; tar cf – .) | (mkdir -p uvm-source; cd uvm-source; tar xf -)
# Do a dry-run
$UVM_HOME/bin/ovm2uvm.pl -top_dir uvm-source
# Examine the *.patch file
….
# If satisfied with the analysis, change in place
$UVM_HOME/bin/ovm2uvm.pl -top_dir uvm-source -write
If you are migrating to the UVM from OVM, you are NOT required to use this script, but you must do a conversion by some means.
Once your OVM design is converted to UVM, you are almost ready to run.
The UVM requires that you use some DPI code. Additionally, the UVM defines a different semantic for run(). If you are using an OVM design converted to UVM, and you use stop_request() or global_stop_request(), then you need to add a switch:
vsim +UVM_USE_OVM_RUN_SEMANTIC +UVM_TESTNAME=hello …
In order to NOT use this switch, you need to change your OVM design. You need to NOT use stop_request() or global_stop_request(). You should cause your test and testbench to be controlled by raising objections as the first thing in your run tasks, and then lowering your objections where you previously had your stop requests.
More information about migrating from OVM to UVM can be found in the Verification Academy Cookbook (registration required).
Tags: methodology, questa, UVM, UVM-1.0, UVM-1.1
Parameterized Classes, Static Members and the Factory Macros
Somebody asked me a simple question: Why do need two different macros (`ovm_object_utils and `ovm_object_param_utils) to register classes with the factory, and why can’t it tell me when I’ve used the wrong one? The answer turns out to be quite long, and demonstrates the dangers of using certain macros without first understanding the code behind them. Some I’m posting the response here. Adam Erickson will be presenting a paper Are Macros in OVM & UVM Evil? at the upcoming DVCon11 on Wednesday, March 2nd that goes into more details about the costs and benefits of the OVM macros.
First I need to talk about parameterized classes in SystemVerilog and how they interact with static members of those kinds of classes.
When you declare a parameterized class, it is more like a template, or generic class than a real class type. Only specializations of parameterized classes are real types. Suppose I have the two class definitions in the table below:
|
Un-parameterized |
Parameterized |
|
class A; |
class B #(int w=1); |
The class A definition by itself creates the static variable A::name initialized with the string “packet” without any other reference to class A. As soon as you add parameters to a class definition, like the parameter w in class B, the class becomes a generic class and the static variable name does not get created. As soon as there are specializations of the class B, each unique specialization causes the static variables inside the class to be instantiated. The following statements create two specializations of class B and two instances of the static variable. B#(2)::name and B#(3)::name are both set to “packet”.
|
typedef B#(2) B2; |
The two class variable declarations (B3_1h and B3_2h) represent only one unique specialization of B because its parameters have the same value in both declarations. The variable B#(1)::name does not exist unless there is some other reference to B or B#(1) somewhere else.
What if you wanted the static string variable name to have a different value for each unique specialization of B? You could write something like
|
class B #(int w=1); |
Now assuming the previous typedef and variable declarations above, B#(2)::name would have the value “packet2” and B#(3)::name would have the value “packet3”. There would be no instance B#(1)::name and the string “packet1” would never have been generated.
Now let us go back to the `ovm_object_utils macro. Suppose we have the following class definition
|
`include “ovm_macros.svh” |
Looking at just the factory registration statement this macro inserts for us (this little one line macro expands to over 100 lines of code just to support the field automation macros), we see a typedef for a specialization of the parameterized class ovm_object_registry called type_id.
|
import ovm_pkg::*; |
The specialized class type_id gives us access to all the static declarations inside ovm_object_registry. The code inside that class does something similar to what class A did above, except that it builds a global list of all string names and their associated types that can be used by the factory. The OVM gives you the choice of using the string name “packet” or the static function packetA::get_type() to set overrides, depending on which factory methods you use. The problem using the string names is that there is no type checking until run-time when the override statements are executed. We prefer you use type references to perform overrides
packetA::type_id::set_inst_override(extended_packetA::get_type(),”env.my_agent.*”);
Finally, let us take a look at a parameterized class, but assume we used the same `ovm_object_utils macro.
|
import ovm_pkg::*; |
There are two problems here. The first is that this is now a generic class. The string “packetB#(w)” will not put on the factory registration list unless there is a specialization of the class packetB somewhere. The second is that if there are more than one specializations of packetB, they all will be registered with the same string name, producing an error at run time.
The `ovm_object_param_utils macro simply leaves the second parameter to ovm_object_registry as the null string and forces you to use type references for your overrides. These type references also create the specializations needed to create the static methods inside these classes.
packetB#(2)::type_id::set_inst_override(
extended_packetB#(2)::get_type(),”env.my_agent.*”);
The references to packetB#(2) and extended_packetB#(2) are checked at compile time and cause the static methods within these references to be created.
You can use $psprintf to register a string name as long as the string is unique for each specialization of the class. This can be difficult when the parameters are types.
|
import ovm_pkg::*; |
OK, I’m done. If you still need more background information. I recommend another DVCon09 paper I wrote with Adam about Using Parameterized and Factories.
Tags: OVM, SystemVerilog, Verification Methodology
SystemVerilog Coding Guidelines: Package import versus `include
Another frequently asked question: Should I import my classes from a package or `include them? To answer this properly, you need to know more about SystemVerilog’s type system, especially the difference between its strong and weak typing systems.
In programming languages, weak typing is characterized by implicit or ad-hoc conversions without explicit casting between values of different data types. Verilog’s bit vectors, or integral types, represent these weak typing aspects by implicitly padding and truncating values to be the proper bit lengths – at least proper by Verilog standards. If you perform a bitwise AND of a 7-bit and 8-bit vector, Verilog implicitly zero pads an 8th bit to the 7-bit operand and returns an 8-bit result. In contrast using VHDL, you would have to explicitly state whether you wanted the 7-bit operand to be padded, or the 8-bit operand to be truncated so that you have an expression with operands of equal size.
With a few exceptions, all other types in SystemVerilog follow strong typing rules. Strong typing rules require explicit conversions or casts when assigning or expressing operands of unequal types. And understanding what SystemVerilog considers equivalent types is key to understanding the effect of importing a class from a package versus including it from a file.
Inheritance aside, SystemVerilog uses the name of a type alone to determine type equivalence of a class. For example, suppose I have these two class definitions A and B below:
class A; |
class B; |
SystemVerilog considers these two class definitions unequal types because they have different names, even though their contents, or class bodies, are identical. The name of a class includes more than just the simple names A and B; the names also include the scope where the definition is declared. When you declare a class in a package, the package name becomes a prefix to the class name:
package P; |
package Q; |
Now there are two definitions of class A, one called P::A and the other called Q::A. And the variables P::a1 and Q::a1 are type incompatible referencing two different class A’s. Re-writing the above example using an include file creates the same situation – two incompatible class definitions.
| File A.sv | File P.sv | File Q.sv |
class A; |
package P; |
package Q; |
After `including class A into each package, you wind up with two definitions of class A. Using `include is just a shortcut for cut and pasting text in a file. Importing a name from a package does not duplicate text; it makes that name visible from another package without copying the definition.
| File A.sv | File P.sv | File R.sv | File S.sv |
class A; |
package P; |
package R; |
package S; |
Class A is declared in package P, and only in package P. The variables R::a1 and S::a1 are type compatible because they are both of type P::A. The fact that class A was `included from another file once it is expanded is no longer relevant once you consider the placement of the text from the file.
When you get compiler errors claiming that two types are incompatible even though they appear to have the same name, make sure you consider the scope where the types are declared as part of the full name. Class names declared in a module are prefixed by the module instance name, so the same module instantiated multiple times will create unique class names, all incompatible types.
For further information about packages, check out the June Verification Horizons article entitled “Using SystemVerilog Packages in Real Verification Projects”.
Dave Rich
Tags: IEEE 1800, S, SystemVerilog, Verification
The Art of Deprecation
At a recent SystemVerilog requirements gathering meeting,I was quite amused to see “deprecating features” come out as one of the top 10 user requested priorities for the next revision of the IEEE 1800 standard. Even more amazing was that this request came out without listing which features were to be considered for deprecation.
P1800 Requirements Gathering Meeting 2/27/2010
I’m sure most people don’t understand the meaning of the word deprecate. I thought I understood until I looked it up in a dictionary. According to Merriam-Webster:
Deprecate:
1 a archaic : to pray against (as an evil) b : to seek to avert <deprecate the wrath…of the Roman people — Tobias Smollett>
2 : to express disapproval of
3 a : play down : make little of <speaks five languages…but deprecatesthis facility — Time> b : belittle, disparage<the most reluctantly admired and least easily deprecated of…novelists — New Yorker>
In computer science standards and documentation, deprecation has come to mean to supersede or discourage use of a feature. It does not mean a feature has to be removed to be compliant with the standard. You can’t remove a feature from an existing standard; you can only remove a feature from being documented in a future standard. No vendor is going to immediately remove a feature from a tool that it has already implemented and in widespread use without ample warning and without providing a practical alternative to the user. Typically, a deprecated feature is never removed from support in a tool unless in the rare case it’s needed to allow for a future enhancement.
The current standard lists in Annex C.4 the defparam and the procedural continuous assignment statements as candidates for deprecation. Listing candidates for deprecation seems to be almost the same as actually deprecating them without removing the LRM. No tool will remove support for these statements regardless of whether they are candidates or actually removed from the LRM.
Q: So why go though the trouble of deprecating a feature in a standard?
A: Well, to discourage use of that feature.
Q: And why is that a good thing to do?
A: It makes learning the language and maintaining existing code much easier.
Take an example from the current Verilog and SystemVerilog LRMs. The logic data type was added to supersede the reg data types; they both have the same semantics. Anyone with a history of Verilog will understand the change in keywords, but someone new to SystemVerilog will be left wondering why there are two keywords for the same thing. And then there is the issue of trying to maintain the LRM so that all references to reg also include logic and the other way around. If someone misses that in one place, people will begin to think the two keywords have different behaviors.
It seems it’s always easier to add new features than to remove them. There are many places to create lists of your favorite enhancements. At the same time, people complain about the size of the Language Reference Manual – it’s over 1200 pages. Doug Smith of Doulos writes “Will this language ever stop exploding?”
So here is my list for deprecation, as well as a place for other to add their list by commenting here.
- Program blocks
- Reg data type – see above
- Wildcard associative array index types
- Un-typed mailboxes
- Dynamic array copy A = new[]B redundant with A = B
- always @(*) – superseded by always_comb
Tags: IEEE 1800, Standards, SystemVerilog
SystemVerilog: A time for change? Maybe not.
The SystemVerilog IEEE 1800-2009 Language Reference Manual (LRM) was published a few months ago with an unprecedented 472 updates. That’s in addition to the changes required as part of the merging process with the Verilog 1364-2005 LRM. And in that five year timeframe, the Mantis system that tracks all of the LRM issues has grown to 986 open issues, becoming a black hole for issues. The SystemVerilog Working Group is collecting input for the next revision.
Inconsistencies in Implementations
There’s a lot of variety in what’s in the latest LRM versus what’s actually implemented in simulators today. Vendors have different sets of customers with different sets of priorities that drive implementing SystemVerilog features. Ambiguities in the LRM that have yet to be addressed wind up as inconsistencies in vendor‘s simulators.
Even some of what was specified in IEEE 1800-2005 has yet to be implemented. Take pattern matching of tagged union for example. This feature was put into Accellera SystemVerilog before IEEE standardization, but to my knowledge, had yet to be implemented in any simulator.
Why? There are several reasons. The most likely reason is that no customer has asked for it, or it has been below the threshold level to make it into anyone’s list to be implemented. Another reason is that there might be ambiguities in the LRM that need to be resolved before the feature can even begin to be implemented.
The result of all this is that users who want vendor interoperability are forced into restricted coding rules that limit themselves to a much smaller subset of SystemVerilog. Those same users often fail to realize that they need to drive their vendors to follow and fix the standard (See the recent discussion at Cool Verification).
The Problem
How did we get into this situation? Part of the problem lies with the PAR process. This is the IEEE process mandated to produce a revision of a standard. Five years is too long between revisions for an actively used standard. Users running into gaping holes in SystemVerilog functionality usually drive their vendors to bypass the PAR process and introduce proprietary extensions.
A Proposed Solution
After such a long revision process with so many changes, both users and vendors need to catch their breath. While it may be too radical to say no changes, we can propose a short period of stabilization where the main focus would be to address errata and ambiguities that drive convergence in implementations. We can improve the process that lets enhancements into the standard by making sure there is widespread support for that enhancement before work begins on it. Other areas for improvement could be to split the LRM is to separate standards (DPI/PLI) with their own schedules.
Input from users is welcome and needed.
Dave Rich
Tags: IEEE, SystemVerilog
About Dave Rich
Follow us on Twitter
Dave Rich is Verification Technologist at Mentor Graphics and is one of the authors of Mentor’s Advanced Verification Methodology cookbook. He began his career as a design and verification engineer in 1981 at Data General. In 1987, he joined Gateway Design Automation as one of the first application engineers to support Verilog-XL. At Gateway, he helped design many of the early features of the Verilog Hardware Description Language (HDL), and after Cadence acquired Gateway, helped prepare the Language Reference Manual (LRM) that would eventually be donated to the newly formed Open Verilog International. In 1995, he joined another Verilog simulation company, Frontline Design Automation as an AE manager and later as a Product Manager after it was acquired by Avant!. In 1998, he joined Ambit Design and worked as a consulting engineer for both synthesis and simulation products after it was acquired by Cadence. In 2000, he joined Co-Design Automation as Director of Application Engineering where the Superlog HDL was being developed that eventually became the basis of the Accellera SystemVerilog 3.0 standard. Co-Design Automation was acquired by Synopsys in 2002. Dave began work on numerous technical committees within Accellera and later the IEEE P1800 working group, which he continues today.
Latest Posts
- Part 1: The 2012 Wilson Research Group Functional Verification Study
- What’s the deal with those wire’s and reg’s in Verilog
- Getting AMP’ed Up on the IEEE Low-Power Standard
- Prologue: The 2012 Wilson Research Group Functional Verification Study
- Even More UVM Debug in Questa 10.2
- IEEE Approves New Low Power Standard
Subscribe to the Verification Horizons Newsletter