1. Easier SystemVerilog with UVM: Taming the Beast
John Aynsley, Doulos

2. supported by all tool vendors
SystemVerilog
The language of choice
because it's a standard
For better or worse...
The language of choice for many companies because there are multiple implementations and companies are not tied to one vendor
Supported by all major tool vendors
Top-selling training class at Doulos
supported by all tool vendors

3. Large and complex SystemVerilog I'll quantify that in a minute
[Picture of the beast?]

4. Not simple, orthogonal, or consistent
SystemVerilog
Not simple, orthogonal, or consistent
Manages to violate all the principles of good language design that I studied in the 1980's

5. Several Languages in One?
Includes features from
Verilog
VHDL
PSL
Superlog
OpenVera C
C++
Java

6. Differences between implementations
SystemVerilog
Differences between implementations
Uneconomic to refine the definition SystemVerilog (the LRM) to the point where all implementations are consistent
Don't blame the tool vendors – they have other priorities! They've got businesses to run!
Don't blame anyone! It's just the way the market works. The market rejected other prettier solutions because they are in effect single-vendor.
and don't blame the vendors

7. Syntax Definition - VHDL

8. Syntax Definition - VHDL
24 pages

9. Syntax Definition - SystemVerilog

10. Syntax Definition - SystemVerilog
43 pages
Remark on the size of the SystemVerilog GRG

11. Syntax Definition VHDL C++ 1998 24 pages 18 pages 43 pages
SystemVerilog

12. Hard to Learn Verilog VHDL SystemVerilog (from scratch) UVM
Hard and time-consuming to learn
The reason SV is 5 days is the 5 day barrier. Need to assume Verilog knowledge, and need to be very selective which features we teach
To learn SV fully from scratch would be more like 8 days (though few do it in one hit)
Learning UVM is another 3 days, giving 8 days to convert from Verilog to SV+UVM
UVM

13. Enter UVM
[Picture of taming the beast]
Taming the Beast

14. UVM Enables verification IP reuse & captures best practice
Supported by all major vendors
Increased confidence to adopt SystemVerilog
Implementations now mutually consistent
Still need to avoid remaining pitfalls...
UVM enables VIP re-use and captures best practice
As a standard methodology supported by all major simulators, gives users increased confidence
Also, UVM gives an imperative for simulator vendors to create mutually consistent implementations
Still need to avoid the remaining pitfalls... addressed in the second half

15. Easier SystemVerilog Approach
Do use
Verilog
Concise RTL, for hardware synthesis
Features used by UVM – OOP and C-like
Features for constrained random verification
Features for interfacing test bench to DUT
We are all creatures of habit. Best to keep to a set of coding idioms that are known to work
Concise RTL only if you are doing synthesis. The paper says a bit more, but it is really outside the scope
Features used by UVM BCL are not sufficient: also need assertions, coverage, constraints, and interfaces
Also necessary to have an explicit list of features to avoid
Don't use
Features which are not portable

16. Used by the UVM BCL Packages All the class syntax (almost)
typedef, 2-state types, enums, (some) structs in classes
Strings, queues, associative and dynamic arrays
C-like procedural statements in methods
fork-join in methods
Pretty much everything associated with classes is now consistently implemented by all the simulators, thanks to UVM, with a few minor exceptions given later
There are some restrictions around structs, mentioned later
The commonality with C is a very positive thing, making SV easy to learn and natural to use
This is a simplified list – expanded in the paper

17. Idioms from the UVM BCL class C #(type T = int) extends BASE #(T);
Here are some quick-fire examples of coding idioms from the UVM BCL. By themselves they are not particularly exciting. The big deal is that each of these examples might very easily not have worked or not have been portable. But they do work, on all the main simulators
Having a type parameter to a class and passing that parameter to a superclass

18. Idioms from the UVM BCL begin classname::typename::method();
end
Inline instantiation of a parameterized class

19. Idioms from the UVM BCL if ($cast(to_handle, from_handle)) ...
Performing a polymorphic dynamic cast on object handles, and testing for success

20. Idioms from the UVM BCL begin static string blank = ""; ... end
classname q[$];
Declaring and initializing variables, including handles, at class scope (within a class) and block scope (within a method)

21. Idioms from the UVM BCL void’( obj.method() );
Using a void cast to throw away the value returned from a function

22. Idioms from the UVM BCL typedef enum bit { lit1 = 0, lit2 = 1 } name;
Enum types, including base types and initializers - within a class

23. Idioms from the UVM BCL string S; if (S == "")
S = {"pre", S.substr(expr1, expr2)};
Using strings, including the test for an empty string, the substr and len methods, and string concatenation

24. Idioms from the UVM BCL for (int i = 0; i < n; i++) ...
Here's an example of a C-like idiom that makes SV natural for C users (despite some annoying differences)

25. Idioms from the UVM BCL foreach (array[i]) ...
Use of foreach to iterate over arrays, associative arrays and queues

26. Idioms from the UVM BCL -> assoc_array[index].named_event;
Triggering a named event stored within an associative array

