Towards a Practical Design Methodology

with SystemVerilog Interfaces and Modports

Jonathan Bromley
Doulos Ltd
Ringwood, U.K.
[email protected]

Abstract—Explores the benefits and limitations of

SystemVerilog interfaces and modports in block-level design. II. INTERCONNECT MODELING USING SYSTEMVERILOG
Identifies key problems of portability, re-use and flexibility in
interface-based design, and suggests a methodology for A. Data structures are not enough
adoption of SystemVerilog interfaces and modports that helps Like most other programming and hardware-description
to solve these problems in synthesizable designs. languages, SystemVerilog offers a rich set of constructs for
modeling user-specified data structures. In particular, it has
I. INTRODUCTION the struct and union construct and the useful concept of
packed data objects. Packed data in SystemVerilog are
The interface construct provided in the SystemVerilog stored in contiguous collections of bits having a well-defined
hardware design and verification language [1] offers a means organization, so that (in design applications) the mapping
to encapsulate complicated interconnect, just as Verilog's between data structures and the underlying hardware that
module construct encapsulates functionality. However, carries them is explicit. However, these packed structures
interconnects used in typical modern electronic systems and are inappropriate for modeling complicated interconnect
subsystems are not merely wiring. They contain non-trivial structures. They do not capture information about direction
functionality within the interconnect structure itself (often of signal flow, nor do they allow for the specification of
known as the bus fabric), and subsystems connected to such different views of the interconnect for different kinds of
a bus fabric need logic to support the often complex client modules that may connect to it. Both these issues are
protocols required by interconnect standards. It is not elegantly answered by the interface and modport constructs
obvious how the interface construct can be used to support in SystemVerilog. Note that, in the remainder of this paper,
all common interconnect modeling styles. the word “interface” is used exclusively to refer to the
Section II reviews the key features of, and motivation for, language construct in SystemVerilog and not in its ordinary
SystemVerilog’s interface construct, and shows how it can usage.
be used to model interconnect structures.
B. Interconnect modeling using SystemVerilog interfaces
Section III describes what the author believes to be the
key challenge associated with the use of interfaces in design, The SystemVerilog interface construct is closely similar
and shows that the most obvious solutions are unsatisfactory to a Verilog or SystemVerilog module both in the syntax of
in practice. its declaration and the language constructs it is permitted to
contain.1 It has, however, two special distinguishing
Section IV examines more radical solutions to the features:
problem discussed in section III, and argues that these
solutions are out of reach until tool vendors provide more • it can contain modport constructs;
complete SystemVerilog language support than is available • an interface instance may be connected to a
at present. module’s port, giving that module access through the
Sections V and VI consider how the advanced features of port to the interface’s entire contents but appearing
interfaces can be used to make designs more expressive, and as a single connection in the module’s instantiation.
address some concerns about robustness and ease of use.
Finally, section VII concludes with some specific design
1
methodology recommendations that respect the limitations of Reference [1] forbids module instances within an interface.
current tools, and summarizes changes to tools and language However, this restriction is not enforced by all tools and is
features that could make interfaces more widely useful. likely to be lifted in a future revision of the standard.
 wishes to connect to it. However, there are two far-reaching
