VHDL-200X - DASC List for VHDL 200X: Re: [vhdl-200x] Correction

Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting,S an Jose Dec 4, 2003
From: Andy D Jones (andy.d.jones@lmco.com)
Date: Wed Dec 17 2003 - 10:04:09 PST

Andy,

Please take a deep breath and read what is actually written.

Jim stated it would be convenient to have additional LOGIC operator overloadings (not COND overloadings). These are independent of the implicit boolean conversion where a *condition* can occur in the language. Those logic operator overloadings are valuable, in and of themselves, but would also increase the value of the COND boolean conversion capability.

As I stated in a private reply to Jim, I think he has the return values of the operators wrong. They should return std_ulogic. If that change were made, no information would be lost in sub-expressions with boolean and std_ulogic operands and the COND would perform the final conversion to boolean in a condition context.

You are right that arbitrarily applying implicit conversions anywhere in an expression tree is problematic. That is the "rat's nest" that I referred to in an earlier email. We had already seen the problems that this can lead to and constructed the proposal to exclude them.

The specific problem that we want to avoid is:

(not (b and c))

Where b is boolean = TRUE

c is std_ulogic = 'X', 'U' or 'Z'

We don't want the result of b and c to be FALSE which would presumably be the result if AND returned boolean. In that case, the entire expression would evaluate TRUE after the logical negation which is not what people would expect. (Please note that there is no need for an implicit COND conversion in this case because the expression is already boolean.)

If AND returns std_ulogic, then the result of b AND c in this case would be X and NOT X would return X and it is presumed the std_ulogic COND conversion would make it FALSE which is what people would expect.

We are not proposing any language changes that amount to: The compiler will determine, to the best of its ability, what the user really wanted and do the "right thing!"

-Steve Bailey

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org]On Behalf Of Andy D Jones
Sent: Wednesday, December 17, 2003 8:03 AM
To: Jim Lewis
Cc: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Corrections to Minutes for VHDL-200X-FT meeting,San Jose Dec 4, 2003

This slope is getting slippery...! First we said this would only be in conditionals, now we're going to extend it to expressions? Where will it be next? Why not just abandon strong typing altogether and "let the compiler figure out what we meant"?

This perfectly illustrates why I think it is a bad idea: when users start to ask "Why can I get away with this here, but not there?" and we don't have a good answer, then we'll be chipping more and more out of the guts of vhdl 'till it looks and functions like verilog.

Wrong direction guys!

Andy Jones
Lockheed Martin
Missiles & Fire Control
Dallas TX
andy.d.jones@lmco.com

Jim Lewis wrote:

Marcus,
If we limit boolean conversion to being only applied
at the top most level then we need to provide the following
overloading to logic operators to make it generally useful:
     L     R      return
     sul   bool   bool
     bool sul    bool
     bit   bool   bool
     bool bit    bool

Cheers,
Jim

Marcus Harnisch wrote:

Jim,

Jim Lewis writes:
>    2) if clk and clk'event then     -- W/ the implicit boolean conversion

Did I miss anything? I was under the impression that the implicit
boolean conversion will only be wrapped around the condition. Here you
are giving an example where an implicit conversion is applied on the
left argument to "and".

Best regards,
Marcus