RE: [sv-bc] forward typedef declarations

Ok, thanks.

The issue remains then only if the typedef is something whose size is then used explicitly or implicitly, as Yulik described.

-mac

 -----Original Message-----
From: 	Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent:	Tuesday, August 01, 2006 08:22 AM Pacific Standard Time
To:	Michael (Mac) McNamara; Feldman, Yulik; sv-bc@eda-stds.org
Subject:	RE: [sv-bc] forward typedef declarations

This is SystemVerilog, not C++. Class variables are handles, not
objects.

> -----Original Message-----
> From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-
> stds.org] On Behalf Of Michael (Mac) McNamara
> Sent: Tuesday, August 01, 2006 8:06 AM
> To: Feldman, Yulik; sv-bc@server.eda-stds.org
> Subject: RE: [sv-bc] forward typedef declarations
> 
> Yes, but isn't:
> 
> typedef Class C2;
> 
> class C1 ;
>   C2 c;
> endclass
> 
> class C2;
>    C1 c;
> endclass
> 
> Implicitly, and primarily using sizeof(C2) in order to properly
allocate
> space for C1?
> 
> -mac
> 
>  -----Original Message-----
> From: 	Feldman, Yulik [mailto:yulik.feldman@intel.com]
> Sent:	Tuesday, August 01, 2006 07:33 AM Pacific Standard Time
> To:	sv-bc@eda-stds.org
> Subject:	[sv-bc] forward typedef declarations
> 
> Hi,
> 
> 
> 
> I would like to raise the concerns I have regarding the freedom SV
gives
> to the usage of forward typedef declarations. The only restriction the
> LRM apparently has is that "the actual type definition of a forward
> typedef declaration shall be resolved within the same local scope or
> generate block". However, with this restriction being the only
> restriction, the designer can write declarations that are not
> resolvable:
> 
> 
> 
> typedef s2;
> 
> 
> 
> typedef struct {
> 
>             bit [$bits(s2) - 1:0] m1;
> 
> } s1;
> 
> 
> 
> typedef struct {
> 
>             bit [$bits(s1) - 1:0] m2;
> 
> } s2;
> 
> 
> 
> Here, the MSB bounds of the two arrays may be resolved to any value to
> satisfy the type system.
> 
> 
> 
> Or, the designer can write declarations that are resolvable, but with
> great complexity:
> 
> 
> 
> typedef s2;
> 
> 
> 
> typedef struct {
> 
>             bit [$bits(s2) * 2 - 1:0] m1;
> 
> } s1;
> 
> 
> 
> typedef struct {
> 
>             bit [$bits(s1) - 2 - 1:0] m2;
> 
> } s2;
> 
> 
> 
> Here, the MSB of 'm1' should be 2 and the MSB of 'm2' should be 4 for
> the types to be valid.
> 
> 
> 
> In general, the compiler may be required to invoke a constraint solver
> to solve the type system, unless I miss something. This is clearly
> undesirable, since it complicates the tool and the processing, while
> giving very little benefit to the end user. As I understand, the
> original reason for introducing the forward typedefs was to allow code
> like the following (the example is taken from section 7.24):
> 
> 
> 
> typedef class C2;
> 
> 
> 
> class C1;
> 
> C2 c;
> 
> endclass
> 
> 
> 
> class C2;
> 
> C1 c;
> 
> endclass
> 
> 
> 
> While the intention is good, I have a feeling that the LRM is missing
> some restrictions on the usage of the typedefs, that would disallow
the
> complex and/or ambiguous usages as shown above. In C, the usage of
> forward declarations is allowed only when certain conditions are met.
> For example, sizeof(forward_decl) is forbidden, unless the full
> definition of the type is available. It may make sense to restrict SV
> forward typedefs to usages that do not require knowledge about the
> internals of the type, such as its size and probably other properties.
> If such usages are forbidden, it won't be possible to write a code
like
> above, thus removing the language ambiguity and making the life easier
> for tool implementers. The code similar to that in section 7.24 will
> still remain compilable.
> 
> 
> 
> Note that such ambiguities may also arise without forward typedef
> declarations, due to SV allowing usage before declaration for non-type
> objects:
> 
> 
> 
> bit [$bits(m2) - 1:0] m1;
> 
> bit [$bits(m1) - 1:0] m2;
> 
> 
> 
> It looks that the same restrictions that could be applied to forward
> type declarations should be applied to references to not-yet-declared
> objects as well, generalizing the solution.
> 
> 
> 
> I'll be glad to hear opinion of others on that issue.
> 
> 
> 
> Thanks,
> 
>             Yulik.
>