TOLEDO'97

Tutorial M-B:
VHDL Lite - How VHDL Can Be Slimmed Down

Speakers

Abstracts

In this tutorial the authors, examine a number of superfluous features that can be removed from VHDL without harming its usefulness. For each of these superfluous language features, a discussion will be given as to why they were put in the language in the first place and why they ought to be removed.

When VHDL was first standardized by the IEEE in 1987, one of the complaints most frequently heard was that it was "too complex" to be usable. Part of this complexity was "merely" syntactical, an inheritance from Ada and the Ada-like philosophy of letting nothing be implicit in a description. This sort of complexity, while non-trivial, could be worked around by using, for example, a smart text editor.

However, much of the complexity in VHDL was inherent in its semantics. Indeed, much of the work done by the IEEE VASG (the group which standardized VHDL) between 1987 and 1992 can be viewed as an attempt to make sense of the original semantics of the language. This situation of semantical ambiguity lead not only to conflicts in the various VHDL simulation tools, but also, perhaps more importantly, to confusion on the part of users and for many users a real distaste for VHDL.

Then came VHDL 1993. The VASG can be safely said (in hindsight) to have taken exactly the wrong tact in its restandardization process. The committee should have concentrated on cleaning up the language, repairing broken syntax, establishing consistent semantical interpretations, eliminating redundant language features, etc. Instead, the VASG, while it did clean up some of the semantical confusions left after 1987, spent most of its time adding new features and removing virtually none.

Many reasons could be put forward to explain this seemingly self-destructive behavior on the part of the VASG. However, its effect lives on in the fact that -three years after the fact- only one vendor has completely implement VHDL 1993, while one or two others have partial implementations, and most have simply ignored the new language. In short, there appears to have been a judgment that VHDL 1993 does not deliver enough in desired features to justify the high price of implementing it. This is, of course, a decision made by EDA vendors, but it is one seconded by the general apathy of the user community -there just is no outcry for VHDL'93.

This might be of merely historical interest, except that the past mistakes are presently not merely being repeated -they are being embellished upon. Since 1993, new VHDL-related standards have been started which build on top of (Analog VHDL), on the side of (the various VHDL packages, VITAL, Synthesis, etc.) and within VHDL (Shared variables) 1993. At the same time the VASG, including the subgroup that rules on syntactical and semnatical aberrations, has become dormant. To top all of this off, VHDL 1998 -yet another opportunity for revision- is fast approaching.

However, VHDL 1998, while it could end up as another disaster, the unused VHDL 1993 morass might end up even more cluttered, can also serve as a point of some hope. Specifically, the coming of VHDL 1998 affords the VHDL community the opportunity to correct some of the mistakes of the past. Indeed, the new restandardization activity can be used to both clean up remaining syntactical and semnatical ambiguities in the language, and, more importantly, to remove unused and/or redundant features from the language.

In this tutorial the authors, who have a combined experience of 33 years of participant and leadership in the VHDL-world, examine a number of superfluous features that can be removed from VHDL without harming its usefulness. For each of these superfluous language features, a discussion will be given as to why they were put in the language in the first place and why they ought to be removed. Copious examples of each features (and alternatives) uses will be given, and the audience will be invited to provide their input on the subject.

This tutorial may be considered to be a first "shot over the bow" in the VHDL 1998 wars. The authors care about VHDL's future, but are very worried about what they see as its lack of future. Put simply, if the apathy shown regarding VHDL 1993 continues towards VHDL 1998, there may not be a need for VHDL 2003.


ifip@it.uc3m.es