Subject: Re: [vhdl-200x] An alternative proposal to boolean equivalence
From: Rick Munden (firstname.lastname@example.org)
Date: Fri Dec 19 2003 - 14:45:22 PST
If this were defined in a package (rather than in the language itself)
that could be used in place of 1164, I think it would retain the
advantages you list plus be obvious (from the package and type
declarations) what was going on in the code. I, for one would find it
Evan Lavelle wrote:
> Here's a possible alternative to the boolean equivalence proposal, which
> maintains strong typing, doesn't require new implicit operators, and has
> other advantages. I haven't thought this through in detail, and I'm not
> sure if it has already been proposed (a quick search suggests that it
> The proposal is to add a new 'boolean logic' datatype to the language.
> Objects of this type can take on the values 0, 1, x, and z (note no
> quotes; it's not an enumerated type). The datatype is essentially
> identical to Verilog's logic type. In addition, the syntax of a
> condition is modified to
> condition ::= boolean_expression
> | boolean_logic_expression
> Logical operations on this type work in the same way as Verilog: they
> always evaluate to 1, 0, or x; 0 is false, everything else is true.
> 1) Anyone who wants to use the new type gets the simplified syntax in
> conditionals, ie. 'if we' rather than 'if we = '1''
> 2) Anyone who wants to use the new type no longer has to use single
> quotes everywhere (now that will *really* save typing)
> 3) Completely backwards-compatible. Anyone who doesn't like the new type
> doesn't have to use it, and doesn't have to worry about package
> visibility issues that could change the behaviour of conditionals.
> 4) Does not require the addition of invisible/implicit operators to the
> 5) Maintains type safety
> 6) Easier to convert code between Verilog and VHDL
> 7) Potentially faster simulation with 4-value logic?
> 8) Easier to implement a Verilog-equivalent ternary operator (ie.
> a=b?c:d) with this new logic type (the issue being a result of x)
> 1) Incompatible with existing code that uses 'x' or 'z' as an
> identifier, but the tool can detect this case and give a warning
> 2) The literals 0 and 1 may be either integers, or boolean_logic values,
> depending on context. At first sight, I don't think that this would be a
> significant implementation issue.
> There must be an obvious flaw here, but I haven't quite figured out what
> it is.. :)
> Evan Lavelle
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 14:47:15 PST