RE: [sv-bc] forward typedef declarations

The summary yes, the full description, no.

 

 

________________________________

From: owner-sv-bc@server.eda-stds.org
[mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Bresticker, Shalom
Sent: Tuesday, August 01, 2006 7:59 AM
To: Rich, Dave; Feldman, Yulik; sv-bc@server.eda-stds.org
Subject: RE: [sv-bc] forward typedef declarations

 

Dave,

 

Mantis 1500 as worded today is only about forward typedefs of classes,
not about other 'types' (pun intended) of forward typedefs.

 

Shalom

 

________________________________

From: owner-sv-bc@server.eda-stds.org
[mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Rich, Dave
Sent: Tuesday, August 01, 2006 5:52 PM
To: Feldman, Yulik; sv-bc@server.eda-stds.org
Subject: RE: [sv-bc] forward typedef declarations

 

Yulik,

 

I entered mantis 1500
<http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=0001500>  a few
months ago which suggests that a forward typedef be used *only* to
declare a reference to that type.

 

SystemVerilog does not allow a variable to be referenced before it is
declared, except in a hierarchical reference, which is not allowed in a
constant expression. So your last example is illegal.

 

Dave

 

 

________________________________

From: owner-sv-bc@server.eda-stds.org
[mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Feldman, Yulik
Sent: Tuesday, August 01, 2006 7:32 AM
To: sv-bc@server.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.