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

On 19/03/2011 12:25, Jonathan Bromley wrote:

> 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.

I think it would be a great idea to have one language serving multiple
user groups, if it was possible for the language to do it, and the
requirements of group A didn't adversely affect group B, to such a point
that the language became a camel rather than two horses. Sure, C++ can
do this for compilers, libraries, and apps, but can VHDL++ do this for
both electronic design and verification?

[not directed at JB, but at those of you who want to build VHDL++]... I
did think for several years that VHDL was great precisely because it did
serve multiple groups, until I started using 'e' for verification (and,
later, C/C++/TestBuilder).

My own view now is that the requirements of electronic and verification
engineers are so widely separated that it just doesn't make sense to try
to shoehorn everything into one language. The EEs require a language
which is (1) structural, and (2) procedural/imperative, and (3) highly
parallel, and (4) intimately concerned with time. In short, an
incredibly specialised language, ie. VHDL or Verilog. It also needs to
be simple - look at the success of Verilog, which has managed to survive
and prosper over 25 years, despite having no coherent type system.

The verification guys have no interest in (1) structural [Wirth tried to
implement the structural aspects of an HDL as a class hierarchy in Lola,
but it was klunky]. They've also moved on from (2) procedural to
OOP/AOP. Are they even that interested in (3) highly parallel and (4)
time? They can get the parallelism they need from threads, rather than
processes, and I don't think they're even that concerned with time
beyond getting a look in on every cycle. In fact, when you're writing
verification code, once you've done the one-off basic low-level
communication with the DUT, everything else you do is completely
unrelated to the HDL/process/time/"electronics"/paradigm - it's all
verification plans, functional coverage, closure, temporal assertions,
directed generation, scoreboarding, and so on. Anyone who thinks that
VHDL should be retro-fitted with all this stuff needs to make a very,
very, good case for it.

> 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.

I agree with you, of course; I didn't make myself clear. What I should
have said was that there were lots of modern languages that could handle
the overall language infrastructure - OO, for example. You have to add
temporal assertions, coverage, and generation either to the language
itself (logical) or to VHDL (not so logical). Incidentally, I have done
constrained-random with C++ and TestBuilder, some years ago, but it was
pretty trivial compared to 'e'.

But...

> 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?

would be much better.

-Evan

[unrelated, but on the issue of how much use "generic functions"
actually are, and on whether they're worth implementing. The C++ code
I'm currently writing, which is a 96K-line compiler, has exactly one
simple instance of a function template in it. It's a great idea but, in
practice, perhaps not very valuable].

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