Re: [sv-bc] Question on ?: with "any" data type

>From: Gordon Vreugdenhil <gordonv@model.com>

>The SV LRM claims the ?: is defined for "any" data type.  Is
>the following supposed to be legal?  If so, what is the value of z?
>
>    module top;
>       integer x[1] = '{ 1 };
>       integer y[1] = '{ 2 };
>       integer z[5];
>       reg cond;
>
>       initial z = cond ? x : y;
>    endmodule

Well, I believe it is illegal, but not because the cond is X.
The result of the ?: is an array of 1 integer, and you are trying
to assign it to z, which is an array of 5 integers.  This is not
assignment compatible.

However, since this is presumably not what you were trying to ask,
I will respond as if z were declared as an array of 1 integer.

>In 1364, when "cond" has the value 'x, the result is
>defined bitwise by Table 5-20.  But bitwise operations aren't
>defined for unpacked types (and would be quite bad for class
>handles or similar).  I see 3 choices:
>     1) ?: should be restricted to integral types
>     2) it must be a sim time error if the condition is 'x for
>        a non-integral result
>     3) the condition must be restricted to a 2-state value if
>        the result is a non-integral type.

This is defined by the rules in section 8.18 of 1800, and the answer is
"none of the above".  The rules require combining the values element-by-
element, though they don't define what constitutes an element (i.e. does
it just go down to the first non-aggregate value, such as an integer, or
does it go down inside packed values to the bit level).  A mismatch at
the element level produces the default initialization value.

If you regard the integers as the elements, then x[1] and y[1] do not
match, and the result is an array whose element is 'x.  If you regard
the individual bits of the integers as the elements, then this is a
bitwise combination of the integers, and the result is an array whose
element is 32'b0xx.  The first is more pessimistic than the second.
Both operations are complex and expensive, but the second is more so.

For a class handle, the element must be considered the class handle
itself.  So if the two handles refer to the same object, then that
is the result.  Otherwise the result would be null, since that is the
default initialization value for a handle.  That is pretty clean.

Things seem really fuzzy for objects that can have differing numbers
of elements, such as queues and associative arrays.  My best guess is
that combining a queue containing 5 elements with one containing 8
elements would result in an 8-element queue where the last 3 elements
were all the default initialization value (since those elements did
not match in both).  But you could instead get a 5-element queue,
which behaves similarly in some ways, giving you back the default
initialization value if you try to read the extra 3 elements.  Similar
possibilities exist for associative arrays.

It's all very messy.

Steven Sharp
sharp@cadence.com