Subject: Re: [vhdl-200x] A 2nd proposal to boolean equivalence
From: Evan Lavelle (anti.spam1@dsl.pipex.com)
Date: Wed Dec 24 2003 - 01:52:04 PST
Tim Davis wrote:
> I don't understand why you think a new case statement would be
> necessary. It is just a matter of allowing the selector expression and
> the matching elements to be non-static. (Maybe I don't understand you.)
The problem is how the compiler determines if the new non-static case
statement is 'full' or 'parallel', to borrow Synopsys' directive
terminolgy. The existing VHDL case statement is always 'full parallel',
which makes life easy for synthesisers. The Verilog case statement
allows a non-static case expression and selectors, so it's not obvious
whether the case statement is full (ie. explicitly or implicitly covers
all choices) or parallel (choices covered only once). In Verilog this is
handled by adding synthesis directives to tell the synthesiser what your
intent was (which potentially causes simulation and synthesis
mismatches). This isn't good, so we could alternatively use different
case statements to give this functionality. On the other hand, this
might just set in concrete the problems with the Verilog case statement
and the use of directives; this needs some thinking about.
>>> Third, (as I proposed before) utilize enumerated type declarations
>>> with explicit type equivalency built into the declaration. Here is
>>> the syntax I proposed:
>>>
>>> type negative_logic is ('0' => true, '1'=>false, 'Z'=>false,
>>> 'X'=>false) with boolean,
>>> ('0'=>1, '1'=>0, 'Z'=>-1, 'X'=>-1)
>>> with integer,
>>> ('0' => "0", '1'=>"1", 'Z'=>"Z",
>>> 'X' => "X") with string;
>>
>>
>>
>> If you want boolean equivalence, then it seems to me that this is a
>> much cleaner, simpler and better way of achieving it. However, the
>> overall effect is the same: the compiler is allowed to carry out
>> implicit typecasting without any explicit request (at the point at
>> which it is required) from the user.
There's another reason why your proposal is much better than the
package-based 'COND' proposal. For the packaged-COND proposal, the
user's intent is split into two parts: the point of (implicit) use of
the 'cast', and the point where the relevant COND is defined in a
package. But anyone who's ever read VHDL code will know that the average
user generally has little grasp of which packages are required to make
code work (how many times have you seen code which uses both Synopsys
and IEEE arithmetic packages?). I also see (and have) exactly this
problem in C++ and 'e' all the time - you simply mess with your includes
until everything compiles. In other words, for the packaged-COND
proposal, the writer's original intent can be lost simply because
another user of the code gets their package visibilities wrong. Consider
a case where package A has a COND which sets 'X' as true, and package B
sets 'X' as false. This obviously has the potential for major problems.
Put differently, packaged-COND only works if the original writer *wrote*
the code correctly, *and* all later users *use* it correctly. It's a
maintenance nightmare.
Your proposal doesn't (generally) have this problem: the original
writer's intent is clearer. You could still get a problem if the new
type is given a common name, and its definition is packaged in another
source file, but it's much less likely to be a problem.
Evan Lavelle
This archive was generated by hypermail 2b28 : Wed Dec 24 2003 - 01:54:15 PST