| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 172
|
| Category | errata
|
| Synopsis | 3.5 Implicit Declarations - moved from #125B
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Oct 24 2002
|
| Originator | Shalom Bresticker <Shalom.Bresticker@motorola.com>
|
| Release | 2001b: 3.5
|
| Environment |
|
| Description |
In #125B, I asked what are the rules for implicit declarations where there appears (on the LHS of a continuous assignment or in the port connection of a primitive or module connection) a bit-select or part-select or concatenation. It appears that the same rules should be used for continuous assignments as for module connections. For module connections, Verilog-XL does not allow bit-selects or part-selects. It allows concatenations and does an implicit declaration for each undeclared identifier within the concatenation. I will propose wording to that effect to be inserted into 3.5. Note that in Verilog-XL, if the wire declaration appears AFTER the module instance, then Verilog-XL relates to the declaration as illegal (identifier previously declared). -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 "The devil is in the details." |
| Fix |
|
| Audit-Trail |
From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/172: 3.5 Implicit Declarations - moved from #125B Date: Mon, 28 Oct 2002 08:54:12 +0200 (IST) >Category: errata >Confidential: no >Originator: Shalom.Bresticker@motorola.com >Release: 2001b >Class: TBD >Description: Also, implicit declarations are not made for hierarchical identifiers. From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/172: 3.5 Implicit Declarations - moved from #125B Date: Sun, 03 Nov 2002 16:24:21 +0200 >Category: errata >Confidential: no >Originator: Shalom Bresticker <Shalom.Bresticker@motorola.com> >Release: 2001b >Class: TBD >Description: I propose the following wording for 3.5: "For a concatenation, an implicit declaration shall be assumed for each undeclared identifier in the concatenation. An implicit declaration shall not be assumed for a hierarchical identifier (see 12.4), nor for an identifier with a range (vector)." From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com Cc: Subject: errata/172: Implicit declarations Date: Fri, 23 May 2003 18:40:45 -0400 (EDT) Shalom has pointed out that with named begin-end blocks inside generates, a reference to an identifier could be resolved to a declaration in a surrounding scope. An implicit declaration should not be created even though the net is not declared in the immediate scope. This seems pretty obvious to me, but maybe others don't agree. A related question is if there is a reference inside such a nested scope which creates an implicit declaration, what scope should the declaration be created in? It seems pretty clear that it should appear in the same scope as the construct (instance or continuous assign) that referenced it, but this should probably be specified. The text for implicit declarations was already getting cumbersome, and this would make it more so. Perhaps it needs to be reorganized. The case where there is only a port declaration is different from the cases for references in instances or continuous assigns, which are similar to each other. Separately specifying the same rules for the latter two cases is part of the clumsiness of the current organization. And those rules should be separated into independent pieces: the two situations that call for it (instance ports and cont assign LHS), what constitutes a reference (the original point of this erratum, involving bit and part selects and concatenations), what constitutes an undeclared identifier (Shalom's first point above), what scope the declaration is made in (the second point above), and how the net type is determined for the declaration. Would anyone have a problem with a complete rewrite along these lines? The difficulty of adding more to the description without reorganizing it is why I haven't provided a proposal on this yet. Steven Sharp sharp@cadence.com From: Michael McNamara <mac@verisity.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: RE: errata/172: Implicit declarations Date: Tue, 27 May 2003 08:22:38 -0700 Steven Sharp writes: > Precedence: bulk > > The following reply was made to PR errata/172; it has been noted by GNATS. > > From: Steven Sharp <sharp@cadence.com> > To: etf-bugs@boyd.com > Cc: > Subject: errata/172: Implicit declarations > Date: Fri, 23 May 2003 18:40:45 -0400 (EDT) > > Shalom has pointed out that with named begin-end blocks inside generates, > a reference to an identifier could be resolved to a declaration in a > surrounding scope. An implicit declaration should not be created even > though the net is not declared in the immediate scope. This seems pretty > obvious to me, but maybe others don't agree. > > A related question is if there is a reference inside such a nested scope > which creates an implicit declaration, what scope should the declaration > be created in? It seems pretty clear that it should appear in the same > scope as the construct (instance or continuous assign) that referenced it, > but this should probably be specified. > > The text for implicit declarations was already getting cumbersome, and > this would make it more so. Perhaps it needs to be reorganized. The > case where there is only a port declaration is different from the cases > for references in instances or continuous assigns, which are similar to > each other. Separately specifying the same rules for the latter two > cases is part of the clumsiness of the current organization. And those > rules should be separated into independent pieces: the two situations > that call for it (instance ports and cont assign LHS), what constitutes > a reference (the original point of this erratum, involving bit and part > selects and concatenations), what constitutes an undeclared identifier > (Shalom's first point above), what scope the declaration is made in (the > second point above), and how the net type is determined for the declaration. > > Would anyone have a problem with a complete rewrite along these lines? > The difficulty of adding more to the description without reorganizing it > is why I haven't provided a proposal on this yet. > > Steven Sharp > sharp@cadence.com > As part of or 1364-2005 effort, I endorse looking at rewriting entire sections with a goal of achieving clarity, based on the accumulation of ten years of additions to the language. |
| Unformatted |
|
Hosted by Boyd Technology