( ESNUG 365 Item 8 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 363 #8 ) No, Janick Was Right; Verilog & Superlog Do Suck
> I enjoyed reading Janick Bergeron's piece in ESNUG, "Janick Pisses On
> Superlog". Janick writes superbly and his pieces are really
> entertaining. Still, I believe this time he went over the edge.
>
> Hardware verification languages are evolutionary not revolutionary as
> he stated.
>
> - Lauro Rizzatti
> Get2Chip
From: "Martin d'Anjou" <mdanjou@nortelnetworks.com>
John,
I must admit that I agree with Janick's point of view regarding Superlog.
Superlog provides nice features like re-entrant tasks, which opens the door
to powerful constructs like recursion and concurent calls, but fails to take
the verification effort beyond the current dead-end path of verilog: lack of
OO, lack of proper random generators, lack of temporal checking and
lack of functional coverage specification description to name a few. The
problem with Verilog is its simplistic linear procedural nature. Easy to
understand: yes. Easy to solve verification challenges: no. Is Superlog
helping: not enough because it completely misses the boat on the OO
technology. Superlog proponents bet that we will not need OO to verify
chips.
In Verilog, we wrote 4500 lines of code to describe our packet generators.
In Verisity E-lite I have written 500 lines of code (comments included) and
I support two more packet types than the Verilog solution. That's 9X less
code. Thanks to OO and built-in directed random generators. Superlog does
not embrace OO and does not have the powerful built-in generator E-lite has.
It would not have helped me much here.
With OO, we describe our packet generators and "augment" them with new
fields and new properties later. Using typical Verilog include
statements does not work because includes have to be in the older code
already, and includes blindly add code to existing modules. If Verilog
or Superlog were OO they would let you "re-open" an already defined
module in another file subsequently loaded in the compile process
without even touching the original one, and either append, pre-pend,
add new i/os or new tasks, or replace tasks, or just anything you
want. Superlog does not even bring C++ OO features to verilog.
High level constructs like lists are poorly supported by most languages
and rely on external libraries, except in E-lite. You can have a list
of almost any type in E-lite, not just unsigned integers or bytes. Lists
have been around for decades and people still think they have to build
their own libraries for them. I disagree with that. Come up with a
language that has lists built right into it, not the other way around.
Checking functional timing requirement always involves writing complex
procedure in Verilog. Superlog does not help me as much as E-lite on
this matter. In E-lite I need one line of code for most checks:
// Using the english to temporal expression dictionary
// in the Verification Advisor:
expect @X => {[N1-1..N2-1]; @Y} @clock
else dut_error("Check failed: Y did not occur within", N1, " to ",
N2," cycles after X");
Where are the powerful random generators in Superlog? In E-lite, I just:
// Apply a range to ethernet packets, will not affect other packet types
extend ethernet packet {
keep address in [FFFF_0000_0000..FFFF_FFFF_FFFF];
keep soft address == select {
5 : [FFFF_FFFF_F000..FFFF_FFFF_FF00];
2 : others; // "pass", "edges" are "other" are keywords that can
// be used here depending on what you need
};
};
Voila! The address field is self generating and restricted to an
interesting range for my test case but it can still take, 2/7 of the
time, another address in a wider range. You need complete procedures in
Superlog to do what you can do in a few lines of Elite code.
On the functional coverage side, we've traditionnaly been relying on a
mix of verification plan reviews, code coverage tools and code reviews
to decide whether we had covered all the features, and exercized them
to our satisfaction.
E-lite lets you *measure* functional coverage. You can actually measure
coverage items, like the input stimulus distribution. I do not see
that built-in into Superlog. You can attempt to do it though. You
will spend a tremendous amount of time creating routines to define,
count and classify coverage items. That's what Janick means when he
talks about statistics collection. Routines that run in the background
and collect the data you ask for in bins, and cross-correlate the
collected data together.
Simulation speed? The problem is to write testbenches, not the time it
takes to run them. We've built an LSF cluster of about 100 CPUs, and
we intentionnaly keep each testbench small enough to run overnight.
Testbench too long? Split it and add CPUs. The goal is to run
regression overnight, and we are far from using all our CPUs.
Some clever people have solved many problems in ASIC verification. Of
course this requries new thinking, new approach, new language. The
problem is we are so used to model our world using procedural languages
that we can't imagine any other way to model it. Yet we know the
limitations imposed by current HDLs, and it is not a question of learning
a new syntax, it is a question of spending time to learn a different way of
modeling a verification environment. You know a new language has become a
necessity when you can't easily model and structure your code the way you
picture it in your mind, easily and concisely, with the language you
already know.
Get more done, write less code. It's the only way to keep up with
Moore's law.
- Martin d'Anjou
Nortel Networks
|
|