interface Sig_Intf; repercussions of this change.
logic Sig;
modport driver_mp (output Sig); • The port connection in each connected module
modport receiver_mp (input Sig); makes reference not to a variable or net in the
endinterface enclosing module, but to an instance. We have, in
effect, bound an identifier (the module’s port name)
module Driver(Sig_Intf.driver_mp si); to an existing hierarchical instance. This ability is a
initial si.Sig = 1’b1; radical addition to the Verilog language.
endmodule SystemVerilog extends this notion yet further by
providing a new kind of variable (a virtual interface)
module Receiver(Sig_Intf.receiver_mp ri);
initial #1 $display(ri.Sig);
that can be bound to an interface or modport instance
endmodule dynamically, at run-time, although this feature is
inappropriate for synthesis and is not discussed
module Top_Fig1; further here.
Sig_Intf S ();
• The usage of interfaces and modports shown in Fig,1
Driver D (S.driver_mp);
Receiver R (S.receiver_mp);
is synthesizable by at least two commercially
endmodule available tools.2 (The Verilog code shown in the
connected modules is simplified for the sake of
brevity and is not synthesizable, but if it were, then
Figure 1. Interface with modports connecting two modules the whole design would be synthesizable.) The
important change here is that synthesis tools have
A modport defines a view of an interface, specializing traditionally refused to accept any kind of
the interface so that a specific kind of client module can hierarchical name or cross-module reference but, in
connect to it in an appropriate manner. Fig.1 illustrates two the special case of members of a connected interface,
modules, one a driver and the other a receiver, connected synthesis of forms such as ri.Sig is possible.
together by a very simple interface containing only one Current tools achieve this by flattening each
signal. Modports driver_mp and receiver_mp capture interface instance so that it becomes a collection of
views of the interface as required by driver and receiver signals declared in the instantiating module, and then
modules respectively. The modules explicitly choose to rewriting all connected modules’ port lists
connect to the modport appropriate to their behavior. It is appropriately.
useful to note that dataflow direction in a modport is
specified from the point of view of the connected module
rather than from the point of view of the interface. Thus, for III. THE PROBLEM OF MULTIPLE DRIVERS
example, in our driver_mp modport, signal Sig is The style exemplified in Fig.1 is perfectly suited to
specified as an output from a connected driver module. modeling a system structure in which each module is
“plugged-in” to a backplane or similar bus structure having a
For a trivial interface as shown in Fig.1 there is obviously number of identical sockets or attachment points all wired in
little benefit in the use of interfaces. Indeed, it adds some parallel. Each modport represents one possible kind of
complication to the connected modules – note, for example, socket. There is no limit on the number of modules that can
the “dotted name” ri.Sig that must be used in the receiver connect to a modport (although, as discussed later, a
module. However, if the interface encapsulates large and mechanism exists in SystemVerilog interfaces to restrict a
complex connectivity, the simplification achieved in the modport so that only zero or one module instance may
enclosing module is very valuable. In particular, if the connect to it). All module instances connecting to a given
interface represents a standard bus structure that is replicated modport will see exactly the same set of interconnect, with
in more than one place in the design, bus signals within the the same directionality attributes.
interface can retain their standard names, since they are
encapsulated in an interface instance. It is not necessary to
A. Three-state drivers
invent names for signals in the various instances of the bus
structure. The approach described above works very well for multi-
drop bus structures in which each module has a driver on its
C. Key features of this modeling style outputs but only one module’s drivers are active at any given
time. In such a scheme, the output drivers of currently
Superficially, the use of interfaces described in the inactive modules must refrain from driving their outputs,
previous paragraphs is a straightforward extension of the typically by asserting a high-impedance (“Z”) value onto
Verilog language. It has always been possible to capture a those outputs. Multi-drop buses of this type are common and
large collection of interconnect in a module and instantiate
that into an enclosing module. An interface merely makes it
more convenient for us to reach into that “module” by 2
It is likely that there are further synthesis tools, of which
allowing it to be referenced through a port of a module that the author is unaware, that offer similar capability.
 interface TS_Intf; interface Var_Intf;
wire Data; // uses a net logic Data; // uses a variable
logic [7:0] Adrs; logic [7:0] Adrs;
modport modport
master_mp(output Data, input Adrs); master_mp(output Data, input Adrs);
modport modport
slave_mp (input Data, output Adrs); slave_mp (input Data, output Adrs);
endinterface endinterface

module TS_Master(TS_Intf.master_mp mi); module Var_Master(Var_Intf.master_mp mi);

initial begin initial begin
mi.Adrs = 50; // select first source mi.Adrs = 50; // select first source
#100 #100
mi.Adrs = 42; // select other source mi.Adrs = 42; // select other source
end end
endmodule endmodule

module TS_Slave module Var_Slave

#(parameter A = 0) #(parameter A = 0)
(TS_Intf.slave_mp si, input logic data); (Var_Intf.slave_mp si, input logic data);
assign si.Data = (si.Adrs == A) always @*
? data // selected if (si.Adrs == A) // when selected...
: 1’bz; // deselected si.Data = data; // ...update result
endmodule endmodule

module Top_Fig2(input logic d42, d50); module Top_Fig3(input logic d42, d50);
TS_Intf T (); Var_Intf V ();
TS_Master M (T.master_mp); Var_Master M (V.master_mp);
TS_Slave #50 S50 (T.slave_mp, d50); Var_Slave #50 S50 (V.slave_mp, d50);
TS_Slave #42 S42 (T.slave_mp, d42); Var_Slave #42 S42 (V.slave_mp, d42);
endmodule endmodule

