Re: [vhdl-200x] VHDL enhancements wish list

On the topic of FFs, I would encourage the use of a model practiced by
Verilog (also SystemVerilog) for many years. Specifically,
// SystemVerilog
always_ff @ (posedge clk, negedge reset_n)
  if (!reset_n) state <= 4'b0000; // async reset
  else state <= state + 1'b1;

Thus, the always_ff block is sensitieve to posedge clk or to negedge
reset_n.
This model is currently being used by synthesis vendors. It would be more
elegant to align VHDL to that model, with the proper syntax for VHDL. Thus,
it could look something like:
*process_ff *(posedge clk, negedge reset_n) *is*
*begin*
   *if (not *reset_n) *then *q<='0';
   *else *q<=d;
   *end if*;
*end process*;

For the combinational logic, SystemVerilog added the *alwasy_comb.*
VHDL could add the *process_comb. *
*
*
I favor an alignment to SystemVerilog style on this, as synthesis vendors
are already implemented, and this was done in the LRM with a lot of work and
considerations.
Ben Cohen
Ben@systemverilog.us

On Fri, Feb 18, 2011 at 12:04 PM, <ryan.w.hinton@l-3com.com> wrote:

> Hello, Hans.
>
> 1. Actually, your reason for *not* liking my suggestion (1) is
> essentially the reason I like the idea! What I neglected to mention are
> two principles that motivated my suggestions.
>
> A. "Make the common case fast", or in this case, make it simple,
> concise, and easy to use. (Yes, I am abusing the quote, but it feels
> similar to me.)
>
> B. A hardware description/design language should describe hardware.
>
> I don't feel bad about suggesting another way to infer a clocked
> process. I read a book chapter by David Bishop where he claimed there
> were five or six different ways to do this in VHDL-93. (And his point
> was that only one or two are supported by synthesis tools. :-) The idea
> of this new syntax could replace the current conventions as a preferred,
> "right" way to write a clocked process.
>
> Going by principle (A), why should I have to follow the right
> convention, type the extra lines of magic code to get a clocked process
> -- nearly *all* of my processes have to do this! Since it's so common
> it makes sense to me to make it simple and concise. Yes, I know most
> editors generate the boilerplate for you so it's not a great deal of
> work. Yes, it isn't really that many lines of code. But going by
> principle (B), it seems ridiculous that there is no "right", simple,
> concise way to do it now.
>
> Incidentally, my original suggestion does *not* have a sensitivity list.
> It's a new process style. It doesn't use a sensitivity list and
> conditionals or wait statements. You request/specify a clocked process,
> and the simulator and synthesis tools "do the right thing."
>
> I agree it's not a high-value, hard-hitting, change-the-world
> enhancement. It might make some other things easier/possible, e.g. my
> pipelining suggestion or David Bishop's z-transform idea. It might even
> make simulation a little faster because the process doesn't activate on
> both clock edges. The current conventions use the VHDL language
> mechanisms to infer the desired behavior. This is good. But it doesn't
> directly express the design intent (a clocked process), so we have to
> work harder to describe what we want indirectly.
>
> Mostly it just seems silly not to have something like this in a hardware
> language.
>
> 2. Again, the pipelining suggestion is primarily for convenience and
> clarity. It's not a question of what is *possible* in VHDL. You're
> right, current synthesis tools will move registers around to improve
> timing. The last equivalence checker (thanks for the clarification) I
> saw warned that you had to turn off these features for it to work. I
> have no experience or expertise in this area, but an idea that makes
> life easier for the designer *and* for the tools seems worthy of
> consideration. :-)
>
> 3. I very much agree that we should do as much as possible with the
> existing language. (Yes, I know this statement blatantly contradicts my
> first two proposals. :-) Pinpointing the problems and limitations is
> the best way to make sure we get an efficient solution. A preprocessor
> is an excellent way to try out ideas, but it's not a good everyday,
> long-term solution.
>
> It sounds like we need a working group to try to implement one or more
> of these frameworks in VHDL. Volunteers? :-)
>
> - Ryan
>
> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
> Of hans@ht-lab
> Sent: Friday, February 18, 2011 3:59 AM
> To: vhdl-200x@eda.org
> Subject: Re: [vhdl-200x] VHDL enhancements wish list
>
> Hi Ryan,
>
> I am not sure I understand your first point, it looks to me as something
>
> that might lead to "perl" like language issues were there are so many
> ways
> of doing something that it started to confuse its users :-).
>
> Regarding your second point, the question becomes do we want to enhance
> the
> language or rely on back-end tools to solve the problem?
> For pipelining you don't have to add complicated logic, adding some
> extra
> registers will enable synthesis tools to use register retiming or absorb
>
> registers in primitives (like with Xilinx multipliers). The same
> argument
> can be applied to formal tools (I assume you are referring to
> equivalence
> checkers). Most high-end synthesis tools write out guide files to drive
> the
> equivalence process (close to the point of becoming a push-button
> operation).
> However, having all said that I do like your "after" language construct
> since it is concise and clear.
>
> I also like your third point but rather than just adding OO we should
> take
> an existing verification framework (OVM/UVM/VMM) and see what would be
> require to implement this in VHDL (this has already been suggested by
> others).
> I also like the idea of having a pre-parser as described on your page
> (OOVHDL Working Group link) which, if I understand correctly, can
> convert
> OO-VHDL to standard VHDL. Unfortunately the link is dead and the page
> hasn't
> been updated for years.
>
> Regards,
> Hans
> www.ht-lab.com
>
>
>
> -----Original Message-----
> From: ryan.w.hinton@L-3com.com
> Sent: Thursday, February 17, 2011 8:17 PM
> To: vhdl-200x@eda.org
> Subject: [vhdl-200x] VHDL enhancements wish list
>
> Here is my current wish list for VHDL language enhancements.
>
> 1. Shorthand for clocked process. It seems silly for an HDL to require
> coding conventions to describe 90+% of designs, namely clocked
> processes. Instead, (or in addition for the foreseeable future) VHDL
> could support something like the following.
>
> label: process clock(Clk) is
> -- declaration region for constants, variables, aliases, etc.
> synchronous reset(Rst)
> -- reset logic
> begin
> -- non-reset logic
> end process;
>
> For falling edge clocks, we could add another token to specify "process
> falling clock(Clk) is ...." To be consistent we could also allow
> "process rising clock(Clk) is ..." with the default a rising-edge clock.
> For resets, we could allow either "synchronous reset" or "asynchronous
> reset".
>
> This change doesn't give a huge benefit, but it ought to be easy to
> specify and use.
>
> 2. Shorthand for pipelining. This is another common operation that
> could be easier -- but it has significant side-benefits as well.
> Typically, pipelining a signal or an operation requires defining
> additional signals and/or variables to hold intermediate values,
> shifting values in and out, etc. Instead, VHDL could support something
> like the following inside a clocked process (perhaps limited to the
> syntax above).
>
> Product <= A * B after 2 cycles;
>
> We could specify "clocks" instead of "cycles" if preferred, or possibly
> allow either.
>
> Besides the convenience, this approach has significant benefits in two
> areas. First, this syntax makes it much easier for synthesis tools to
> recognize and implement pipelined operations -- which is a big deal for
> our FPGA designs. Second, this syntax allows formal verification tools
> to see only the essential functionality. In other words, not only are
> the extra objects and assignments annoying, but they *over-specify* the
> circuit behavior. If the synthesis tool pipelines the operation like I
> want, the formal tools will complain *correctly* that the synthesis
> results do not match my design. This is because there is no way
> currently to directly express pipelining.
>
> 3. Object-oriented language features. For a discussion of syntax and
> benefits see e.g.
>
> http://www.ashenden.com.au/suave.html
>
> 4. Verification language features. This is not a strong area for me;
> in particular, I don't know SystemVerilog. But it seems that VHDL is
> already relatively strong in verification features. The VHDL-2008 text
> handling enhancements are a great improvement in this area. VHDL
> already supports most of the ideas I hear described for SystemVerilog
> verification systems. Adding object-oriented features should ease reuse
> of verification IP. We ought to be able to propose several high-value
> verification features that push VHDL back to parity -- or even beyond --
> the functionality and ease-of-use of SystemVerilog. In particular, I
> like the idea of stealing the best paradigms and features of
> verification languages like e and Vera.
>
> The other enhancements proposed have also sounded good to me. I look
> forward to working with them in the process.
>
> Enjoy!
>
> ---
> Ryan Hinton
> L-3 Communications / Communication Systems West
> ryan.w.hinton@L-3com.com
>
>
>
> --
> 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.
>
>
> --
> 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.