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

Gordon Vreugdenhil wrote:
> 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[1];
>       reg cond;
> 
>       initial z = cond ? x : y;
>    endmodule

> 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.

Gord,

   I think P1800 section 8.18 extends ?: to non-integral types.
I too have some problems with that section's wording.
One thing I find ambiguous is that it does not
precisely specify a result type that is statically determinable
independent of the value of the conditional expression.

   Another problem is that my copy (which may be old) says the
blending of unpacked types is done element-by-element.
I'm not clear on how to do this for tagged union types, for
structure types (which don't have "elements"), or for multi-
dimensional array types (which some view as having subarray-shaped
elements of one fewer dimension, and others view as having a multitude
of scalar elements).  Nor can I imagine  any useful application
for propagating an X effect with a coarse granularity.

   I don't know the answer, but here are some design thoughts:

   ?: should have 2-state behavior that is a subset of its 4-state
behavior for all cases where that is defined.  It's simply too
pedantic to appeal to the 2/4 stateness.

   If having a 2-state condition enables SV to /extend/ ?:, that is
probably OK too - but I foresee a rough patch when we try to define
its behavior on SV strict enum type operands.  As a bitwise BLEND
operator, these enums became integral values and lost their enum
type.  Ruling out the blending possibility by statically detecting
that the conditional has a 2-state type gives us this possible
definition:

   If the types of the THEN and ELSE expressions match, then the result
has that type provided the conditional expression is 2-state or the
matching type is unpacked.  Otherwise the THEN and ELSE expressions
must have equivalent types and the result type shall also be equivalent
to them, but normalized so that its unpacked array bounds run from [0:size-1].
Here, I'd say that since we have to adjust ALL the bounds down to the
packed or structured elements, that any element-by-element behavior
should be defined at that level, rather than at the subarray level.

   As you can see, I'm having some problem writing one general-purpose
rule.   There is a clear interest in letting enum type info propagate
up through the ?:, if no blending can happen.  Enum type info can
be implicitly discarded at any later stage where it becomes irrelevant.

   Array bound info isn't so fungible, but it's also immune to whether
blending occurs or not.  The result array needs /some/ known bounds,
and if the THEN and ELSE can't agree, it ought to use canonical bounds.

   User-defined structure types must match to be equivalent, so that
case is trivial.  There should be no "blending" effect between structures -
they are all or nothing THEN or ELSE.  If a 4-state conditional presents
an 'X, I'd be happy seeing a default or 'X-ful result.

   That takes a few twists to specify and implement, but it gives
reasonably "predictable" results for naive uses.

   Finally, I'd like this section to say something like:

   Note: Bitwise blending of signal values is not part of the
   synthesizable subset because it presupposes the existence of
   hardware "X" detection.

> 
> I think I'd prefer (3) since that allows "natural" expression of
> assignments for class handles, etc. while ensuring that we can
> check legality at elab time.
> 
> Gord.

   I respect your instincts for what seems "natural" here.