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