Subject: Re: [vhdl-200x] An alternative proposal to boolean equivalence
From: Evan Lavelle (anti.spam1@dsl.pipex.com)
Date: Fri Dec 19 2003 - 11:36:54 PST
Jim Lewis wrote:
> Evan,
> To be useful, this bit type would need to have a
> corresponding vector type, and extensions to support
> math.
Yes, but surely this would be easy? Standard could just include a
logic_vector (or whatever) in the same way as it has a bit_vector, and
couldn't the arithmetic packages just be overloaded without much more
effort than cutting and pasting?
> It also looses the ability to differentiate
> an X on an input from a don't care. As a result,
> there would be no sane way to enhance the case
> statement and "=" to handle don't care ('-').
True, we can't handle both unknown and don't care in 4-state logic.
Anyone who needs this level of sophistication would have to use
std_logic, as they do now. But then, anyone who wants to distinguish 'X'
and '-' isn't going to want boolean equivalence anyway; they'll write it
all out in full, so I don't think this is a problem.
For the case of enhancing case statements for don't cares, we could just
do the same as Verilog. If the case expression is of type 'logic', it
could be treated as a casex-equivalent, where an x or a z in a choice is
a don't care. Maybe a casez-equivalent would be useful as well.
Equality is trickier: do you want to handle don't cares? Is that a
proposal? It could be handled in the same way as the case(x/z) statement
when the operands are of type 'logic', but this would be incompatible
with Verilog. Not a problem, but it would be nice to be compatible.
> This is a good alternate view of what we are doing:
> condition ::= boolean_expression
> | boolean_bit_expression
> | boolean_std_ulogic_expression
>
> So the "COND" operator is simply a way to implement
> the above.
Ok, but it still leaves the issue of the cond operator being textually
invisible, or implicit if you prefer, and the type safety issue.
Evan
This archive was generated by hypermail 2b28 : Fri Dec 19 2003 - 11:38:51 PST