( ESNUG 366 Item 12 ) -------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #8 ) Superlog, Verisity E-lite, and Avery VCK
> 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.
>
> - Martin d'Anjou
> Nortel Networks
From: David Duxstad <dduxstad@mn.rr.com>
John,
Martin d'Anjou's posting (ESNUG 365 #8) on Superlog vs. E-lite was a good
read. While I agree that less lines of code is a critical factor, E-lite
isn't the only way to achieve that goal. Lately, I've been working with
VCK from Avery Design Systems. It has most all the features that are
"missing" from Superlog and is based on Verilog. It adds extensions to
Verilog (called VLE) that support robust random number generators, lists,
temporal checking, functional and code coverage functions, and records.
Since the syntax for these extensions in VCK is based on Verilog, there
is no need to learn another language. Avery plans to propose these
extensions to OVI in the near future, so they will not be proprietary.
d'Anjou presents a simple expect function that is coded in a few lines.
The function is to detect a change in "y" from n1 to n2 cycles after a
change in "x". Here's that same expect function in VCK:
initial
begin
e_handle = $expect( value_change(y),,go_fail(n1,n2), n1:n2,posedge clock);
end
always @(x) $expect_trigger(e_handle);
task go_fail;
input n1,n2;
integer n1,n2;
$display("Check failed: y did not occur within %d to %d cycles after x",
n1,n2);
endtask
task value_change;
input my_input;
@(my_input);
endtask
And while the use of tasks in the $expect() function may make this code
slightly more wordy than the E-lite example, the code is just as powerful,
if not more powerful, and easier to read. And, it was all done in Verilog.
Additionally, Avery has created a cool C/C++ API that allows you to write
much of your verification code in a higher level language that is very well
supported by the open software folks. I use GNU gcc and DDD on Linux for
my C coding and debug and it works very well.
The verification code that I've been working on makes extensive use of what
they call the VCI channel. With this VCI channel, communication between
the C process and Verilog is done over a TCP-IP link. This allows me to
run the C process on a separate machine, freeing up CPU resources for the
Verilog simulation. Alternatively, you can used a shared memory scheme
on the same machine if you like, it just depends on the simulation
environment you are trying to set up.
I'm a big believer in standards and non-proprietary languages and I think
those are essential for IP/SOC designs coming our way. Verification of
SOCs is difficult enough without the added complexity caused by the
introduction of proprietary languages.
- David Duxstad
Duxstad Consulting
---- ---- ---- ---- ---- ---- ----
From: [ Roger Rabbit ]
John,
Keep this anonymous. I don't want Verisity people calling me any more.
A while ago I was involved in the evaluation of Specman for a project. It
seemed to be right down the tools alley. I had written a PERL script that
generated address and data for a processor BFM using random rule sets.
This generated a Verilog task call sequence and the BFM would execute this.
It was self checking, as you could write rules for register and memory
accesses. This took a little more than a day to write and it was very
extensible. Verisity wanted to demonstrate their power, so I gave them the
PERL and a overview of the driver. It took better than a week to get the
code.
Now, this doesn't mean that the person writing the code took a week, or
perhaps he didn't understand the concepts, although this was in the same
class of operations as their demo was. The time from when I gave them
the task to when the completed the task was over a week.
Needless to say, I haven't been a huge fan of Specman, it works, we have
groups here that use it on designs, most using contractors to code the "e".
I find "e" to be very different from Verilog and even VHDL which produces
a large learning curve. I had great hopes for Superlog, it is an extension
of the Verilog language which makes learning it additive, but it seems that
some people are finding holes in the language. I have three questions for
the general population and perhaps this would be of interest to others.
1. Is Specman the state of the art, can Superlog measure up, is neither
the answer?
2. Is this the rebirth of the "Verilog is better, no VHDL is better" wars?
3. Has anyone heard of, or tried the PERL linkage tool from NelSim
http://www.nelsim.com/ ?
We can do some interesting things with PERL right now and extending that
would be great.
- [ Roger Rabbit ]
|
|
