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: Tue Dec 16 2003 - 11:02:27 PST

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



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 : Tue Dec 16 2003 - 11:05:50 PST