Re: EXTERNAL: Re: [vhdl-200x] Clocked Shorthand Proposal - Need Consensus

From: Evan Lavelle <eml-vhdl-200x@cyconix.com>
Date: Fri Mar 28 2014 - 04:31:11 PDT
On 28/03/2014 10:09, Daniel Kho wrote:

> Anyway, I will be consolidating all your comments on the Twiki. Please feel
> free to add more if you hold a strong opinion.

Well, if you're going to do that, I suppose you should at least have 
some coherent 'against' arguments to add.

VHDL is an abstract language. It's power is that it *is* abstract, and 
has no knowledge of what are essentially artifical constructs, such as 
clocks, resets, and enables. The designer has to code in an abstract 
way, and the job of the synthesis vendors is to ensure that these 
abstract constructs, or some subset of them, can be implemented.

This is not simply a philosophical argument. Many of you will remember 
that there was a lot of argument in the 80's and 90's about delta 
delays, and whether they were necessary to describe hardware. Verilog 
tried to avoid these issues by being less abstract than VHDL; it didn't 
have NBAs, and had dedicated register 'types', and so on. It didn't 
work, and it tooks years of retro-fitting and re-education to make the 
language usable. This never happened with VHDL, because it was properly 
defined, at an abstract level, from the start. This didn't make VHDL any 
less synthesisable: 'abstract' constructs, such as 
attribute-initialisation functions, and recursive functions, were 
synthesisable in VHDL long before they were included in Verilog.

This proposal breaks the clean and abstract nature of VHDL, for no other 
reason than to "reduce the amount of typing". It adds nothing to the 
language that cannot already be expressed relatively concisely. It adds 
confusion for designers, who have a new way to do the same thing, and 
for synthesis vendors, who have to deal with two, potentially 
conflicting, sets of instructions to follow. It adds more potential 
sources of error in the language definition. The new constructs may not 
even be implemented by synthesis vendors; and, if they are implemented, 
users will have to wait years for them.

And, of course, there are far better ways to 'reduce typing' in VHDL, 
which do not change anything apart from the front-end syntax. The 
language could simply be 're-skinned' with trivial changes to 
implementation tools, to give it a much more modern and concise look.

As a final note (not for the wiki!), I'll just add to Andy's comment 
about Abel (as I've written a compiler for a language which is 
essentially Abel++). HDLs come in a range, from fully abstract, through 
to what is essentially fully implementation-constricted, such as Abel. 
There's no such thing as one-size-fits-all in HDL design. You start with 
a philosophy, you get it right, and you stick with it. If it turns out 
that you got it wrong, don't waste everyone's time by trying to fix it - 
move on, and get it right next time. I sometimes wonder what we'd have 
now if everyone who was involved with tinkering with Verilog and VHDL 
over the years had simply sat down and defined a language for this 
century, rather than the last one.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Mar 28 04:31:34 2014

This archive was generated by hypermail 2.1.8 : Fri Mar 28 2014 - 04:31:53 PDT