Re: [sv-bc] Errata: undesirable behavior of wildcard compares

Steven Sharp wrote:

>>The "inside" operator will give you the behavior you desire
>>
>>assign cs = address inside {16'hff??};
>>
>>
>
>Apparently I had an older version of the LRM that did not include this
>extension. Now that I have read it, there are still issues.
>
>If users consider this an acceptable way of getting this behavior, then
>the wildcard compares should simply be removed from the language. As
>I have already noted, their behavior is less desirable. However, there
>are reasons why users might not want to use the "inside" operator for
>this.
>
>1. They may not understand how to use it for this. By the time you read
>through the complex description of the set operations, it may not be
>clear that you can use them for this simple capability.
>
>
This could be fixed by the appropriate word smithing

>2. Because of those complex capabilities, some tools such as synthesis
>tools may not support the set operations.
>
>
Ditto

>3. Because of those complex capabilities, the set operations may be
>implemented less efficiently than a wildcard compare.
>
>
True, but I see compare as a subset of the set operation, so it
shouldn't be difficult to detect.

>4. The set operations may not read as naturally as the compare that the
>user intends them to be.
>
>5. The "inside" version is more verbose.
>
>
It's already there from the constraint functionality. This was just an
attempt to consolidate the language

>6. The "inside" version only treats Z as don't care, while the wildcard
>compares treat both X and Z as don't care. In discussion with Shalom,
>he expressed a preference for treating X as a don't care. Whatever your
>preference on this issue, the fact remains that the "inside" operator is
>not equivalent to the suggested behavior. For example, if you want to build
>up a don't-care mask with logical operations, you can't do that with the
>"inside" approach.
>
>
At one time there was an insidex version, but that was eliminated. This
could always be enhanced.

>
>I don't believe that users are benefited by the current definition of the
>wildcard compares. If they use them anyway, then the current definition
>may actually harm them. If they use your workaround and avoid them, then
>the current definition does them no good.
>
>
You've got one more day to file an errata for this next round. ;-)

>Steven Sharp
>sharp@cadence.com
>
>
>
>
Received on Tue Aug 31 13:41:30 2004