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: Jim Lewis (Jim@synthworks.com)
Date: Tue Dec 16 2003 - 13:37:28 PST


Andy,
Nothing to worry about here. The synthesis coding
styles are governed by 1076.6.

First, 1076.6-1999 and P1076.6-200X, requires the
edge of a register to be explicitly identified when
using a process without wait (note there are only
special cases of wait where clock is implicitly
identified - example follows). As a result, the
portable way to imply a register with your process,
one would need to modify the if statement to be one
of the following:

   1) if rising_edge(clk) then -- I prefer this one.
   2) if clk and clk'event then -- W/ the implicit boolean conversion

Note, in a wait statement, this is not required if only one
element is in the wait statement. Hence, both of the
following would be supported:
   3) wait until Clk = '1' ; -- supported in 1076.6-1999
   4) wait until clk ; -- W/ the implicit boolean conversion

Keep in mind that since only clock is on the sensitivity
list the simulation of semantics of your code actually
does imply a rising_edge register. However, since some
synthesis tools like to ignore sensitivity lists, they
do not agree with the simulation semantics.

It was my intent to make this coding style illegal in P1076.6-200X.
Unfortunately, I can't find anything in the standard that says that
the register coding styles specified are the only ones that
are permitted. As a result, I think a synthesis tool is permitted
to synthesize this as a register. However, they are also
permitted (and recommended) to produce an error.

> We should not judge what is ambiguous to vhdl users based on what
> verilog users have put up with.
Agreed.
However, we do want things that are unambiguous
and more concise than we currently have.

Best Regards,
Jim

Andy D Jones wrote:

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

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

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



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