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

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.