Subject: Re: $sv-ec Re: SV_EC September4,02 testbench discussion presentation
From: Alec Stanculescu (alec@fintronic.com)
Date: Fri Sep 06 2002 - 09:41:34 PDT
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 - 10:39:43 PDT