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

Ben,

To the best of my understanding, process(all) in VHDL-2008 is
semantically equivalent to this description of always_comb. One request
to check off already.

OK, so the difference between your always_ff suggestion and my process
clock() suggestion is just syntax. In the interest of everyone's time,
I'll wait to say I like mine best until the appropriate committee
discussion. :-)

- Ryan

From: ben cohen [mailto:hdlcohen@gmail.com]
Sent: Friday, February 18, 2011 5:52 PM
To: Hinton, Ryan W @ CSG - CSW
Cc: vhdl-200x@eda.org
Subject: 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.