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

From: Ray Andraka, Andraka Consulting Group, Inc <ray@andraka.com>
Date: Fri Mar 28 2014 - 04:35:29 PDT
Amen.  Thank you Evan.

On 3/28/2014 7:31 AM, Evan Lavelle wrote:
> 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.
>
>


-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

   "They that give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety."
                                            -Benjamin Franklin, 1759
  


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

This archive was generated by hypermail 2.1.8 : Fri Mar 28 2014 - 04:35:49 PDT