Subject: RE: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting, San Jose Dec 4, 2003
From: Bailey, Stephen (SBailey@model.com)
Date: Tue Dec 16 2003 - 13:02:45 PST
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 : Tue Dec 16 2003 - 13:04:50 PST