RE: [sv-ec] rand in struct with union members

So you are saying that only unpacked unions cannot be made random. If so
then the whole sentence from which we started the discussion is redundand
and mention about unions should be removed.
From Steven email I think that LRM was  saying that packed union cannot be
made random if nested in unpacked struct - but this restriction is
controversial.

DANiel

-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: 7 września 2009 17:03
To: Daniel Mlynek; 'Steven Sharp'; sv-ec@server.eda.org
Subject: RE: [sv-ec] rand in struct with union members

1. I think it could have been done, as Steven wrote, 

"It would have been more general if it had said that a struct member could
be made rand, as long as that member was itself of a type that could be made
rand. "

18.4 says, "The solver can randomize singular variables of any integral
type," and packed unions are singular (6.4) and integral (6.11.1).

I think the possible distinction between packed and unpacked unions was
simply not considered when the restriction in 18.4 was written.


2. However, in your example, you wrote:
> 	typedef union packed {reg [3:0] r; enum bit[3:0]{raz,dwa,trzy} e;} 
> TT;
> 	typedef struct {TT a; rand byte b;} TT1;
> 	typedef struct packed{TT a; byte b;} TT2;
> 
> 	typedef struct {
> 		TT u1;		//cannot be random
> 		rand int i;//ok 
> 		rand TT1 s1;//ok
> 		TT2 s2;//this also cannot be random as if so then it will
randomize 
> s2.a which is a union
> 	} T;

I think u1 can be random, as I wrote above. At least, I think it is a
legitimate interpretation of the LRM.
I think s2 can also be random as it is a packed structure, not an unpacked
structure.

Shalom


> -----Original Message-----
> From: owner-sv-ec@server.eda.org
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Daniel Mlynek
> Sent: Monday, September 07, 2009 10:50 AM
> To: 'Steven Sharp'; sv-ec@server.eda.org
> Subject: RE: [sv-ec] rand in struct with union members
> 
> 1. Thank you for yours exaplanation.
> I still have doubts why not to allow packed union to be rand member of 
> unpacked struct and treat them as variable vector with size and sign 
> given by its declaration (ignore fields specification). Another 
> problem is that union are allowed as arguments for std::randomize 
> function so this is inconsistence.
> 
> 2. Let me present  an example for current LRM rules - are my comments 
> right?
> 
> module top;
> 	typedef union packed {reg [3:0] r; enum bit[3:0]{raz,dwa,trzy} e;} 
> TT;
> 	typedef struct {TT a; rand byte b;} TT1;
> 	typedef struct packed{TT a; byte b;} TT2;
> 
> 	typedef struct {
> 		TT u1;		//cannot be random
> 		rand int i;//ok 
> 		rand TT1 s1;//ok
> 		TT2 s2;//this also cannot be random as if so then it will
randomize 
> s2.a which is a union
> 	} T;
> 	T s1;
> 
> 	
> endmodule
> 
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: 4 września 2009 23:21
> To: sv-ec@eda.org; daniel.mlynek@aldec.com
> Subject: Re: [sv-ec] rand in struct with union members
> 
> 
> >From: "Daniel Mlynek" <daniel.mlynek@aldec.com>
> 
> >LRM:"Members of unpacked structures containing a union as well as 
> >members of packed structures shall not be allowed to have a random
> modifier."
> >
> >Why does the LRM forbids to have "rand" on  structs
> containing an union?
> >What was the motivation for this restriction?
> 
> I don't remember anything about this restriction, and may not have 
> been involved.  However, I can make deductions about what was 
> intended.
> 
> The wording of this restriction in 8.4 closely matches the restriction 
> in
> 7.2.2:
> 
> "Members of unpacked structures containing a union as well as members 
> of packed structures shall not be assigned individual default member 
> values."
> 
> I assume that the wording in 8.4 was borrowed from 7.2.2.
> 
> The issue here is presumably that it is unclear which member of the 
> union is supposed to be assigned the value.  And for a member of a 
> packed struct, it may be unclear how to handle the conflict between 
> the overall initialization of the struct as an integral value, and the 
> initialization of the member.  A packed struct is effectively a union 
> between the separate members and the vector value that the entire 
> struct represents.
> 
> The text in 7.2.2 refers to unions that are members of unpacked 
> structs because it is only members of unpacked structs that can have 
> default values like this.  So there is no need to say it about unions 
> in general.
> 
> Similarly, the text about rand in 18.4 comes immediately after a 
> reference to rand qualifiers on members of unpacked structs.
> 
> Allowing a rand qualifier on a union would be a problem, since it 
> would be unclear which member of the union should be assigned the 
> random value.  So why does this only mention unions that are members 
> of unpacked structs?  It appears that this is because other unions 
> have already been excluded.  8.4 lists everything you can qualify with 
> rand, and it does not list unions.
> But when it says it is allowed for a member of an unpacked struct, 
> that seems to allow a loophole, since that member could be a union.  
> So this text is saying that a union still isn't allowed.
> 
> It would have been more general if it had said that a struct member 
> could be made rand, as long as that member was itself of a type that 
> could be made rand.
> 
> 
> >Does above forbids the code:
> >
> >typedef union packed { reg a; bit b;} TU;
> >
> >typededef struct {
> >
> >    rand int a;//illegal as this struct has  union inside
> 
> This is fine, as the member does not contain a union.
> 
> >    rand TU v; //illegal
> 
> This is illegal, as the member contains a union.  It isn't a major 
> issue in this simple case, but one can imagine cases where it would 
> be.  For example, what if it were a union between an enum and an int?  
> Which member of the union should be randomized?  If it is the enum, 
> then I assume it is restricted to the defined literals of the enum.  
> If it is the int, then it could be any value in its range.  These give 
> different results.  It could have been defined to randomize the first 
> (or last) member of the union, but instead it was made illegal.
> 
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
> 
> 
> 
---------------------------------------------------------------------
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.