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

From: Steven Sharp <sharp_at_.....>
Date: Tue Sep 08 2009 - 17:41:40 PDT
>From: "Daniel Mlynek" <daniel.mlynek@aldec.com>

>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).

I agree that this is reasonable.  I suspect that Shalom is right, and
whoever wrote this was only thinking of unpacked unions at the time.

> Another problem is that
>union are allowed as arguments for std::randomize function so this is
>inconsistence.

I would hope that implementors would figure out that this was a problem
and disallow it.  It is entirely unclear how you would randomize an
unpacked union.

If they have not disallowed it, the results may vary.  An implementor
might have decided to randomize the first member.  Or they might try to
treat it as a struct and randomize all of the members in some order.  In
that case, you would get an overlay of the randomizations in that order.


>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;

Yes, this is what I would expect for the current LRM rules.  However, I
don't see any problem with allowing packed unions as you have said.  In
that case, this would be legal.

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 Tue Sep 8 17:42:27 2009

This archive was generated by hypermail 2.1.8 : Tue Sep 08 2009 - 17:43:20 PDT