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

Ryan,
The difference is that the edges are in the sensitivity list, rather than in
the body of the process.
I must admit that did not keep pace with VHDL'08 because I concentrated my
efforts on SystemVerilog, assertions, and VMM. The always_comb is used to
model combinational logic. I like the SystemVerilog syntax on this. From
P1800'2009
*9.2.2.2 Combinational logic always_comb procedure*
SystemVerilog provides a special always_comb procedure for modeling
combinational logic behavior. For example:
always_comb
  a = b & c;
always_comb
d <= #1ns b & c;
The always_comb procedure provides functionality that is different from the
general purpose always procedure:
— There is an inferred sensitivity list that includes the expressions
defined in 9.2.2.2.1.
— The variables written on the left-hand side of assignments shall not be
written to by any other process. However, multiple assignments made to
independent elements of a variable are allowed as long as their longest
static prefixes do not overlap (see 11.5.3). For example, an unpacked
structure or array can have one bit assigned by an always_comb procedure and
another bit assigned continuously or by another always_comb procedure, etc.
See 6.5 for more details.
— The procedure is automatically triggered once at time zero, after all
initial and always procedures have been started so that the outputs of the
procedure are consistent with the inputs. Software tools should perform
additional checks to warn if the behavior within an always_comb procedure does
not represent combinational logic, such as if latched behavior can be
inferred.

*9.2.2.4 Sequential logic always_ff procedure*
The always_ff procedure can be used to model synthesizable sequential logic
behavior. For example:
always_ff @(posedge clock iff reset == 0 or posedge reset) begin
r1 <= reset ? 0 : r2 + 1;
...
end
The always_ff procedure imposes the restriction that it contains one and
only one event control and no blocking timing controls. Variables on the
left-hand side of assignments within an always_ff procedure, including
variables from the contents of a called function, shall not be written to by
any other process. Software tools should perform additional checks to warn
if the behavior within an always_ff procedure does not represent sequential
logic.

*9.2.2.3 Latched logic always_latch procedure*
SystemVerilog also provides a special always_latch procedure for modeling
latched logic behavior. For example:
always_latch
if(ck) q <= d;
The always_latch construct is identical to the always_comb construct except
that software tools should perform additional checks and warn if the
behavior in an always_latch construct does not represent latched logic,
whereas in an always_comb construct, tools should check and warn if the
behavior does not represent combinational logic. All statements in 9.2.2.2
shall apply to always_latch.

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

> I believe your first suggestion fits the syntax I already suggested for an
> asynchronous reset. (Actually, I don’t think I included the active-low
> reset, but it should be easy to handle.) I assume we will debate the syntax
> in committee. (I think mine looks more like VHDL. :-)
>
>
>
> Is SystemVerilog “always_comb” different from VHDL-2008 “process(all)” ?
>
>
>
> - Ryan
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Friday, February 18, 2011 5:03 PM
>
> *To:* vhdl-200x@eda.org
> *Cc:* Hinton, Ryan W @ CSG - CSW
>
> *Subject:* 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.