Evan, > Well, if you're going to do that, I suppose you should at least have some coherent 'against' > arguments to add. I said I would be consolidating ALL arguments, i.e. both for AND against. > 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. With all due respect, I haven't yet seen a better and more concise way of describing the same thing. Perhaps you have something to add here, in which case I will be willing to listen. I always support better ways to do things, and if you have an idea on how you could achieve better conciseness and clarity with less confusion, please do share it here. I will be in education mode. -daniel On 28 March 2014 19:35, Ray Andraka, Andraka Consulting Group, Inc < ray@andraka.com> wrote: > 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. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Mar 28 05:31:40 2014
This archive was generated by hypermail 2.1.8 : Fri Mar 28 2014 - 05:32:05 PDT