Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Paul Graham (pgraham@cadence.com)
Date: Tue Dec 16 2003 - 08:18:37 PST
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 - 08:21:26 PST