ISSUE 629

Number 629
Category errata
Synopsis 12.4.2: generate clarification on naming of nested constructs
State lrmdraft
Class errata-simple
Arrival-DateOct 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