{Spam?} RE: EXTERNAL: Re: [vhdl-200x] Clocked Shorthand Proposal - Need Consensus

As one of the originators of this proposal, I want to clarify a few things.

Pipelining was not the original intent, but it is a nice addition.  My original intent for this proposal was to suggest an intentional way to create a clocked process.  After reading a few chapters of a VHDL book, I had the basic syntax down and was ready to start experimenting.  I had to walk across the aisle to a co-worker to ask, "How do I create a flip-flop?"  He showed me how and explained how those 10 lines of code matched the behavior of the flip-flop I wanted.  I use a good editor (Emacs) so most of those 10 lines of code are created for me automatically.  Consequently, there is very little typing to be saved in my case.

I understand and appreciate that VHDL is an abstract language.  I like it that way!  

Most of the time.  VHDL is also a *hardware* language.  Why else would we have a boolean type and then three more types to express a bit?

I'm coming at this from the perspective of, "What might we be able to improve in VHDL?"  I am most productive when the language I'm using supports more direct ways to express the algorithm/block diagram in my head.  That's why I got involved with the last VHDL revision: the unconstrained array elements and fixed-point library significantly improve my ability to express my design intent.  So I asked the question, "What is a VHDL-like way to intentionally create a clocked process?"  Syntax option 3 [http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ClockedShorthand#Syntax_Option_3] is my best answer.  This is a hardware question, so it's valid to ask of a hardware language.

The motivation is, to abuse Amdahl's law, "Make the common case obvious."  At least 80% of the processes I write are clocked.  (The vast majority of the rest are to convert types or reformat signals between blocks in structural code.)  If the vast majority of the processes I write infer synchronous logic, why do I have to write my code in a roundabout way -- hoping that the synthesis tool figures out what I want?

I also agree with (most of) Evan's arguments.  There is power in the Python credo, "There should be one -- and preferably only one -- obvious way to do it."  Already in VHDL there are at least 4 ways to infer a flip-flop precisely because VHDL is abstract.  I would rather not create another.  Still, none of the current methods (to me) express the "I want to create a flip-flop" intent.  So now we have some potential syntax alternatives to discuss.

The point is not that these things can't be done in the current language.  The question is whether the benefit of an intentional clocked process is worth the work, duplication, delay, and tools headache required to add it to the language.  And I agree that part of the discussion and decision should be how consistent it is with the current language.  

- Ryan

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Evan Lavelle
Sent: Friday, March 28, 2014 5:31 AM
To: vhdl-200x@eda.org
Subject: Re: EXTERNAL: Re: [vhdl-200x] Clocked Shorthand Proposal - Need Consensus

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.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.