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

From: Daniel Mlynek <daniel.mlynek_at_.....>
Date: Mon Sep 07 2009 - 22:53:10 PDT
only fields on unpacked struct can have default values (initialization). st2
is unpacked so all simulatros should fail.
 
In example from yours 2nd email all is ok there is no field initialization
(field default value) for both structs - there is only initialization of
variable of type packed struct - which is legal. In this initialization
packed member is initialized with int which is legal as packed struct is
assignment comatybile with packed vectors.
 
DANiel

  _____  

From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] 
Sent: 6 września 2009 16:57
To: Steven Sharp
Cc: sv-ec@eda.org; daniel.mlynek@aldec.com
Subject: Re: [sv-ec] rand in struct with union members


Hi Steven,
I have tried with another example:
module top;
    typedef struct packed {
        int x;
    } st1;
    typedef struct packed {
        st1 s1 = '{default:0};
        int y;
    } st2;
endmodule

This is failed by all simulators. Does LRM want to mean this initialization?
Please confirm.

Regards

Surya


-------- Original Message  --------
Subject: Re:[sv-ec] rand in struct with union members
From: Surya Pratik Saha  <mailto:spsaha@cal.interrasystems.com>
<spsaha@cal.interrasystems.com>
To: Steven Sharp  <mailto:sharp@cadence.com> <sharp@cadence.com>
Cc: sv-ec@eda.org, daniel.mlynek@aldec.com
Date: Sunday, September 06, 2009 8:14:15 PM


Hi Steven,
I just want to understand the text of LRM in 7.2.2 by using the following
example.
module top;
    typedef struct packed {
        int x;
    } st1;
    typedef struct packed {
        st1 s1;
        int y;
    } st2;
    st2 s = '{y:1, s1:'{default:0}};
endmodule

But all the standard simulators pass the case. Can you please explain it
with an example?

Regards

Surya

  


-------- Original Message  --------
Subject: Re:[sv-ec] rand in struct with union members
From: Steven Sharp  <mailto:sharp@cadence.com> <sharp@cadence.com>
To: sv-ec@eda.org, daniel.mlynek@aldec.com
Date: Saturday, September 05, 2009 2:50:48 AM


From: "Daniel Mlynek"  <mailto:daniel.mlynek@aldec.com>
<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.
Received on Mon Sep 7 22:58:21 2009

This archive was generated by hypermail 2.1.8 : Mon Sep 07 2009 - 22:58:30 PDT