( ESNUG 502 Item 5 ) -------------------------------------------- [04/19/12]
Editor's Note: Wow! MENT declares SV has "won" then pushes how
to migrate *out* of Specman "e". Talk about chutzpah! - John
Subject: Ballsy MENT marketing promotes migrating from Specman "e" to SV
> From the program, it appears that DVcon heavily favored Synopsys
> System Verilog over Cadence Specman "e". While they're both
> commonly used verification languages, DVcon'12 had plenty of panels,
> papers, and tutorials focused on UVM with System Verilog, but
> DVcon'12 had only 1 paper on "e" -- and it was on how to migrate from
> Specman "e" to System Verilog.
>
> - from http://www.deepchip.com/items/0500-02.html
From: Avidan Efody <avidan_efody=user domain=mentor not calm>
Hi, John,
Enclosed in the paper Brett Cline mentioned that Mike Horn and I presented
at the recent DVcon'12 conference. Our paper, titled:
"e/eRM to System Verilog/UVM: Mind the Gap but Don't Miss the Train"
which I wrote together with Mike Horn, was intended to be the one thing I
didn't have when I started "e" to SV migrating myself a few years back.
(In 2006 we had some dictionary-like papers and documents that allowed
us to partially map constructs from one language to another. We also had
one paper by janick Bergeron of Synopsys titled:
"System Verilog for e Experts: Understanding the Migration Process"
which was written at a somewhat higher level and concentrated on technical
differences like AOP or "WHEN inheritance".)
However, nothing at the time had an actual testbench and didn't really help
verification engineers figure out if BFMs, scoreboards, coverage collectors,
random generators, etc. they were coding in "e" were going to require a
totally different thinking in SV, or just mechanical translation work.
We often found ourselves coding a few 100's of lines of "e" code, only to
find out at the end when translating to SV, that something we dismissed as
a mere technical issue actually had more significant consequences.
Jump to now.
System Verilog and UVM are standard. OVM and UVM have created a Specman "e"
haze over System Verilog in quite a few areas and most parts of a typical
testbench look very similar whether written in Specman "e" or SV. The
sequence architecture has been copied, for better or worse, from eRM to UVM.
Ports, unless used to connect to RTL signals, map nicely to UVM's TLM lib.
BFMs are an area where all a user would need do is a simple syntax switch.
Same goes for scoreboards that normally take around 50% of a project and
remain as difficult to write; and for coverage models.
So where should users expect differences between Specman "e" and SV? The
structure of a testbench. Specman "e" has:
1.) AOP, which mainly influences testbench/test-case separation.
2.) Memory allocation during randomization, which affects anything
random -- in a typical testbench that would mainly be random
configuration and random transactions.
3.) The way testbench and DUT are connected together, which affects
assertion checkers and anything that needs to reference RTL signals.
Although our paper refers to "WHEN inheritance", I intentionally left it out
here, because I now see it is a special case of "memory allocation during
randomization".
Generic capabilities such as "macros" and "reflection", we also left out
because they normally have a marginal affect on a verification environment.
SPECMAN "E" AOP:
AOP has proved itself quite useful for creating better separated testbenches
and test-cases, which is why the "factory" was introduced into OVM, and
taken from there almost as is into UVM. Although the factory is in my eyes
a sufficient solution, it requires some more planning upfront than AOP does.
To cite our own paper:
"A well planned Specman "e" testbench will have some parts that are easy
to extend and override (the API), and some that require significant
effort. A well planned System Verilog testbench will have some parts
that are easy to extend and override, and other parts that can't be
since they're outside the API".
The factory will also not replace all the features of AOP. For example, it
won't help users implement "orthogonal" base class extensions. According to
Janick's paper, such "orthogonal" extensions could be implemented in System
Verilog testbenches by using the "facade" design pattern. (We implemented
an example that shows how this is done with the uvm_component base class,
but, will be the first to admit that it won't allow for the same flexibility
as real AOP.) In poetic justice, however, this missing flexibility in SV is
probably mostly felt by the UVM committee itself and, to a lesser degree by
big company methodology teams. In a real SV project, where requirements for
base class extensions is manageable, this is never a real issue.
SPECMAN "E" MEM ALLOCATION DURING RANDOMIZATION:
Memory allocation during randomization is a seemingly technical difference
between Specman "e" and System Verilog which has wide reaching consequences.
Simply put, while Specman "e" allocates structs and units during generation
of a parent struct or unit, System Verilog doesn't allocate classes during
randomization of a parent class. (Read our paper to understand the details
but two areas where this pops up are: when you want to randomly generate
several subtypes of a same base type -- say various packet types; or when
a random class contains an array of random size of other random classes.)
There's no magic solution that will allow System Verilog users do things in
exactly the same way as Specman "e" here, but our paper gives alternatives
and discusses in depth their respective merits and shortcomings.
From my experience, awareness of this issue is already half of the solution.
SPECMAN "E" CONNECTING TO A DUT:
Finally Specman "e" and System Verilog have different ways of connecting to
a DUT. With "e", ports and temporal expressions are natively integrated
into units, while with System Verilog their natural habitat is "interfaces",
which are accessed from classes through a sort of hybrid creature called
"virtual interface". This means there are a few limits on signals and
assertions which Specman "e" users sometime find hard to put up with:
1. signal paths are determined at compile-time rather than runtime.
2. signal maps can't be extended through inheritance.
3. assertions can't easily look at testbench state and config values.
During the work on our paper we created the "Mentor eRM to UVM Migration
Kit" that automatically spits out testbench-DUT connection code, in much
the same way as Specman "e", and therefore solves #1 and #2 above. The
migrating Specman "e" users I tested it with just love it.
As for #3, the limitation on assertions, some workarounds are available,
but none that I know of is perfect and all have to be tailored according
to the requirements of the testbench in question.
WHY MIGRATE TO SYSTEM VERILOG?
I guess an Specman "e" user reading through this might go "Why bother?
Why migrate at all if I can't have AOP, random generation and assertions
just the way I used to?". It's because the battle "e" vs. SV is really
over and System Verilog has won. It's time to catch up with the rest
of the world.
- Avidan Efody
Mentor Graphics Israel
Editor's Note: Mike and Avidan's DVcon'12 paper plus the Mentor
eRM to UVM Migration Kit are #66 in DeepChip Downloads. - John
Join
Index
Next->Item
|
|
