Re: [sv-bc] structure literal example in standard

Greg Jaxon wrote:

> The example on page 12 is wrong, and its expansion has been bungled.
> Here is a corrected version:
> 
> struct {int X,Y,Z;} XYZ = '{3{1}};
> typedef struct {int a,b[4];} ab_t;
> int a,b,c;
> ab_t v1[1:0] [2:0];
> v1 = '{2{'{3{'{a,'{2{b,c}}}}}}};
> /* expands to '{ '{3{ '{ a, '{2{ b, c }} } }},
>                  '{3{ '{ a, '{2{ b, c }} } }}
>                } */
> 
> /* expands to '{ '{ '{ a, '{2{ b, c }} },
>                     '{ a, '{2{ b, c }} },
>                     '{ a, '{2{ b, c }} }
>                   },
>                  '{ '{ a, '{2{ b, c }} },
>                     '{ a, '{2{ b, c }} },
>                     '{ a, '{2{ b, c }} }
>                   }
>                } */
> 
> /* expands to '{ '{ '{ a, '{ b, c, b, c } },
>                     '{ a, '{ b, c, b, c } },
>                     '{ a, '{ b, c, b, c } }
>                   },
>                  '{ '{ a, '{ b, c, b, c } },
>                     '{ a, '{ b, c, b, c } },
>                     '{ a, '{ b, c, b, c } }
>                   }
>                } */
> 
> Since there is enough room on the page, please use the vertical
> pattern to better illustrate the repetitive behavior.
> 
> Greg Jaxon

I understand that examples aren't normative, but please add:

/* Implementations are not required to replicate assignment patterns
    before evaluating them. */

Rationale:

DCSV enforces a non-standard constraint on replicated assignment
patterns not discussed in the LRM, but which I feel keeps things
saner.  The insanity I prefer to avoid is where one subexpression
is given multiple different interpretations after being replicated.

This doesn't arise in most array examples because SV arrays are
homotypic.  But when the '{n{...}} syntax corresponds to a struct,
it is possible that the replicated items in the list come into
correspondence with substructures of different data types.

Expanding the text (above) _does_ give us an "obvious" semantics
for these cases, yet when it comes time to report a type mismatch
error somewhere in the bowels of this expansion, there is just no
good way to indicate which copy of the subexpression was at fault.

Verilog explicitly permitted repeat concatenation of function calls
to evaluate by replicating the result of one function call.  I feel
that this established an expectation that values are being replicated,
not macro text.  Warnings and errors issue from DCSV wherever
replication by text expansion begins to violate this naive expectation.
We warn if the replicated value gets used in different "width" contexts,
We error out if a replicated assignment pattern must construct several
non-matching types.  The increased power of text expansion just didn't
seem worth the risk to design correctness that comes from violating the
principle that subexpressions are parsed and type-balanced just once.

Internally in DCSV, we refer to subexpressions with multiple meanings
as "puns".  Fun as they may be, you don't want to be groaning over them
during the post-mortem of a design failure.

Greg Jaxon