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: Andy D Jones (andy.d.jones@lmco.com)
Date: Wed Dec 17 2003 - 06:42:53 PST

Steve,

Thanks for the clarification, however...

Is it proposed to include a standard COND operator definition in std_logic_1164?  Would it convert  'H' to TRUE?  What about 'X' or any other metavalue?  If it is not defined as a standard, then different users may write it differently.  Which now means the same code, with a different user's COND definition would simulate differently.  Hmmm, sounds like verilog to me.

Most of this would not make any difference for RTL code written for synthesis into an FPGA or ASIC, but when it is used to simulate the FPGA on the board, and the board has resistively driven inputs, these details matter big time.  And it is these "details" that brought about the creation of std_logic in the first place; now we are going to throw away all that work for a little less typing?

When only "clk" is in the sensitivity list (and there is no subordinance to another if clause, i.e. reset), many synthesizers will accept the following for a clock edge specification, and it will simulate correctly, assuming no weak or metavalues are involved (a shortcoming to every method but rising_edge() and falling_edge().)

main: process (clk)
begin
  if clk = '1' then -- means rising edge clock
    do_rising_edge_stuff(inputs, outputs);
  end if;
end prodess;

By extension, it would be allowed to write (if a COND operator is defined for std_logic):

main: process (clk)
begin
  if clk then -- means rising edge?
    if enabled then -- clock enable?
      do_rising_edge_stuff(inputs, outputs);
    end if;
  end if;
end prodess;

And, by further extension, it would be allowed to write the following:

main: process (clk)
begin
  if not clk  then -- means falling edge?
    if not disable then -- clock enable?
      do_falling_edge_stuff(inputs, outputs);
    end if;
  end if;
end prodess;

As you can see this usage makes it more difficult to distinguish between clock enables and clocks, an important distinction.  Furthermore, it has been proposed elsewhere that synthesis vendors accept the following as clock enable syntax (it already simulates like a clock enable):

main: process (clk)
begin
  if rising_edge(clk) and enable = '1' then
    do_rising_edge_stuff(inputs, outputs);
  end if;
end prodess;

If this were rewritten under the new standard as the following, what would it mean?

main: process (clk)
begin
  if clk and enable then -- = rising_edge(clk and enable) = gated clock, not clock enable!
    do_rising_edge_stuff(inputs, outputs);
  end if;
end prodess;

I used the term "allowed to write" above, even though we all know that, since it is the shorter syntax, it will become the de facto standard, and vhdl will lose valuable clarity as a result.  If users want to write code like verilog lets them, tell them to use verilog (and tell them to look out!).  Otherwise, write vhdl. 

The popularity of vhdl (and thus its survival) is not dependent on trivial shortcuts like this.  It is dependent on archaic, but still taught practices like using component definitions/configurations/instantiations instead of entity instantiation.  Like using std_logic and std_logic_vector everywhere when integer and boolean are simpler, easier to read and write, and faster to simulate.  These are the things that will make and keep vhdl vibrant and healthy, not dumbing it down for the masses. The proposed implicit call to COND is a terrible idea, providing precious little benefit for a monumental loss in clarity.

Andy Jones
Lockheed Martin
Missiles & Fire Control
Dallas TX
andy.d.jones@lmco.com


Bailey, Stephen wrote:
Andy,

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

Or

  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: 'pgraham@cadence.com'; Rick.Munden@Siemens.com; vhdl-200x@eda.org
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
follows:

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

and

main: process (clk) 
begin
  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
andy.d.jones@lmco.com <mailto:andy.d.jones@lmco.com> 



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



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



  

Andy,



    

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

design.



Paul

This archive was generated by hypermail 2b28 : Wed Dec 17 2003 - 06:45:42 PST