Just forwarding the below private discussion to the reflector, so that it will be visible from 1500. Until the issue of "declaration before use" is formally resolved, the example in the bottom of the original mail may be considered valid, or at least arguable ("bit [$bits(m2) - 1:0] m1; bit [$bits(m1) - 1:0] m2;"). --Yulik. ________________________________ From: Bresticker, Shalom Sent: Wednesday, August 02, 2006 10:32 AM To: Feldman, Yulik; 'Rich, Dave' Cc: Bresticker, Shalom Subject: RE: [sv-bc] forward typedef declarations I just added a bugnote to 1268 where I stated that this seems to be missing in 1364, just implicitly understood there. Shalom ________________________________ From: Feldman, Yulik Sent: Wednesday, August 02, 2006 10:17 AM To: Bresticker, Shalom; 'Rich, Dave' Subject: RE: [sv-bc] forward typedef declarations Thanks, I wouldn't find this without your help! Do you know where in Verilog LRM this is stated? --Yulik. ________________________________ From: Bresticker, Shalom Sent: Tuesday, August 01, 2006 11:13 PM To: Feldman, Yulik; 'Rich, Dave' Cc: Bresticker, Shalom Subject: RE: [sv-bc] forward typedef declarations In 1800, 6.1 says, "SystemVerilog follows Verilog by requiring data to be declared before they are used, apart from implicit nets." Shalom ________________________________ From: Feldman, Yulik Sent: Tuesday, August 01, 2006 6:51 PM To: Rich, Dave; Bresticker, Shalom Subject: RE: [sv-bc] forward typedef declarations I've added a link to this discussion to 1500, just in case. Regarding the SV-BC/SV-EC choice, I'm not sure what the policy is. At least from what I see on the reflector, lots of things originally introduced by EC are discussed in BC now (which makes sense, since these features are now part of the standard, not future enhancements). So I assumed that whatever is already a part of LRM is a BC job now. Dave, regarding the "declaration before use" principle, is it part of the LRM already? Can you, please, show me where? --Yulik. ________________________________ 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 6:13 PM To: Bresticker, Shalom; sv-bc@server.eda-stds.org Subject: RE: [sv-bc] forward typedef declarations Forward typedefs were added by the sv-ec, so they should be the ones to modify it. ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Tuesday, August 01, 2006 8:08 AM To: Rich, Dave; sv-bc@server.eda-stds.org Subject: RE: [sv-bc] forward typedef declarations If that was the intention, then it should go to SV-BC instead of or in addition to SV-EC and it should be addressed in 4.9 in addition to or instead of 7.24. In fact, a lot of 4.9 then has to change or be deleted, if I understand you. Shalom ________________________________ From: Rich, Dave [mailto:Dave_Rich@mentor.com] Sent: Tuesday, August 01, 2006 6:04 PM To: Bresticker, Shalom; Feldman, Yulik; sv-bc@server.eda-stds.org Subject: 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.Received on Wed Aug 2 01:47:56 2006
This archive was generated by hypermail 2.1.8 : Wed Aug 02 2006 - 01:48:32 PDT