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

Hi Ryan,
Your proposals sound like good ideas to me. For your first proposal, I come
to agree with you that the following convention can be further simplified to
something like what you've proposed:
label: process(Clk,Rst) is
begin
     if Rst='1' then
        -- reset logic;
     elsif rising_edge(clk) then
        -- non-reset logic;
     end if;
end process;

I remember in the old days, we used to have:
    if clk='1' and clk'event then ...

I was thinking of having another attribute just for these conditions, such
as 'rising and 'falling attributes, so we can just specify:
   if clk'rising then
or similarly do the same with the falling edge.

Adding this idea to your original proposal (those if-statements are also
still omitted), we could have something like:
label: process(Rst, Clk'rising) is
<synchronous | asynchronous> reset(Rst)
 -- reset logic
begin
 -- non-reset logic
end process;

Just my 2cents worth.

For your second proposal, I come to like the idea that we should be trying
to make some currently non-synthesizable code to become synthesizable
instead. Such as the example you've given: the "after" clause is currently
not synthesizable though it is simulatable.

And, a very good (and easy) way you've pointed out is to make the "after"
clause synthesizable by taking the "number of clock cycles" instead of using
"nanoseconds".

 And yes, pipelining is a pain and is confusing when you have to specify a
number of pipelined stages that does not describe the intent or
functionality of the design. A new designer reading an existing design with
many such pipelined signals will need quite a bit of time to decipher those
extra signals.

Another way to do this was proposed by David Bishop in the thread "Request
for Input". Below is an excerpt of what he had proposed:

The hope would be to let the synthesis tool figure out the divider style
(given some constraints) and move the FFs back into the divider until timing
is met.

 Maybe a attribute to set a default clock, reset and enable? Then it would
look like:

 Z'default_clock := clk;
 Z'default_reset := rst;
 Z'default_enable := '1';

 Z : zt (x**2 / y, 15);

 Maybe a built in operator?

 Z <= x**2/y @ 15;

Here, a z-transform operator is designed as a built-in library, and is
essentially a delay element (similar to the "after 1 cycle" proposal). The
"zt" and "@" operators denote the proposed z-transform operators. Here, the
Z signal is pipelined to delay by 15 clock cycles. Read the thread for the
full discussion.

Perhaps it's a good idea to support both proposals (the "after" clause and
"zt" operator)?

Regards,
Daniel

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

> 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.