Figure 2. Multiple slaves using three-state drivers Figure 3. Multiple slaves using selective write to variable

appropriate for systems built at the level of a circuit board or

a rack-and-cards system, but are usually inappropriate at the B. Selective writing to variables
on-chip level where three-state drivers (those capable of As an alternative to three-state drivers on a multi-drop
asserting a high-impedance output) present many difficulties signal modeled as a net, the signal could be modeled as a
relating to testability and other issues. variable. Only the currently active connected module writes
to that variable; other connected modules are deselected and
Fig.2 shows a simple example in which the master refrain from writing to the variable. This approach works
module provides an address signal to the interface through a well in simulation but is unlikely to be synthesizable,
dedicated modport master_mp. Each slave module, because it requires the synthesis tool to resolve Verilog’s
connected via modport slave_mp, compares the address “last write wins” semantics across assignments from code in
signal with a parameter value. If its address matches, a slave multiple module instances. Most synthesis tools cannot do
assumes it has been activated and it drives a value on to the this resolution even for the much simpler case of
interface’s common Data net. Inactive slaves place a high- assignments from multiple processes in the same module.
impedance value on the Data net.
Fig.3 modifies the example of Fig.2 to show how
Some synthesis tools, notably those targeting FPGA multiple data sources can be implemented using selective
devices that lack on-chip three-state drivers, can write to a variable in the interface, as described in the
automatically restructure such a description so that a set of preceding paragraph. It is probably appropriate to emphasize
three-state drivers is mapped on to a multiplexer with once again that this approach simulates correctly but is not
equivalent functionality. However, this facility is not synthesizable with currently available tools.
universally available; and in any event the author is uneasy
about a technique demanding not only that the designer IV. PROPOSED SOLUTIONS
specify an apparently inappropriate architecture, but also that
the synthesis tool then convert it to a very different A. Selection (addressing) functionality in the interface
architecture.
SystemVerilog interfaces can include functionality, much
in the same way as modules. Consequently it would be
straightforward to add address-decoding functionality to the
 interface Arr_Intf; connected modules through a single modport. Each
