Re: [sv-bc] applying '{default:} struct assignment pattern on array of structs

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Mon Jan 24 2011 - 09:33:18 PST
I agree that it's illegal, whereas assign str = '{3{ '{a:1, b:2} }}; works just fine.

In general, an assignment pattern can nest in another assignment pattern wherever the enclosing repeats or tags
describe a path to the element(s) whose type should be imposed on the nested pattern.

It is tempting to think that the "default:" tag can guess how deep a path you meant - perhaps by reading ahead
into the nested assignment pattern. Or maybe a simpler rule ought to apply that does not require prescience.

The recursive definition for default: arose primarily from the desire to force integer and simple bit vector
values down into the lowest structural components of the aggregate - '{default:0} being the primæval case.

When the default expression has a particular type, the recursion stops as soon as it reaches elements of that type.
So, had the struct here been named my_t,  '{ default: my_t'{a:1, b:2} } would work.

With default expressions that are "asking for" a data type to be imposed, this search algorithm is not appropriate.
Does it make sense for default: '{...} to distribute the nested assignment pattern to each top level field or
N-1 dimensional subarray of the LHS's data type? That rule would match Jonathon's intuition here, but would require
a default clause for each dimension:

module test;
    struct { int a; int b; } str[2:0][4];
    assign str = '{default:'{default:'{a:1, b:2}}};
endmodule

... and when the LHS aggregate type is a structure with fields of distinct types, the nested assignment pattern
becomes a "pun", with multiple meanings, which formal languages wisely avoid.

module
test;
    struct{ struct { int a; int b; } a, struct { byte a; byte b; } b } str;
    assign str = '{default:'{a:1, b:2}}; //?
endmodule

Although it is tempting to look at those "a:1, b:2" tokens as necessarily referencing the field names of the struct,
in the general case they are entirely ambiguous, the compiler must first choose a scope in which to resolve them
before determining whether they are meaningful in that scope. I don't think looking ahead into the nested
assignment pattern serves as a reliable guide to the data alignment.
Error:  ./test.sv:3: Syntax error at or near token 'default:': illegal default element. (VER-294)
Assignment patterns nested in default clauses can be rejected as ungrammatical until someone develops a good mind-reading trick here.

Greg Jaxon


On 1/24/2011 5:08 AM, Jonathan Bromley wrote:
Shalom

I would say it's illegal, because the inner assignment pattern has no self-determined type.  So the array's element type doesn't meet any of the three criteria in the default: matching rule (last bullet point at the foot of p.192 in 1800-2009 clause 10.9.1).  I think it has to be that way, because of the recursive nature of the default: key.

I can easily imagine users saying it should be correct using the well-known mathematical technique of proof from obviousness.

Jonathan


From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
To: "sv-bc@eda.org" <sv-bc@eda.org>
Cc: Alex Shot <Alex.Shot@synopsys.com>
Sent: Mon, 24 January, 2011 10:35:15
Subject: [sv-bc] applying '{default:} struct assignment pattern on array of structs

Hi,
 
Is the following legal? Why or why not?
 
module test;
    struct { int a; int b; } str[2:0];
    assign str = '{default:'{a:1, b:2}};
endmodule
 
Thanks,
Shalom
 
Shalom Bresticker
Intel LAD DA, Jerusalem, Israel
+972  2 589 6582 (office)
+972 54 721 1033 (cell)
 
 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Mon Jan 24 09:34:23 2011

This archive was generated by hypermail 2.1.8 : Mon Jan 24 2011 - 09:34:36 PST