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

I think it would be useful to start by getting some clarity on the
target market for all these new features. 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 are
people who design and "verify" FPGAs, but they generally don't do much
verification, and are happy with what VHDL or even Verilog currently
has. If you look at everybody else, you see a very clear division
between the engineers, who do the hardware in an HDL, and the
verification people, who are professional programmers, and who (in the
VHDL world) do verification in C, C++, or 'e'. If you've ever worked in
an organisation like this you'll know that there are very few people who
can do both. My own experience in an organisation that used Verilog and
'e' is that, of the Verilog guys who trained on 'e', maybe only 10 - 20%
ever used it in anger. The rest couldn't; they were engineers, and not
programmers, and didn't have the mindset for it (and 'e' is trivially
easy compared to C++).

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.

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. Adding OOP to VHDL is, to all intents and purposes, designing
a new language (unless, of course, you simply copy Ada, but I don't
think that would go down well in the market). There are some things that
could be done relatively easily (coverage, generators, a small standard
library), but OOP is not one of them. It's vastly complicated.

On to OOP and generics.

OOP:

----
The problem with OOP, quite apart from the implementation and market 
issues, is that it's got nothing to do with hardware (Niklaus Wirth did 
try with Lola, but Lola disappeared without trace). If you look at the 
history of programming languages over the past 60 or so years, you can 
see a clear progression in the development of type systems, from untyped 
or minimally-typed languages, through various levels of abstraction to 
current OO languages. Essentially, this was a progression from a 
function-based to a data-based paradigm; from a paradigm in which 
operations, or functions, are central and data is secondary, to one in 
which data, or objects, are central, and the operations on that data are 
secondary. For programmers, this has been incredibly useful. However, 
the problem here is that this progression is of no value whatsoever when 
describing electronic circuits. In the hardware world we are concerned 
precisely with the function-based paradigm. We care only about simple 
well-defined operations on data. Abstracting 'data' into a 'class' - 
where a 'class' has the properties of dynamic lookup, abstraction, 
subtyping, and inheritance - has no value in hardware design. As an 
engineer, I need a language which allows me to concisely describe basic 
operations on data. As a programmer, I already have access to maybe a 
dozen modern and excellent OO languages that can do the verification job 
properly.
Generics:
---------
Generic programming, on the other hand, is very useful in hardware 
design. Stroustrup defined this as "lifting algorithms and data 
structures from concrete examples to their most general and abstract 
form", which is precisely what I'd like to do in an HDL. VHDL's limited 
generics pre-2008 have always been one of its main strengths, and 
package generics can only make that better. It's difficult to see why 
you'd want to add any more to this, though. C++, for example, has 
generic class templates and function templates. Class templates aren't 
relevant without an entire class infrastructure, but generic functions 
might be of some use. Personally, I'd put the effort into more pressing 
features first.
-Evan
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.