RE: $sv-ec Re: SV_EC September4,02 testbench discussion presentation


Subject: RE: $sv-ec Re: SV_EC September4,02 testbench discussion presentation
From: David W. Smith (david.smith@synopsys.com)
Date: Fri Sep 06 2002 - 11:20:40 PDT


This is the beginning of a good discussion.

While you have made definitive statements with respect to one language
or not I believe that the answer to this question is not as simple or
clear-cut as your responses indicate. A case can be made that having a
single language is much easier for the end-user, language features that
have been described have value as part of the verification language in
addition to the testbench, there is a clear separation (within the
donation) between testbench functionality and system description, etc...

I think it is important to review what the agreed upon mission statement
of the committee. In the Operating Guidelines published on the web site
(http://www.eda.org/sv-ec/Operating_Guidelines.txt) the mission
statement states:

        "Extend the Verilog language to system design and for testbench
using a single syntax."

So, the issue of extending Verilog to support testbench was already
agreed to early on. The merits of this can be argued by both sides and
would make for an interesting discussion. Being that we have already
decided it at this point it is more relevant to ask if the approach that
has been donated is an appropriate way of extending Verilog to do
testbench design (or at least in the correct direction).

I am definitely not trying to take sides in this discussion. My intent
is to help us move forward based on decisions we have already made and
the material in front of us.

Regards
David

David W. Smith
Synopsys Scientist

Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124

Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
http://www.synopsys.com

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Alec
Stanculescu
Sent: Friday, September 06, 2002 9:42 AM
To: fm@cadence.com
Cc: sv-ec@eda.org
Subject: Re: $sv-ec Re: SV_EC September4,02 testbench discussion
presentation

Francoise,

Your questions are excellent and should help us verbalize what we want
to do next.

Definitely, as Vassilios pointed out, the scope of our Committee
includes the testing of hardware descriptions. However, you are right
that separating the two "languages" (i.e. hardware description and
testing) is supported both by history and by the power of the "divide
and conquer" paradigm. There is no reason to burden one language with
useless features of the other.

Of course, it would be nice (as pointed by Arthuro Salz) that constructs
having the same semantics should have the same syntax in both languages
in order to facilitate the learning of these languages. This, however,
is secondary to keeping the languages as simple as possible.

So, in designing System Verilog we should develop a testing language
that, very much like Vera, is (1) well integrated with the hardware
description part, and (2) can be used only in the scope of "testing
modules" or "programs" as they are refered to in Vera.

I will attempt below to answer your questions.

> These answers will guide me to picture and judge how we can design a

> language which can be adequate for testing and hardware design.
>
> 1. Is it necessary for a hardware description language which is used
for
> design to contain language constructs for testing?
> Should SV contain everything for testing purpose, or should SV
only
> contain provision to
> integrate easily with a testbench program?
>
> 2. would the engineer who uses SV for designing his system also be
the same
> engineer who writes the tests?
>
In general the answer is NO.

> 3. Should'nt a testbench language be HDL independent?
>
YES
> note: VERA has many language independent features (classes, lists,
process
> threads...) modifying VERA syntax and semantics to fit within SV may

> conflict with that requirement.
>
VERA is independent of Verilog and has a good interface (which can be
improved) to Verilog.

> 4. Shouldn't the testbench program/module be completely separated
from the
> HDL design?
YES, as it is the case with Vera.

> If not, what are the advantages of embedding the tests in the
design?
> I see the disadvantage that it would require the design to be
> recompiled every time I
> want to use a new test program.
>
One could go around this particular problem by using fileIO (readmemh in
Verilog). However, there are many more disadvantages.
> 5. What are the various kinds/types/scenarios of tests that one may
want to
> do and that the language should support? Do they have different
scope?
>
Testing uses different means than hardware design to achieve its goals.
The two languages should already be much different and will evolve in
different directions in the future.

> 6. VHDL and Verilog and also PLI have been used for writing
testbenches,
> what were their weaknesses and strengths in their testing
capabilities?
> Is SV or VERA addressing these?
>
It is very seldom that one achieves to kill two birds with one stone. It
is more often that the one who attempts to grab too much ends up holding
very little (qui trop embrasse ...)

It is not necessary to impose the restrictions comming with hardware
description languages on testing languages, and it is not necessary to
provide hardware description languages with unsinthesizable features
that ultimately create only confusion in hardware design. It is not
necessary, but it is possible though ...

PLI was an excellent interface that allowed tools such as Vera and
Specman to be interfaced to Verilog Simulators. Direct C interfaces as
well as extensions to the VCD interface represent improvements over PLI
and will allow even better testing tools to be developed in the future.

> There may be more questions but these are the first ones which came
up to me.
> I would really appreciate if some people could share their opinions
and provide
> some answers to my questions.
>
> Francoise
> '
>
Best regards,

Alec Stanculescu



This archive was generated by hypermail 2b28 : Fri Sep 06 2002 - 11:23:10 PDT