Re: [vhdl-200x] Why OOP vs Generics

Evan's thoughtful comments should be required reading for everyone
working on this. I couldn't agree more with his conclusion that adding
OO to VHDL, at this late stage, would be a disastrous waste of work.

There are a couple of things he says that I'd like to challenge,
or at least to question, though.

Will VHDL200x be used by engineers, or programmers? People designing
> circuits, or verifying them? These aren't the same people, except in very
> limited cases.

There's certainly some truth in that, but I know plenty of folk who do
bridge that divide successfully; and I'd like to think that the number
will increase. Designers being aware of verification issues, and
vice versa, can only be a good thing.

In any case, it's quite odd to suggest that it's bad for a language to
serve many different user groups in the same sphere of activity.
People write device drivers, compilers, libraries and applications in
C++;the required skills differ at least as widely as they do between
verification and RTL design.

> The real-world lesson, IMHO, is that one size does not fit all in EDA.
> There's no point adding fancy modern programming features to antiquated
> 1980's HDLs, because the result is not going to please anybody. The
> engineers get features that they don't understand and won't use, and the
> programmers get a clunky retrofit on top of an unusable base language. The
> only winners are the EDA vendors, as everyone has to go through yet another
> replacement cycle. If this sounds familiar, then it's because this is
> exactly what has been happening with SystemVerilog over the last few years.
>

That's a soft target, and there's a lot of truth in the accusation.
However, I don't think it's quite that simple. With the obvious
disclaimer that I'm pretty heavily invested in SystemVerilog
myself, let's highlight the fact that general purpose programming
languages mostly aren't adequate for verification. Constrained
randomization is an obvious example of something that is well
supported by 'e' and SV, but is utterly painful in C++ (anyone
tried SCV?). Coverage could be done in any language with
sufficiently rich introspection facilities, but it's so much easier
if the language provides the functionality "out of the box".

> You also have to consider something else, which is that designing new
> languages is not, by any stretch of the imagination, easy. It's also, with
> all due respect, not something that can be done by an IEEE committee.

Indeed, IEEE committees are not supposed to invent anything,
but merely to standardise something that's already proven.

> As a programmer, I already have access to maybe a dozen modern and
> excellent OO languages that can do the verification job properly.
>

I disagree; there are *some* verification tasks (notably modelling)
that can be well and elegantly done in mainstream OO languages,
but constrained-random and a few other things really demand a
language that has some domain-specific features. Or, perhaps,
a language that is truly extensible to add such features; C++
and Java really don't cut it there, but it's interesting that the
modern scripting languages probably come closer to what you
need. (Oh, did I mention introspection?) So I find your "dozen"
hard to accept. But we have 'e', which is pretty darned good,
and SV which, despite its many flaws, has real advantages in
a few areas.

There's a "dream ticket" here, much undervalued in the industry
but cherished by those in the know: VHDL for design, 'e' for
verification. Can't you talk with the 1647 folks, divvy the work
up between you, and set an expert team to work on making the
interface between them as smooth as you are able? There are
some fairly easy things that could be done at the language
interface that would bring killer advantages. Just one example:
allow 'e' to be fired up first, before VHDL elaboration; use 'e'
randomization to build a DUT configuration by randomizing
top-level generic values; allow the 'e' testbench then to run
VHDL elaboration before starting to simulate. No-one can
do that in SV - you need to enlist the help of scripting and
multiple runs of a testbench.

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