RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003

Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Bailey, Stephen (
Date: Tue Dec 16 2003 - 13:02:45 PST


Looks like you don't completely comprehend the proposal. Since we don't have a fully fleshed out proposal, it is understandable.

The proposal is for a user-definable condition operator, let's call it COND for the time being. COND would only be called implicitly in places where the VHDL syntax identifies a *condition*. If you look at the syntax rules for VHDL, that would be:

  - assert *condition* ...
  - if *condition* (if statement and if-generate)
  - elsif *condition*
  - wait [...] until *condition* [...]
  - when *condition* ... (conditional signal assignment, exit, next)
  - while *condition*

Further requirements are that there must be a COND operator visible at the point of the *condition* that takes as its sole input parameter a value of the type of the expression found in place of the *condition*. Of course, COND must return BOOLEAN.

We would probably need to add a production for *condition* of the form:

  *condition* ::= *boolean*_epression
               | COND( expression )

In your examples below, you are attempting to apply the implicit call of COND in an edge sensitive context. While you can write:

  if clk then


  if not clk then

These if statements are level sensitive and not edge sensitive. To capture edge sensitivity, you would still need to specify event using any of the supported mechanisms today, for example:

  if rising_edge(clk) then
  if clk'event and clk = '1' then

  if falling_edge(clk) then
  if clk'event and clk = '0' then

Since we already have rising_edge and falling_edge functions defined, I would recommend their use as (sorry can't help myself):

  - rising_edge(clk) is shorter than
    clk'event and clk = '1'
  - It better captures the design intent.

The proposal for the implicit COND call is the equivalent of:

  if COND(we) then

If std_logic_1164 defined an AND overloading that took BOOLEAN, std_[u]logic operands returning std_[u]logic, then for the edge case, the implicit call would be equivalent to:

  if COND(clk'event and clk) then

There is no need for the implicit call to COND for today's edge specifications (rising_edge, (Clk'event and clk = '1')) as those expressions are of type BOOLEAN already.

In summary, the implicit COND call is made only at the top of the condition expression evaluation and it has no event semantics associated with it.

-Steve Bailey

-----Original Message-----
From: Andy D Jones
To: Bailey, Stephen
Cc: '';;
Sent: 12/16/2003 11:02 AM
Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003

The specific cases I was referring to would best be fleshed out as

main: process (clk)
  if clk then -- rising edge or falling edge?
    do_clocked_stuff(outputs, inputs);
  end if;
end process;


main: process (clk)
  if not clk then -- rising edge or falling edge or not clock event?
    do_clocked_stuff(outputs, inputs);
  end if;
end process;

While verilog has the posedge modifier on the "sensitivity list", vhdl
does not. I maintain that the above examples are not.

We should not judge what is ambiguous to vhdl users based on what
verilog users have put up with.

I also believe that to_boolean(clk) would be just as ambiguous as "clk"
itself. Conversion to boolean only has meaning if it is explicit which
value is interpreted as true.

Andy Jones
Lockheed Martin
Missiles & Fire Control
Dallas TX <>

Bailey, Stephen wrote:

Paul has nicely stated what I was about to reply.

I would like to add a few more comments in the hope that they will
improve the quality of discussion:

1. Please refrain from hyperbole.

2. Do not just assert something without providing proof to back-up your
assertion. If you take the time to do so, you'll probably find a more
receptive audience and increase your powers of persuasion.

When I did the VHDL equivalent of Paul's Verilog-oriented response to
Andy, I could not find any ambiguity:

Active High:

  if we then

    ... -- Do write operation

  end if;

Active Low:

  if not we_n then

    ... -- Do write operation

  end if;

Perhaps Andy has better examples that demonstrate his points?

Due to the lack of specific examples or proof on how to_str vs.
to_string, boolean equivalence, etc. (as proposed) harm VHDL, I assume
that people are concerned that these might be the first steps on a
slippery slope into C-type obfuscation (the potential for VHDL that
looks like: q *= *p+++++d). In that regard, I appreciate the concern
and due diligence. However, the people that are working on these
proposals are also keeping these considerations in mind. In the case of
the boolean equivalence capability, I am personally very pleased and
satisfied with the insightfulness of John Ries and Jim Lewis in coming
up with a proposal that preserves the strong typing of VHDL and avoids a
true rat's nest of problems that would arise from many alternative

In summary, please continue with the due diligence review. But,
remember to work through some examples (simple or complex, whatever is
needed) to demonstrate your points.

-Steve Bailey




What happens when someone writes "elsif clk then..."? Do


we assume that


he wants the rising edge? What if he writes "elsif not clk


then..."? Do


we assume it is not a clock event, or that he wants the


falling edge? This


is exactly what I've been talking about


I guess I don't see the ambiguity you refer to. In verilog,

if you write

"always @(posedge clk)" then it's clear that you're looking

at the rising

edge of a clk. If you then write "if (!rst)" it's clear that

you're looking

at an active-low reset.


An implied conversion from vector to number space is


ambiguous, the same


way an implied coversion from signal level to boolean is


ambigous. And


VHDL is all about avoiding ambiguity!!!


Again, if a verilog description has "x = y + 2'b10;" it's

clear that you're

adding the value 2 to y. No verilog designer would be

confused by this.

Ambiguity is a problem mainly for language implementors. If

a design is

truly ambiguous, then different tools may produce different

results. A

human reader can misunderstand a design even if it isn't

ambiguous from a

tool's point of view. A vhdl design which uses overloaded

operators and

layers of types can be confusing to read, though not

necessarily ambiguous.

Since different implementors have produced tools that

interpret verilog in

the same way, then there must not be too much ambiguity in

the language. I

am not saying that the Verilog LRM is clear. It has a long

way to go to

reach the standard of precision and conciseness that was

achieved by the

VHDL definition. But it's hard to find an example of an

ambiguous verilog





This archive was generated by hypermail 2b28 : Tue Dec 16 2003 - 13:04:50 PST