27. Idioms from the UVM BCL function void f ( ref uvm_component comps[$],
input uvm_component comp = null,
string arg = "");
Default argument values, ref arguments, object handles and queues as arguments

28. Used by UVM Applications
interface
clocking
modport
virtual interface
Handle in module scope
Module-class communication
assert
covergroup
rand member
randomize() with { ... }
constraint
Constrained random
A UVM application needs to use features absent from the UVM BCL itself
This list is simplified – see the paper for full details
There are only a few examples of array manipulation methods in the UVM BCL, but implementations are now robust and consistent (with one exception...). One example of a pitfall that's been covered over.
Array manipulation methods
Verilog!

29. Pitfalls
Pitfalls
[Picture of "pitfall" = banana skin]

30. Pitfalls Many features robust and portable
Remaining pitfalls cannot be simply described
UVM BCL side-steps some pitfalls
List of pitfalls is now short and getting shorter!
Areas where the vendors have not converged?
Great swathes of SV are now robust and portable
But the problematic corner cases cannot be reduced to any simple formula
The UVM BCL uses conditional compilation to avoid some features, and noticeably does not use other features (e.g. assignment patterns)
The list of corner cases is remarkably short, relative to the size of the language. A tribute to the implementers ...
... but has some notable areas where vendors have not converged
Don't blame the vendors! Market forces have got us where we are.
The list is getting shorter all the time
Let's be entirely practical here...
Here are some features to avoid right now ... then we'll ask what we can deduce from this list

31. Continuous Assignment to Handle
class C;
...
endclass
module top;
C handle1 = new;
C handle2;
assign handle2 = handle1;

32. Handles as Ports class C; ... endclass
module child1 (input C p, output C q);
module child2 (ref C p, ref C q);
Both cases cause issues. Best not to have handles as ports

33. Hierarchical Reference to Handle
class C;
...
endclass
module top;
modu inst ();
initial
inst.handle = new;
endmodule
module modu;
C handle;

34. Hierarchical Reference to Parameter
interface iface;
parameter int p = 8;
endinterface
module top;
iface iinst();
bit [iinst.p-1:0] vec;

35. Objects as Struct Members
byte a[];
} s1, s2;
initial
begin
s1.a = '{1, 2, 3, 4};
s2 = s1;
s1.a[0] = 5;
$display(s2.a[0]);
end
Got a dynamic array (or in general a handle) inside a struct, and then assign the struct. Is it a deep copy or a shallow copy? Tools disagree. Don't put handles (or dynamic arrays) in structs!
1 or 5?

36. Unpacked Unions typedef struct { bit a; byte b; } T1; byte c; bit d;
typedef union {
T1 p;
T2 q;
} U;

37. Bitstream Casting typedef struct { bit a; byte b; } T1; byte c; bit d;
module top;
T1 s1;
T2 s2;
initial
begin
s1 = '{1, 1};
s2 = T2'(s1);

38. Type Parameter Substitution
class C #(type T = ...);
typedef T::T2 T3;
static const int d = T::c;
endclass
class D;
typedef C #(C1) T;
static const int e = T::d;

39. Protected Constructor
class C;
protected function new;
...
endfunction

40. Array-to-Queue Assignment
begin
int da[];
int q[$];
da = '{1, 2, 3, 4};
q = da;
`define UVM_DA_TO_QUEUE(Q,DA)\
foreach (DA[idx]) Q.push_back(DA[idx]);

41. Iterator Index Query int a[]; int q[$]; a = '{0, 3, 2, 1, 4, 5, 7, 8};
q = a.find with ( item == item.index );

42. Statement Labels
initial
blk: begin
loop: repeat (8);
end: blk

43. Assignment as Side Effect
int i;
if ((i = 99))
$display("i is 99");

44. final final $display("The End at ", $time);
Use the UVM end-of-test mechanism - objections

45. wait fork 44 or 125? begin fork #44; #125; #14; join_none #2;
$display($time);
end
This one is in the UVM BCL!
44 or 125?

46. $get_coverage
initial
$display( $get_coverage );

47. Empty Coverpoint rand longint data; covergroup cg; coverpoint data {}
endgroup
There's some stupid stuff!

48. std::randomize begin byte unsigned a, b, c;
assert( randomize(a, b, c) );
assert( std::randomize(a, b, c) );

49. Prototype in modport modport mp (import function void hello());
modport mp (import hello);

50. Themes? Keep modules and classes separate?
No need for unpacked structs, unions, or arrays (other than Verilog memories)?
Several pitfalls can be traced back to the interaction between module-based and class-based features. Vendors have not felt the pressure to tidy this up. Maybe we want to keep modules and classes separate?
Several pitfalls can be traced to unpacked structs, unions, and arrays. Maybe these were not such a good idea in an HDVL?

51. Conclusions Do use Verilog! Synthesis-friendly RTL features
Classes (from UVM)
C-like features: data types and statements (from UVM)
Interfaces, virtual interfaces, clocking blocks
Assertions, coverage, constraints
Practical conclusion: Do use these features!
See the paper and the UVM source code for more details

52. UVM has tamed the beast! Conclusions
Theoretical conclusion: Yes! UVM has tamed the beast!