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

Ryan,
[Ben] As you know, I wrote several books on VHDL, Verilog, SystemVerilog,
assertions (PSL, SVA), and VMM.
I also used and taught VHDL for many years. However, like many other people
who wrote on the newsgroups, I started to appreciate the power and values of
SystemVerilog, even though VHDL has a more rigorous timing model for
concurrency. Basically, it boils down to maintaining a simple set of rules
in SystemVerilog to avoid timing conflicts; those rules are not that bad,
and are really simple.

>
> library ieee;
>
> use ieee.std_logic_1164.all; *-- [Ben] I have to have to add this every
> time. kind of buggy. *
>
> use ieee.numeric_std.all; *-- [Ben] I have to have to add this every time,
> SV can import packages, *
>
                        *-- but those are more of the standard ones*

> entity Counter is
>
> port (
>
> Clk : in std_logic;
>
> Reset_n : in std_logic;
>
> Count : out unsigned);
>
> end entity Counter;
>
>
>
> architecture behave of Counter is
>
> begin
>
> p_count: *process *clock(Clk) *is*
>
> asynchronous falling reset(Reset_n) *-- [Ben] What is this? Which of
> these words are reserved? *
>
                    * -- **All 3: **asynchronous, falling, and reset ?*

> Count <= (others => ‘0’);
>
> begin
>
      * if (load='0') then -- Hate the need to write ='0' (see below for
more)*

> Count <= Count + 1;
>
> end process;
>
*[Ben] My point here is that this committee should consider a template that
was successfully used in Verilog and SystemVerilog for many years.
 Specifically *

> * p_count: process clock(posedge Clk or negedge Reset_n) is*
>
* begin *
* if (not Reset_n) then Count <= (others => ‘0’);*
* else *

> * Count <= Count + 1;*
>
* end process; *

> * -- [Ben] This is not that different than the current VHDL for an
> asynchronous rest model. *
>
* -- The clk'event and clk='1' is replaced with the clock edges in the
sensitivity list *

>
>
end architecture behave;
>
>
>
> Regarding checking for only combinatorial logic, I’m inclined to agree with
> Mr. Lavelle: I’ve never accidentally inferred a latch or FF inside a
> combinatorial process. I have never heard of any of my colleagues doing
> this. My experience is limited, but it doesn’t seem necessary in my
> opinion. Of course, vendors are always welcome to warn me of such behavior
> if they notice it. :-)
>
> *[Ben] Latches are easily inferred in RTL in a non-clocked process when a
> signal is not assigned under all conditions. *
>
    *While, we're at it, instead of writing *
* if (a='1') then ... , why can't we write *
* if (a) then ..*
* Basically, consider the logic or bit type a boolean. It is SO annoying
to have to write the =='1' *
* These are the few things that people love about SystemVerilog. *
*Ben Cohen SystemVerilog.us *

> Thanks!
>
>
>
> - Ryan
>
>
>
> *From:* ben cohen [mailto:hdlcohen@gmail.com]
> *Sent:* Friday, February 18, 2011 11:23 PM
>
> *To:* Hinton, Ryan W @ CSG - CSW
> *Cc:* vhdl-200x@eda.org
> *Subject:* Re: [vhdl-200x] VHDL enhancements wish list
>
>
>
> Ryan,
>
> This is a very long thread, and I am not totally clear on your syntax. Can
> you provide an example for a counter that is asynchronously reset?
>
> Below is a SystemVerilog model.
>
> I see some differences in the sensitivity list in that events are passed
> there.
>
>
>
> The *always_ff * emphasizes the Flip-Flop implementation. I think that
> this is nice. I gave you the details of meaning and checks if a FF is not
> implied.
>
> The *always_comb * is equivalent to the *process(all). B*ut does the
> process(all) check for combinational logic. From SystemVerilog LRM "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". If not, you may want to add that.
>
>
>
> module mcounter;
>
> logic [3:0] counter, counter2;
>
> logic clk, reset_n;
>
> enum {IDLE, ACTIVE} state;
>
>
>
>
>
> always_ff @(posedge clk, negedge reset_n)
>
> if (!reset_n) counter <=0;
>
> else counter <= counter + 1'b1;
>
>
>
> always_ff @(posedge clk, negedge reset_n) begin : ff0
>
> if (!reset_n) begin : the_reset
>
> counter2 <=0;
>
> state <= IDLE;
>
> end : the_reset
>
> else begin: the_body
>
> counter <= counter + 1'b1;
>
> state <= ACTIVE;
>
> end : the_body
>
> end : ff0
>
> endmodule :mcounter
>
>
>
> Ben Cohen
>
> Ben@systemverilog.us
>
>
>
>
>
>
>
> On Fri, Feb 18, 2011 at 8:03 PM, <ryan.w.hinton@l-3com.com> wrote:
>
> 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.