| Number | 629
|
| Category | errata
|
| Synopsis | 12.4.2: generate clarification on naming of nested constructs
|
| State | lrmdraft
|
| Class | errata-simple
|
| Arrival-Date | Oct 28 2004
|
| Originator | Shalom.Bresticker@freescale.com
|
| Release | 2005: 12.4.2
|
| Description |
See the attached mail for background. PROPOSAL: In para. 5 of new 12.4.2 ("Conditional generate constructs"), which says, "If a generate block in a conditional generate construct consists of only one item which is itself a conditional generate construct, and if that item is not surrounded by begin/end keywords, then this generate block is not treated as a separate scope. The generate construct within this block is said to be directly nested. The generate blocks of the directly nested construct are treated as if they belong to the outer construct, and therefore can have the same name as the generate blocks of the outer construct. This allows complex conditional generate schemes to be expressed without creating unnecessary levels of generate block hierarchy. The most common use of this would be to create an if-else-if generate scheme with any number of else-if clauses, all of which can have generate blocks with the same name because only one will be selected for instantiation. It is permissible to combine if-generate and case-generate constructs in the same complex generate scheme. Note that direct nesting applies only to conditional generate constructs nested in conditional generate constructs. It does not apply in any way to loop generate constructs." CHANGE the sentence "The generate blocks of the directly nested construct are treated as if they belong to the outer construct, and therefore can have the same name as the generate blocks of the outer construct." TO "The generate blocks of the directly nested construct are treated as if they belong to the outer construct. Therefore they can have the same name as the generate blocks of the outer construct, and they cannot have the same name as any declaration in the scope enclosing the outer construct (including other generate blocks in other generate constructs in that scope)." ADD a paragraph break between "This allows complex conditional generate schemes to be expressed without creating unnecessary levels of generate block hierarchy." and "The most common use of this would be to create an if-else-if generate scheme with any number of else-if clauses, ..." Shalom -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification 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 ---------- Forwarded message ---------- Date: Thu, 1 Apr 2004 11:05:52 -0500 (EST) From: Jason Woolf <jasonw@cadence.com> To: etf@boyd.com, gordon_vreugdenhil@mentorg.com Subject: Re: Question on generate constructs Gord, Yes, both "block" and "block2" would conflict with similar declarations in the scope enclosing the generate construct. This is implied by the statement: The generate blocks of the directly nested construct are treated as if they belong to the outer construct... In other words, the rules from the previous paragraphs about name conflicts apply to the names of blocks in directly nested constructs. So they can have the same name as other blocks in the construct (this is explicitly stated later in the same sentence) and all block names would conflict with names in the enclosing scope (this is merely implied). How about: The generate blocks of the directly nested construct are treated as if they belong to the outer construct. Therefore they can have the same name as the generate blocks of the outer construct, and they cannot have the same name as any declaration in the scope enclosing the outer construct (including other generate blocks in other generate constructs in that scope). I am compelled to make this addition wordier than your suggestion, since the wording of the conflict rule in the previous paragraphs did not mention the idea of "belonging" the the outer scope. -Jason > From: "Vreugdenhil, Gordon" <gordon_vreugdenhil@mentorg.com> > To: etf@boyd.com > Date: Thu, 01 Apr 2004 07:23:05 -0800 > Subject: Question on generate constructs > X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:98.0742 C:79.5348 ) > > I have a clarification question regarding the 2005 generate > rules. Given: > > if (c) > begin:block > end > else if (c2) > begin:block > end > > I understand that since the label "block" is in a directly nesting > "if" that identifier "block" conflicts with any other declaration of > "block" in the parent scope even if neither branch is elaborated. > > However, given: > > if (c) > begin:block > end > else if (c2) > begin:block2 // Note: this is named "block2" > end > > Do the rules for directly nesting conditions imply that *both* > "block" and "block2" would cause conflicts in the parent scope? > If so, perhaps a statement should be added along the lines of > the following: "All distinct labels of directly nesting conditions > are considered to exist within the parent scope.". This would > also cover situations such as: > > if (c) > begin:block > end > else if (c2) > begin:block2 // Note: this is named "block2" > end > else > begin:block // Note: back to label "block" > end > > > Gord > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil, Staff Engineer 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com |
| Fix |
In para. 5 of new 12.4.2 ("Conditional generate constructs"), which says, CHANGE the sentence "The generate blocks of the directly nested construct are treated as if they belong to the outer construct, and therefore can have the same name as the generate blocks of the outer construct." TO "The generate blocks of the directly nested construct are treated as if they belong to the outer construct. Therefore they can have the same name as the generate blocks of the outer construct, and they cannot have the same name as any declaration in the scope enclosing the outer construct (including other generate blocks in other generate constructs in that scope)." ADD a paragraph break between "This allows complex conditional generate schemes to be expressed without creating unnecessary levels of generate block hierarchy." and "The most common use of this would be to create an if-else-if generate scheme with any number of else-if clauses, ..." |
| Audit-Trail |
Fix replaced by Shalom.Bresticker@freescale.com on Thu Oct 28 07:26:32 2004 In para. 5 of new 12.4.2 ("Conditional generate constructs"), which says, CHANGE the sentence "The generate blocks of the directly nested construct are treated as if they belong to the outer construct, and therefore can have the same name as the generate blocks of the outer construct." TO "The generate blocks of the directly nested construct are treated as if they belong to the outer construct. Therefore they can have the same name as the generate blocks of the outer construct, and they cannot have the same name as any declaration in the scope enclosing the outer construct (including other generate blocks in other generate constructs in that scope)." ADD a paragraph break between "This allows complex conditional generate schemes to be expressed without creating unnecessary levels of generate block hierarchy." and "The most common use of this would be to create an if-else-if generate scheme with any number of else-if clauses, ..." |
| Unformatted |
|
Hosted by Boyd Technology