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