| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 570
|
| Notify-List |
|
| Category | errata
|
| Synopsis | 12.5 "Upwards name referencing" description has problems
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Apr 09 2004
|
| Originator | sharp@cadence.com (Behavioral Task Force)
|
| Release |
|
| Environment |
|
| Description |
Section 12.5 "Upwards name referencing" has a number of problems. The syntax only allows for names with two components: a module identifier, and an item_name which is a simple identifier. This means that it doesn't allow for upward references that have more path components, even though such references are used in the examples (and clearly work in tools). The wording also implies that when the first name component matches an instance, the name must be found in that instance. The tools I am aware of will continue searching upward if the full name is not matched. |
| Fix |
Unknown |
| Audit-Trail |
From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com Cc: Subject: errata/570: more problems Date: Mon, 12 Apr 2004 18:26:17 -0400 (EDT) The description also ignores the possibility that the module_instance_name could actually be a named block scope name instead. And it ignores the possibility that an upward search might need to traverse upward through named blocks and a task or function scope before reaching the module level. Example of these: module top; initial begin:foo1 begin:foo2 reg bar; end begin:foo3 $display(foo2.bar); end end endmodule Here foo2 is not a module name, and the upward reference traverses up from scope foo3 to scope foo1 before finding the block foo2 and resolving the name. The LRM description doesn't cover this at all. I also don't think it specifies what should happen if a hierarchical name matches both an upward reference and a different full hierarchical reference. For example, if there is an additional top-level module in the previous example: module foo2; integer bar; endmodule Which one does the name foo2.bar resolve to? 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/570: errata/570: more problems Date: Mon, 12 Apr 2004 17:56:59 -0700 It may have been a dream, but I recall far better language than what I read today in the specification for hierarchial name referencing. Did we fix this, and loose the text? -- On Apr 12 2004 at 15:10, Steven Sharp sent a message: > To: etf-bugs@boyd.com > Subject: "errata/570: errata/570: more problems" > The following reply was made to PR errata/570; it has been noted by GNATS. > > From: Steven Sharp <sharp@cadence.com> > To: etf-bugs@boyd.com > Cc: > Subject: errata/570: more problems > Date: Mon, 12 Apr 2004 18:26:17 -0400 (EDT) > > The description also ignores the possibility that the module_instance_name > could actually be a named block scope name instead. And it ignores the > possibility that an upward search might need to traverse upward through > named blocks and a task or function scope before reaching the module level. > > Example of these: > > module top; > initial > begin:foo1 > begin:foo2 > reg bar; > end > begin:foo3 > $display(foo2.bar); > end > end > endmodule > > Here foo2 is not a module name, and the upward reference traverses up from > scope foo3 to scope foo1 before finding the block foo2 and resolving the > name. The LRM description doesn't cover this at all. > > I also don't think it specifies what should happen if a hierarchical name > matches both an upward reference and a different full hierarchical reference. > For example, if there is an additional top-level module in the previous > example: > > module foo2; > integer bar; > endmodule > > Which one does the name foo2.bar resolve to? > > Steven Sharp > sharp@cadence.com > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/570: 12.5 "Upwards name referencing" description has problems Date: Sun, 25 Apr 2004 12:12:14 +0300 Regarding the following: Steven Sharp wrote: > I took an action item to rewrite the rules for upward name resolution to > deal with the issue Cliff pointed out on page 19. The movement up the > hierarchy in step b would not necessarily go to the outermost scope in the > parent module, if the child module was instantiated inside a generate > block. It would go to the scope that the child module was instantiated > in. > > However, there is nothing in the rules to cover traversing up through > nested generate block scopes either. So if that situation came up, it > still wouldn't be covered by removing "outermost" as Cliff suggested. > > This section needs a lot more work than fixing this one issue. I don't > think that this minor change would do much to help the problem. I filed > a separate erratum (errata/570) to collect some of these issues that I > have found. I think that we should drop this from the amendments for > generate and deal with it as a separate issue, with a bigger rewrite. I was not in the last meeting, so maybe I am misunderstanding, but: step a of the reworded version of this section in the generate proposal does take into account the possibility of a nested generate scope. You get to step b, looking at the module scope, only if you have not found scope_name within one of the nested scopes. That is, if you are in scope a.b.c, where a is a module, then you start in c. If it is in c, then it is a downward reference, and everything is easy. Otherwise, you go up to b, and look for scope_name there. Only if you do not find it there do you go up to the module level, a. It might seem that step b is repeating step a, but the reason is in order to say in step c that step b should be repeated. It is true that the first paragraph of 12.5/12.6 "Upwards name referencing" does not talk about nested scopes. It is also true that the more detailed description, starting "Upwards name references can also be done with names of the form scope_name.item_name where scope_name is either a module instance name or a generate block name," does not take into account named blocks. The next section, "Scope Rules", does say, however, in the new proposal, "If an identifier is referenced with a hierarchical name,the path can start with a module name,instance name, task,function, named block or named generate block." I think the wording in the generate proposal is superior to the current wording and supports generate blocks fairly well. So I do not agree that we should delete it from the generate proposal. Doing that would make the current wording even more deficient than it is now. I think we should use the wording in the generate proposal as a basis for further work, which indeed might involve rewriting the entire section from scratch. I also think the rewrite should involve the next section, ""Scope Rules", as well as "Upward Name Referencing", since they are so closely connected. In fact, I think the two sections should be combined. -- 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 [x]Motorola General Business Information [ ]Motorola Internal Use Only [ ]Motorola Confidential Proprietary From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: errata/570: Re: errata/570: 12.5 "Upwards name referencing" description has problems Date: Mon, 26 Apr 2004 16:53:54 -0400 (EDT) >Date: Sun, 25 Apr 2004 02:00:01 -0700 >From: Shalom Bresticker <Shalom.Bresticker@motorola.com> > I think the wording in the generate proposal is superior to the current wording > and supports generate blocks fairly well. So I do not agree that we should > delete > it from the generate proposal. Doing that would make the current wording even > more > deficient than it is now. I am not suggesting that this should be deleted from the generate proposal. As you say, the wording in the generate proposal is improved. It actually covers some of what I have raised here (i.e. the part about looking upward in enclosing scopes covers the issue I raised here with named procedural blocks in addition to named generate blocks). However, Cliff pointed out that in the version in the generate proposal, step b says to move up to the outermost scope of the instantiating module (just as the current wording does), and that this is wrong. It should move up to the scope of the instantiation instead. This is related to generates, since a generate block is the only scope where in instantiation is not an outermost module scope. Cliff suggested just removing the word "outermost" from the proposed text. But once you recognize that step b may leave you inside a nested scope, it is clear that you can't just repeat step b each time. You must also include a step (like step a) to move up scopes inside a module each time before moving up to the next module. So this simple amendment raises a new issue. I took an action item to propose an amendment to the generate proposal to fix this. In the process, I found a number of other problems with the upward name referencing text. Since these were not just related to generates, I filed this erratum separately. And since we need so much rewriting that doesn't involve generates, it doesn't make sense to me to try to fix it further in the generate proposal. > I think we should use the wording in the generate proposal as a basis for > further work, > which indeed might involve rewriting the entire section from scratch. I agree completely. I filed this erratum to document these issues independently from the generate proposal. If the generate proposal is approved, then some of these issues may be partly resolved, but the rest still need work. Steven Sharp sharp@cadence.com From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: errata/570: 12.5 "Upwards name referencing" description has problems Date: Mon, 26 Apr 2004 18:50:27 -0400 (EDT) Reading this again, I think I see the cause for confusion. I wrote: >> I think that we should drop this from the amendments for >> generate and deal with it as a separate issue, with a bigger rewrite. I did not mean "drop this from the proposal to amend generates". I meant "drop this from the amendments to the generate proposal". In other words, leave the wording in the generate proposal alone, without amending it for this issue. In the last meeting, we discussed amendments to the generate proposal (which hasn't been approved by the VSG yet). So this wording seemed clear to me, but I can see now how you might have interpreted it differently. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/570: 12.5 "Upwards name referencing" description has problems Date: Tue, 27 Apr 2004 21:52:42 +0300 (IDT) OK, now I understand you. You mean the case where you have something like generate if (...) begin: cucu // gen-if m m() ; // module instantiation of cucu.m endgenerate and you have an upward reference within m. After you don't find it within m, you have to look for it within cucu. I admit that possibility never crossed my mind. Shalom > However, Cliff pointed out that in the version in the generate proposal, > step b says to move up to the outermost scope of the instantiating module > (just as the current wording does), and that this is wrong. It should move > up to the scope of the instantiation instead. This is related to generates, > since a generate block is the only scope where in instantiation is not an > outermost module scope. > > Cliff suggested just removing the word "outermost" from the proposed text. > But once you recognize that step b may leave you inside a nested scope, > it is clear that you can't just repeat step b each time. You must also > include a step (like step a) to move up scopes inside a module each time > before moving up to the next module. So this simple amendment raises a new > issue. -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Reuse Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary |
| Unformatted |
|
Hosted by Boyd Technology