Subject: [vhdl-200x] An alternative proposal to boolean equivalence
From: Evan Lavelle (anti.spam1@dsl.pipex.com)
Date: Fri Dec 19 2003 - 09:40:47 PST
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.
There must be an obvious flaw here, but I haven't quite figured out what
it is.. :)
Evan Lavelle
Riverside
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 09:42:18 PST