Re: [vhdl-200x] VHDL Testbench Enhancements

Jim Lewis wrote:
> Hi,
> The VHDL standards community has been considering whether
> to enhance VHDL to add advanced testbench features.
> 
> If you are a VHDL user,
>   Do you want these features added to VHDL?
>   Would you rather adopt a verification language that
>   already supports these (SystemVerilog, SystemC, E, Vera).
> 
> I think VHDL needs to enhance testbench capability to
> stay competitive.

My short answer:

- As a long-term VHDL user (most recently, a 1.6M gate ASIC in VHDL/c), 
the proposals do nothing for me

- As the likely project manager of an upcoming 20M+ gate ASIC (probably 
VHDL/C++/possibly 'e'), the proposals still do nothing for me

- As a part-time compiler writer, I can only express sympathy for anyone 
who has to implement these features on top of VHDL

My long answer:

I haven't read the Accellera proposals, since I don't believe that 
Accellera is the appropriate place to discuss an IEEE language.  Having 
said that, I have some general comments. Of course, I know that most, if 
not all of you, will disagree with these comments.

IMHO, creating a single language which attempts to combine both 'design' 
and 'verification' is fundamentally misguided, for many reasons. To 
start with, let's look at the people who are actually expected to use 
this chimera - in other words, the design and verification engineers:

1 - in most ASIC projects, different people carry out these activities, 
and they have very different skill sets;

2 - verification engineers are generally skilled programmers who do not 
appreciate being forced to use archaic HDLs to write software;

3 - verification engineers have no need for "design" features;

4 - Verification engineers are smart people who already know how to use 
sophisticated languages such as C++, Java, 'e', and so on;

5 - design engineers have no need for "verification" features (with the 
exceptions noted below), and do not generally have the skills to use 
them anyway;

6 - Verification engineers do not need to write VHDL to be able to 
access the internals of a model written in VHDL. There are simple and 
well-established ways to do this from a second language.

In other words, there is no *technical* argument for a combined 
language. There are, of course, some exceptions to the points above. The 
2 primary ones are:

a - Design engineers should be able to write temporal assertions. There 
is an argument for adding these to the basic language, although this is 
not essential.

b - A large number of engineers (most?) are involved in "simple" one-man 
projects, or work in very small teams, primarily in FPGA design. These 
people carry out both design and verification activities. However, 
almost without exception, they will have no use for randomisation, 
coverage, or temporal assertion features. They simply write testbenches 
in basic VHDL or Verilog. VHDL has failings which make life difficult 
for these engineers, but the proposals for high-level verification 
features do not address these failings. A simple 'printf' would be 
enough for many of them.

In other words, there is no obvious benefit to the *users* of a combined 
language (note, as an aside, that the arguments above apply equally to 
SystemVerilog and to the proposed VHDL++).

So who, exactly, is this proposal addressing? What is the value 
proposition of the combined language? Who does it benefit?

- I can't believe that the compiler writers want it. Bolting these 
features on top of a 1980's language would be a nightmare. And what 
about OO? Look at the *vast* amount of effort that was required to get 
C++ from C; we could never hope to manage this in the VHDL world. There 
just aren't enough potential customers.

- The small vendors don't want it. Producing a complete language with 
all these features is going to be very, very, difficult for new 
entrants, and will effectively lock them out of the market.

- It does nothing for project managers. We can already get design and 
verification solutions at low cost. And consider how much easier, and 
cheaper, it will be to hire skilled C++ programmers than to hire skilled 
VHDL++/SystemVerilog programmers.

What does that leave? If it's not already obvious, I'll tell you: it's a 
marketing proposal. The VHDL++ proposal exists because of SystemVerilog, 
and a perceived need to catch up. SystemVerilog exists for complex 
reasons, which can be boiled down as follows. EDA is a very small 
market, dominated by 3 vendors. Innovation is difficult, because of the 
small market size, existing domination, and the understandable 
reluctance of EDA tool users to entrust their multi-million-dollar 
project to unproved tools. To progress, the existing vendors have to 
rely on a standardisation process, domination of that process, and 
consolidation of existing technologies. It's all about maintaining 
market share, and locking out new entrants. The result was SystemVerilog.

Do you *really* want to do this to VHDL? If so, why don't you 
(belatedly) start with a properly-argued value proposition, rather than 
a list of features?

Evan Lavelle
Riverside

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.