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.