logic Data; connected module is parameterized for the array subscript
logic slave_D[0:1]; that it will use, and takes care to write only to that element of
logic [7:0] Adrs; the array. Within the interface, address decoding or other
modport selection logic determines which element of the array is to be
master_mp(output Data, input Adrs); copied to the common Data signal; in our example we have
modport ORed together the various signals.
slave_mp (input slave_D, output Adrs);
always_comb Whilst this style is readily implemented with current
Data = slave_D[0] | slave_D[1]; tools, and can be used to model most typical bus structures, it
endinterface seems clumsy. It is awkward to parameterize, and requires
careful coordination of parameter values on the interface and
module Arr_Master(Arr_Intf.master_mp mi); on its connected modules.
initial begin
mi.Adrs = 50; // select first source The design described in [2] uses an extended form of this
#100 technique in which calls into functions in the interface are
mi.Adrs = 42; // select other source also parameterized for the slave identity.
end
endmodule C. Point-to-point interfaces; with bus fabric in a module
module Arr_Slave The bus fabric, together with module selection (address
#(parameter A = 0, slave_ID = 0) decoding) functionality, can be implemented in a traditional
(Arr_Intf.slave_mp si, input logic data); Verilog module. SystemVerilog interfaces can then be used
always @* to capture the point-to-point interconnect between each
if (si.Adrs == A) // when selected... connected module and its dedicated port on the bus fabric.3
si.slave_D[slave_ID] = data; Some features of interfaces remain valuable even in this
else // not selected restricted use model, as illustrated in Fig.5. This style has a
si.slave_D[slave_ID] = 0; number of important benefits.
endmodule

module Top_Fig4(input logic d42, d50);

Arr_Intf A ();
Arr_Master M (A.master_mp);
Arr_Slave #(50, 0) S50 (A.slave_mp, d50);
Arr_Slave #(42, 1) S42 (A.slave_mp, d42); Master module
endmodule
MASTER
modport
Figure 4. Interface with slave signal array
Interface M
(bus signals) Intf
interface, thus locating it in the bus fabric (the interface S SLAVE
itself) rather than in the connected modules. Each slave modport
module has its own distinct modport, with its own dedicated
data signal. Selection logic in the interface drives the Bus fabric module
appropriate data signal on to the interface’s common Data
signal.
M M
Whilst this approach is straightforward, and readily
implemented using today’s tools, it has the severe drawback Intf Intf
that the bus fabric must be given a distinct modport for each S S
connected module. Consequently the interface definition
cannot be generic and re-usable. Worse still, each modport Slave module Slave module
needs a distinct data signal, and these distinct names are
visible to the connected slaves. As a result, each slave must
be specialized for the modport to which it should connect.
We do not consider this approach to be useful in practice.
Figure 5. Bus fabric module and point-to-point interfaces
B. An array of signals, one per slave
The approach of section IV.A can be usefully improved
by providing an array in the interface, as shown in Fig.4. 3
The whole of this array can then be made visible to all The author is grateful to B. Mathewson of ARM Ltd for
bringing this technique to his attention.
 • Each point-to-point interconnect uses the same set of interface Gen_Intf
signals. An interface allows the standard names of #(parameter N_slaves = 2);
these signals to be used even when there are multiple
instances of the interconnect at the same level of the logic [7:0] Adr;
design hierarchy (as will surely be the case when logic slave_D [0:N_slaves-1];
using this approach). logic slave_sel [0:N_slaves-1];
logic Data;
• Modports are valuable to distinguish the two ends of
a point-to-point interconnect. For example, always_comb begin : selector
connected slave modules will see the bus fabric as a int slave_ID;
master; connected master modules will see the bus case (Adr) // Address decode
fabric as a slave. If it possesses modports for both 42: slave_ID = 0;
slave and master, the interface used to model each 50: slave_ID = 1;
point-to-point interconnect can correctly reflect this endcase
slave_sel = 0;
distinction in a uniform manner.
slave_sel[slave_ID] = 1'b1;
This usage idiom is a good fit with typical modern multi- Data = slave_D[slave_ID];
level bus architectures, and presents no difficulties for end : selector
current simulation and synthesis tools. It makes use of the
interface construct in a rather straightforward manner, and modport master_mp (
output Adr,
pushes most of the design challenges into the bus fabric
input Data
module. In practice, the bus fabric module is likely to be
);
customized by a specialized software tool to suit the user’s
system requirements, and therefore questions of re-usability generate
of the bus fabric module do not apply: re-use is achieved genvar i;
through the customization tool. for (i=0; i<N_slaves; i++)
begin : Slave
D. Generated modports with modport expressions modport slave_mp (
input Adr,
Earlier in this section it was noted that it is troublesome
input .sel(slave_sel[i]),
to implement address decoding in the interface because each output .Data(slave_D[i])
connected module then needs a distinct modport of its own. );
Not only is this clumsy, it is also error-prone because there is end : Slave
no straightforward way to forbid multiple modules from endgenerate
connecting to a given modport. (This issue of singleton
modports will be discussed in a later section). endinterface : Gen_Intf
SystemVerilog supports modport expressions, in which a module Gen_Master(Gen_Intf.master_mp mi);
modport not only specifies which signals in an interface are initial begin
visible, but also provides alias names for some or all of these mi.Adrs = 50; // select first slave
signals so that the connected module sees the alias name #100
rather than the signal’s real name. This feature can usefully mi.Adrs = 42; // select other slave
be combined with the generate construct to build an array of end
modports, all identical from the point of view of their endmodule : Gen_Master
connected modules, but making use of different signals
within the interface itself. Fig.6 shows an example of this module Gen_Slave(
technique. It shows several key features of the proposed interface.slave_mp si,
modeling style: input logic data
);
• The form interface.modport_name used in assign si.Data = data;
each slave module’s port list allows the connected endmodule : Gen_Slave
modport to be specified without specifying which
interface defines it. This facility makes it possible module Top_Fig6(input logic d42, d50);
for more than one interface implementation to Gen_Intf G ();
provide the same modport façade, readily allowing Gen_Master M (G.master_mp);
Gen_Slave S50 (G.Slave[0].slave_mp, d50);
progressive refinement of the bus fabric design
Gen_Slave S42 (G.Slave[1].slave_mp, d42);
without disturbing the design of connected modules. endmodule : Top_Fig6

Figure 6. Generated modports

 • The multiple similar modports are constructed in a SystemVerilog features – clocking block and virtual
generate loop. Consequently, it is important to interface – are used in conjunction with interfaces to provide
understand the scope names that this generate a complete, packaged solution to a number of issues relating
loop creates, so that the correctly scoped modport to configuration and timing of the connection between a
instance can be hooked by each client module. testbench and its device-under-verification. This application
of interfaces is already well established in verification
• In our example it is the interface (bus fabric) that practice and widely supported by current tools, and it is not
chooses which slave modport is selected as a considered further here.
function of an address value generated by the master.
However, address decoding can instead be C. Progressive refinement across varying levels of
performed within the client modules; it is merely abstraction
necessary for each module to provide a “selected”
signal back to the interface. The ability to import and export subprograms through
modports of an interface offers some interesting possibilities
This modeling style accurately reflects bus fabric in simulation environments composed of models some of
structures in the interface. It readily allows the bus fabric to which operate at a relatively high level of abstraction
specialize its modport instances – for example, allocating a (commonly known as transaction-level models) and some of
specific address range to each – whilst making the various which are more concrete, perhaps including timed behavioral
modport instances appear identical from the point of view of models and synthesizable RTL models. Since the current
a module connected to them. The author regards this as the paper’s concern is with synthesizable RTL modeling, this
most natural style for using interfaces to represent bus possibility is not considered further here.
structures in modern designs.
Unfortunately no commercially available simulation or VI. ROBUSTNESS AND ENCAPSULATION
synthesis tools support it, as far as the author is aware. This The approaches outlined in section IV make it possible to
is both disappointing and surprising, especially as the create designs in which interconnect is hidden or
SystemVerilog language reference manual explicitly encapsulated in an interface. Whilst this is highly desirable
provides an example of just such usage of modport and can represent a significant benefit for RTL designers,
expressions. there are some further opportunities for improving the
robustness and packaging of such designs that are worthy of
V. FURTHER OPPORTUNITIES FOR THE USE OF note. Some of these are, at least in principle, supported by
INTERFACES the SystemVerilog language in its current form.

A. Encapsulation of protocol functionality in an interface A. Singleton modports

Interfaces can contain subprograms (tasks and functions) By default, modports of a SystemVerilog interface are
as well as data objects that represent interconnect. These promiscuous. There is no limit to the number of modules
subprograms can be made available to connected modules that can connect to a given modport instance. Whilst this
via the interface’s modports using the import construct. If facilitates parallel connection of numerous modules to the
such subprograms are functions rather than tasks, and are same set of signals, it is entirely inappropriate when a
declared automatic so that they do not imply storage modport has been specialized to the needs of a specific,
elements, then such functions are synthesizable and offer a single connected module (as in several of the styles shown in
means for an interface to define functionality that will section IV). It would be preferable to restrict such a modport
ultimately be used in a connected module. In particular, an so that it can have at most one connected module, and it
interface could contain a state variable and next-state seems appropriate to describe such a modport as a singleton.4
function defining the state machine that will ultimately be
synthesized into a connected module. Since a bus protocol This singleton requirement can be met in at least four
in an RTL design is typically implemented using a state different ways, described in the following sections.
machine, this mechanism offers a way for an interface to 1) Exported function
contain not only a specification of interconnect but also a A modport can include a function export construct,
specification of the protocol that connected devices should giving the interface access to a function declared inside a
maintain on that interconnect. This technique has been connected module. Unless the extern forkjoin specification
successfully used in a synthesizable design [2] and is is used (as described in clause 20.8.4 of [1]), such an export
supported by several currently available tools. construct becomes illegal if more than one module connects
to the modport. Regrettably, the export construct is not
B. Verification-related uses supported for synthesis and as a result this technique is
The use of interfaces as a bridge between testbench and
device under verification has been recommended in several 4
Various dictionaries offer chaste as an antonym of
published verification methodology documents such as [3] promiscuous. The author regards singleton as more
and [4]. In this application, two non-synthesizable apposite in the current context.
currently unavailable. As indicated in section VI.B below, modports. However, the effect can readily be mimicked by
support for this feature would not only offer singleton providing an output from the connected module to convey
modports but would also enable a useful additional design the result of the decoding function back into the interface.
style.
2) Drive a uwire VII. CONCLUSIONS
The Verilog-2005 standard [5] introduced a new kind of Whilst the uses of SystemVerilog’s interface construct
net known as a uwire. Nets of this new kind are permitted to for verification are already established, there is little
have at most one driver. If an interface contains a net of the agreement on the most appropriate ways to use it in RTL
uwire kind, and that net is driven by a module connected to design. Of the approaches suggested in this paper, the most
one of the interface’s modports, then there can be only one promising (the use of modport expressions in modports
such module. Unfortunately, the author is aware of only one within a generate construct) is not supported by current
simulator, and no synthesis tools at all, that handle the uwire synthesis and simulation tools. It is much to be hoped that
construct at the time of writing. this situation will improve in the near future. Some
interesting possibilities for parameterization of bus-based
3) Write to a variable designs could in principle be supported by the use of already-
As already mentioned, synthesis tools permit only one standardized features of interfaces, but limitations of current
process to write to any given variable. Consequently, if a tools (and most especially the absence of synthesis support
variable exists in an interface and is written by a connected for functions exported from modules into an interface) mean
module through a modport, there can be at most one such that many of these possibilities are currently out of reach for
connected module. However, the SystemVerilog language RTL designers.
permits any number of processes to write to a variable. The
singleton property therefore cannot be enforced in simulation A. Limitations of the language
but merely becomes a synthesis restriction.
Section VI.A shows that there is no satisfactory way,
4) Programmer discipline with current tool support, to enforce singleton behavior on a
The aforementioned three ways to implement singleton modport. Even if tool support were available, the singleton
modports are all unavailable in practice. Solutions (1) and behavior would be a side-effect of other language features.
(2) depend on language features that are not currently The author regards it as a deficiency of the SystemVerilog
supported by synthesis tools, and (3) is unsatisfactory language that it offers no explicit means to restrict or enforce
because the restriction is not enforced in simulation. As far the number of connected modules on a modport.
as the author is aware, it is in practice only by careful coding The modport construct provides a means to capture a
that a modport can be treated as a singleton. This is usually client’s view of an interface. To facilitate progressive
fairly straightforward, but it is disappointing that it must be refinement, and to enable design of generic modules that can
left to users to enforce this behavior for themselves. inherit their interconnect protocol from whatever interface
they are connected to, it would be preferable for a modport to
B. Address decoding functionality in a connected module be a language construct in its own right – not merely a
Most of the styles described in section IV implement a feature of an interface. Because modports can exist only as a
readback multiplexer as part of the bus fabric interface. component of an interface, designers have only two choices:
Such a multiplexer must be selected by means of an address either to replicate a modport definition in each and every
decoder of some kind, and the obvious location for this interface that supports that modport, or to enclose the
address decoder is in the interface itself. However, this modport in a small interface that is then instantiated in each
approach means that the interface must be specialized or interface that supports it.
parameterized for the address range of each connected
module. ACKNOWLEDGMENTS
An alternative, mirroring the approach taken by many The author is grateful to his employers Doulos Ltd for
bus-oriented hardware systems, is to perform address the time, facilities and encouragement they provided for this
decoding in the connected modules. Individual modules can work, and to his colleagues for consistently enlightening
then be parameterized for address range as part of the discussion.
configuration of a top-level design, and the bus fabric
Cliff Cummings acted as reviewer and provided valued
remains generic. However, readback multiplexers must
feedback.
nevertheless be located in the interface rather than the
connected modules. Activation of the select signals for such Many members of the SystemVerilog community have
multiplexers could, perhaps, be determined by the results of unwittingly provided helpful hints during informal
calling an address-matching function supplied by each discussions.
connected module. This is infeasible with current tools,
because it requires use of the export construct in the same
way as described above in connection with singleton
 REFERENCES
[1] IEEE Std.1800-2005. IEEE Standard for SystemVerilog – Unified
Hardware Design, Specification,and Verification Language.
[2] Jensen P, Kruse T, Ecker W, 2004. SystemVerilog in Use: First RTL
Synthesis Experiences with Focus on Interfaces. SNUG Europe,
2004.
[3] Bergeron J, Cerny E, Hunter A, Nightingale A. Verification
Methodology Manual for SystemVerilog. Springer 2005.
[4] Glasser, M et al. Advanced Verification Methodology Cookbook
version 2.0. Mentor Graphics Corporation, Wilsonville, Oregon,
2006.
[5] IEEE Std.1364-2005. IEEE Standard for Verilog Hardware
Desicription Language
[6] Sutherland, S. Modeling with SystemVerilog in a Synopsys
Synthesis Design Flow Using Leda, VCS, Design Compiler and
Formality. SNUG Europe, 2006.