[sv-bc] Ambiguity with packed struct literals

I think the rules for interpreting a struct literal are ambiguous.
Consider this example:

    typedef struct packed {
        bit [3:0] f1;
        bit [3:0] f2;
    } t1;

    module test(output t1 q1, q2, q3, q4, q5);
        assign q1 = { 4'b1111, 4'b0000 };
        assign q2 = { 5'b11110, 3'b000 };
        assign q3 = 8'b11110000;
        assign q4 = { 2'b11, 2'b11, 4'b0000 };
        assign q5 = { '1, '0 };
    endmodule

The assignment to q1 seems straightforward.

The second assignment is tricky. Is it equivalent to this:

(1)
    assign q2.f1 = 5'b11110;
    assign q2.f2 = 3'b000;

Or is it equivalent to this:

(2)
    assign {q2.f2, q2.f2} = {5'b11110, 3'b000};

(Note that (1) and (2) yield different results.)

LRM 7.14 says:

    A structure expression (packed or unpacked) can be built from
    member expressions using braces and commas, with the members in
    declaration order. ... Each member expression shall be evaluated
    in the context of an assignment to the type of the corresponding
    member in the structure.

so this would seem to resolve the issue in favor of (1).

On the other hand, a packed struct (or packed array) is just an
integer expression, so it should be possible to assign an integer
expression to it. This favors interpretation (2). An example of an
integer assignment to a struct is the assignment to q3.

But an integer expression includes any (packed) concatenation
expression, as in the assignment to q4. The concat expression which
is assigned to q4 can't be interpreted as being of type t1. It has
the wrong number of elements. So is this an illegal assignment
(because not every element of the concat has a corresponding struct
member) or is it legal (interpreted as an integer expression)?

Finally, the rhs of the assignment to q5 can be interpreted as a
struct literal, in which case both '1 and '0 are evaluated to four
bits, or it can be interpreted as a concat (an integer expression),
which I suppose would produce an error because you can't have an
unsized literal in a concat.

Could it be that the rule for evaluating each element of a struct
literal in the context of the corresponding struct memeber only
applies to unpacked struct types?

Paul
Received on Mon Dec 6 10:22:34 2004