Re: [vhdl-200x-ft] Revised FT18: condition operator

Selon Jim Lewis <Jim@SynthWorks.com>:

> Tristan,
> Note, condition? was (is being) replaced by ?? as updated below:
> > Instead of
> > *condition* ::= *boolean*_expression
> > | ??( expression )
> >
> > Where ?? is called by the compiler when the expression does
> > not resolve to boolean.
>
> In this from of condition, ?? can only be called
> implicitly at the highest level of the condition.
> The expression must hence resolve to some type such
> as std_logic or bit for ?? to be called.
>
> > Why not:
> > *condition* ::= expression
> >
> > Where a "??" function returning a boolean is implcitly called with the
> > expression as only argument.
>
> When is ?? called? Anytime? We looked at that.
> If you demote std_logic to boolean too soon, you
> loose the value of X. If A is 'X', should "not A"
> translate to false (applying it after the not) or
> true (applying ?? to A immediately). I think
> John Ries was able to come up with some more
> interesting cases than this.
I was not clear enough. In the second form (the one I have written),
the "??" function is always implicitly called at the highest level of a
condition. Therefore, boolean is not that special anymore (exception that only
function "??" returning a boolean are considered).

[...]
> P.S.
> Of course, as a hardware designer, I never saw the
> value of having a separate type for boolean. So
> long term, I would like to see it easier to move
> back in forth between them. Something more like:
>
> As an expression is being evaluated, promote boolean
> to bit and boolean to std_ulogic as needed. Optionally
> extend this to include bit to std_ulogic.
>
> When an expression is being assigned
> or has reached a conditional demote the expression
> value as needed. From std_ulogic to boolean and
> bit to boolean as needed. Optionally extend this to
> include std_ulogic to bit.
>
>
> In the future we probably need some general mechanism for
> defining type association. If we were to write something
> like the above into the LRM now, it is potentially a wart
> that would either need to be worked around in the future.
That's a real debat, and it seems you like Verilog point of vue on this
issue!!!
I do like strong typing and I do like the difference between boolean and
bit/std_logic. It clearly separates data-flow from control-flow.

Tristan.
Received on Fri Dec 3 00:27:28 2004