Don’t use $unit and module parameters when SystemVerilog package import can do the job

In a SystemVerilog design many basic types and sizes are shared. Passing them down as Verilog-style module parameters through endless levels of instantiation hierarchy isn’t the best way to keep SystemVerilog module definitions generic.

SystemVerilog added two lexical scoping mechanisms beyond module definitions for this purpose, the compilation-unit scope ($unit) and packages. I recommend packages.

An old objection that is no longer accurate was that types and sizes from packages could not be used in the declarations of module ports without either fully qualified package references (such as type_package::T) or wildcard imports into $unit. But that was fixed in IEEE Std 1800-2009 by allowing package imports directly after the module name in a definition.

A new objection is that package imports after the module name clutter up the code, because if they are sharing global types and values they are needed in almost every module and interface definition. But here I show an easy way to get rid of the clutter with an unobtrusive macro.

`define _ import global_parameters::*, type_package::*;

module test `_
( input var T in[N]
, output var T out[N]
  always_comb out = in;

Type-checking SystemVerilog interfaces using a class signature

As I wrote here,

Unlike class specializations, interface specializations cannot be used in a module port declaration. For example, the following is disallowed

module m #(parameter N) (IFC#(N) ifc, ...);

Steven Sharp followed up here that perhaps it was an oversight instead of a decision. Either way, it is still disallowed. He discusses some of the problems this causes for separate compilation. Happily, it is possible to get the effect of at least type checking SystemVerilog interfaces by combining class specializations (8.25) and interface-based typedefs (6.18) using a couple macros.

`define SIGNATURE_DEFINE(Params) \
   typedef SIGNATURE Params \%SIGNATURE ;

`define SIGNATURE_CHECK(Params, Port) \
  if (1) begin \
    typedef SIGNATURE Params Expected; \
    typedef Port.\%SIGNATURE Actual; \
    if (type(Expected) != type(Actual)) begin \
      $fatal("Mismatch"); \
    end \

Here’s a simple example

virtual class SIGNATURE#(int N, type T);

interface IFC#(int N, type T);
  T a[N], z[N];
  modport mp (input a, output z);

module top;
  IFC#(8,int) ifc_inst();
  test#(32,byte) test_inst(;

module test#(int N, type T)( ifc_mp);
  `SIGNATURE_CHECK(/*IFC*/#(N,T), ifc_mp);
  // ...
Copyright © 2016 Brad Pierce

Innovation and standards

According to Dave Rich

The whole point of a having a standard is recording common practice.

[We] have a long history that other end users and implementers of the standard do not have. It’s easy for us to understand the intent, and search the LRM for justifications, but those other people do not have that benefit. And all the people in that environment (training, support, maintenance, AEs), are faced with these problems every day (and many times each day).

According to Brad Pierce

There are more answers to “Why Standards?” than just “recording common practice”.

For example, “Standards can fuel innovation by providing a common starting point.”

Importing Java-style interface classes was an excellent addition to the SystemVerilog language, but they were not common practice in SystemVerilog tools.

According to Dave

I’m not trying to say there’s no place for innovation in standards, it’s just that you can’t forget the underlying principle that brought everybody together in the first place.

I know that if you get a lot of engineers in a room they all will want to work on new and exciting ideas but you can’t forget about the foundation. My favorite analogy:: you can build the most advanced aircraft in the world, but it will never take off unless someone designs the rubber tires.

According to Brad

I’m not objecting to investing some resource into perfecting our rubber tires, I just don’t think the ones we have now are so defective that we can only dare taxi around the airport.

There ought to be a balance between maintenance and innovation, if only to fire up the enthusiasm of the participants. I don’t know anyone that wants to be on projects that have fallen completely into maintenance mode. Maintenance is an honorable and necessary function, and we all do some of it, but it’s thin gruel that should only be eaten as part of a balanced diet.

SystemVerilog: Backward compatibility with Verilog was a key to its success

According to Dave Rich

Superlog was originally designed to be a complete remake of Verilog using more modern programming concepts. My role as the company’s first application engineer was simply to convince people to use it. However, after working at four different Verilog start-ups, I realized how important it was to support legacy code and that migration to a new language must come in the form of evolution, not revolution. So we changed the design of Superlog to be 100% backward compatible with Verilog, as SystemVerilog is today.

UVM beyond SystemVerilog

According to Chris Edwards in “Expanding role of UVM takes center stage at DVCon Europe

[DVCon Europe general chair Martin] Barnasconi says UVM provides a useful framework that can be extended beyond its home of SystemVerilog-based IP verification […]

“We need to think beyond SystemVerilog,” says Barnasconi. “That’s where the challenge is if you ask me. System-level people might use SystemC, C++ or Matlab Simulink. The methodology concept behind UVM is something we should build upon to make it more applicable to other disciplines.

“In the conference there is a tutorial on UVM in SystemC. Teams are trying to bring the methodology to different languages. It underlines the ‘U’ in universal in my view. We also have the trend towards software-driven verification. We need to enable this software layer can be used within sequences defined in UVM.”

Waveform debugging 2015

According to Dave Rich in “A Decade of SystemVerilog: Unifying Design and Verification?

Most design engineers still debug their simulations the same way they debug in the lab: they look at waveforms. During simulation, they rarely look at the design source code, and certainly never look at the testbench code (unless it’s just basic pin wiggling like a waveform). Verification engineers are not much different. They rely on waveform debugging because that is what they were brought up on, and many do not even realize source-level debugging is available to them.

Vital signs

In SystemVerilog design, ‘unique case () inside’ should be your default ‘case’

I recommend requiring the following macro instead of direct uses of  case or casex

`define CASE(EXPR) \
   unique case (EXPR) inside

except when there’s a strong justification for the more expensive alternative

   priority case (EXPR) inside

If, as usual, the expectation is that every value should find a match, or if there is a default branch, then close with

`define ENDCASE \

But if the intent really is for some values not to match any case items, and there is no default branch, then close with