Subject: RE: [vhdl-200x] An alternative proposal to boolean equivalence
From: Bailey, Stephen (SBailey@model.com)
Date: Fri Dec 19 2003 - 10:15:22 PST
Don't interpret my comments as dismissing Evan's proposal. I'll need to think about it some more. I think if we were starting back pre-1987 with the definition of VHDL, adding a concept of a logic type to the language would be the way to go. But, the existing legacy has led me to quickly identify a few more disadvantages for consideration.
> -----Original Message-----
> 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
> hasn't).
>
> 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.
>
> Advantages
> ----------
>
> 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
> language
>
> 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)
>
> Disadvantages
> -------------
>
> 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.
On 2, I think the potential for ambiguous literals would be great. I recently sent a reply that mentioned the number of string'("...") and std_logic_vector'(<bit-string-literal) types of qualification that are, in my opinion, onerous with little to no value added. We would now increase them to cover all integer/logic literal contexts.
3) Would require significant tool investment so that simulators and synthesis tools support it. This is non-trivial work as tools must recognize and analyze for optimizations. (Let me ask a fairly direct question, based on recent public comments and behavior, would anyone want to rely on a certain market leader in one of these areas to provide timely support for a completely new logic type?)
True, this is a concern with any changes we bring. But, the more we can make the changes backward compatible, built on existing capabilities and easy to implement, the better we will be.
4) Imagine the increase in type conversions required as users interface legacy code based on std_logic with new code based on the new type.
5) It is more LRM work as this would be a new class of types. To maintain consistency with overall VHDL principals, users should be able to define their own logic types that behave analogously.
> There must be an obvious flaw here, but I haven't quite
> figured out what
> it is.. :)
>
> Evan Lavelle
> Riverside
-Steve Bailey
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 10:17:27 PST