ISSUE 17

Number 17
Category errata
Synopsis 12.1.3 is not clear enough about permitted defparam usage
State lrmdraft
Class errata-discuss
Arrival-DateAug 13 2001
Originator Shalom.Bresticker@motorola.com
Release 2001b, 12.1.3, 12.2.1
Environment
Description
12.1.3 says (para. 7),

"a defparam statement within the generate scope or within a
hierarchy instantiated within the generate scope shall only
modify the value of a parameter declared within the generate
scope or within a hierarchy instantiated within the generate
scope."

It is unclear whether a defparam may reference a different
iteration of a generate loop.

E.g.,
genvar i;

generate for(i=0; i < 8; i = i+1)
begin : somename
flop my_flop(in[i], in1[i], out1[i]);
defparam somename[i+1].my_flop.xyz = i ;
end endgenerate

There have been different interpretations of whether this is
permitted or not.
This must be clarified.
Fix
The following proposal was worked out by Jason and Gord,
only slightly edited by Shalom.

12.1.3 was deleted by the resolution of issue #113.

That leaves the following discussion in para. 1 of 12.2.1:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. However, a defparam
statement in a hierarchy under a generate scope or array of
instances shall not change a parameter value outside that
hierarchy. See 12.5 for hierarchical names."

(The xref is to 12.4 in 2001/D3, but issue #113 bumps 12.4
to 12.5 instead.)


This proposal is to change para. 1 of 12.2.1 to:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. See 12.5 for
hierarchical names.

However, a defparam statement in a hierarchy in or under a
generate block instance (see 12.4) or an array of instances
shall not change a parameter value outside that hierarchy.

Note: Each instantiation of a generate block is considered
to be a separate hierarchy scope. Therefore this rule
implies that a defparam statement in a generate block may
not target a parameter in another instantiation of the same
generate block, even when the other instantiation is created
by the same loop generate construct. For example, the
following code is not allowed:

genvar i;

generate
for(i=0; i < 8; i = i+1) begin : somename
flop my_flop(in[i], in1[i], out1[i]);
defparam somename[i+1].my_flop.xyz = i ;
end
endgenerate

Similarly, a defparam statement in one instance of an array
of instances may not target a parameter in another instance
of the array.
Audit-Trail
From: Shalom.Bresticker@freescale.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted
defparam usage
Date: Wed, 5 May 2004 12:39:13 +0300 (IDT)

Does the current generate proposal (errata/113) cover this issue?

Shalom


On Mon, 13 Aug 2001 Shalom.Bresticker@motorola.com wrote:

> 12.1.3 says (para. 7),
>
> "a defparam statement within the generate scope or within a
> hierarchy instantiated within the generate scope shall only
> modify the value of a parameter declared within the generate
> scope or within a hierarchy instantiated within the generate
> scope."
>
> It is unclear whether a defparam may reference a different
> iteration of a generate loop.
>
> E.g.,
> genvar i;
>
> generate for(i=0; i < 8; i = i+1)
> begin : somename
> flop my_flop(in[i], in1[i], out1[i]);
> defparam somename[i+1].my_flop.xyz = i ;
> end endgenerate
>
> There have been different interpretations of whether this is
> permitted or not.
> This must be clarified.

From: Jason Woolf <jasonw@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com
Cc:
Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted defparam usage
Date: Wed, 5 May 2004 12:07:17 -0400 (EDT)

Shalom,

That paragraph appears in section 12.2.1 also. Since 12.1.3 is deleted by
the generate proposal, we should be referencing the 12.2.1 paragraph.

I do believe there should be a clarification added to in 12.2.1 to help with
this issue. However, technically, I believe that the generate proposal
does clear up this confusion by defining what is meant by the term
"generate scope". Each instance of a generate block is a separate generate
scope. Therefore, the rule means that it is not permitted to modify a
parameter under a different instance of the same generate block, even when
the other instance is created by the same loop generate construct.

So, I would suggest adding the following note to the rule:

Note: Since each instance of a generate block is a separate generate scope,
this rule implies that a defparam statement in a generate block may not
affect parameters under other instances of the same generate block. For
example...

<include loop genreate example>

-Jason


> Date: Wed, 5 May 2004 02:20:00 -0700
> From: Shalom.Bresticker@freescale.com
> To: etf-bugs@boyd.com
> Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted
defparam usage
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wa.boyd.com
> X-Spam-Level:
> X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no
version=2.63
>
> The following reply was made to PR errata/17; it has been noted by GNATS.
>
> From: Shalom.Bresticker@freescale.com
> To: etf-bugs@boyd.com
> Cc:
> Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted
> defparam usage
> Date: Wed, 5 May 2004 12:39:13 +0300 (IDT)
>
> Does the current generate proposal (errata/113) cover this issue?
>
> Shalom
>
>
> On Mon, 13 Aug 2001 Shalom.Bresticker@motorola.com wrote:
>
> > 12.1.3 says (para. 7),
> >
> > "a defparam statement within the generate scope or within a
> > hierarchy instantiated within the generate scope shall only
> > modify the value of a parameter declared within the generate
> > scope or within a hierarchy instantiated within the generate
> > scope."
> >
> > It is unclear whether a defparam may reference a different
> > iteration of a generate loop.
> >
> > E.g.,
> > genvar i;
> >
> > generate for(i=0; i < 8; i = i+1)
> > begin : somename
> > flop my_flop(in[i], in1[i], out1[i]);
> > defparam somename[i+1].my_flop.xyz = i ;
> > end endgenerate
> >
> > There have been different interpretations of whether this is
> > permitted or not.
> > This must be clarified.
>
>

From: Gordon Vreugdenhil <gvreugde@comcast.net>
To: Jason Woolf <jasonw@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted defparam
usage
Date: Wed, 05 May 2004 20:33:41 -0700

Jason, I like the intent of the note, but might suggest slightly
different wording. Perhaps something along the lines of the
following:

Note: Each instantiation of a generate block is considered
to be a separate generate scope. Thus, this rule implies
that a defparam statement in a generate block may not
target parameters in other instantiations of the same
source generate block. A specific application of this is
that a defparam within a generate loop body may only target
parameters of instances within the current instantiation of
the generate loop body. For example ....

Even if you don't like the overall wording, please modify
the word "affect" to "target" since "affect" could be read
as permitting a defparam that does change the value.
Obviously that isn't the intent.

Gord.


>
> So, I would suggest adding the following note to the rule:
>
> Note: Since each instance of a generate block is a separate generate scope,
> this rule implies that a defparam statement in a generate block may not
> affect parameters under other instances of the same generate block. For
> example...
>
> <include loop genreate example>
>
> -Jason


From: Gordon Vreugdenhil <gvreugde@comcast.net>
To:
Cc: Jason Woolf <jasonw@cadence.com>, etf-bugs@boyd.com
Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted defparam
usage
Date: Wed, 05 May 2004 20:44:55 -0700

Gordon Vreugdenhil wrote:
> Jason, I like the intent of the note, but might suggest slightly
> different wording. Perhaps something along the lines of the
> following:
>
> Note: Each instantiation of a generate block is considered
> to be a separate generate scope. Thus, this rule implies
> that a defparam statement in a generate block may not
> target parameters in other instantiations of the same
> source generate block. A specific application of this is
> that a defparam within a generate loop body may only target
> parameters of instances within the current instantiation of
> the generate loop body. For example ....
>
> Even if you don't like the overall wording, please modify
> the word "affect" to "target" since "affect" could be read
> as permitting a defparam that does change the value.
^^^^^^^^^^^
Please read "does NOT change".

Sigh.

Type. Stop. Read. Read again. Then post.

Sigh.

Gord.


> Obviously that isn't the intent.
>
> Gord.
>
>
>>
>> So, I would suggest adding the following note to the rule:
>>
>> Note: Since each instance of a generate block is a separate
>> generate scope,
>> this rule implies that a defparam statement in a generate block may
>> not
>> affect parameters under other instances of the same generate
>> block. For
>> example...
>>
>> <include loop genreate example>
>>
>> -Jason
>
>
>
>



From: Jason Woolf <jasonw@cadence.com>
To: gvreugde@comcast.net
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted defparam usage
Date: Tue, 11 May 2004 16:36:17 -0400 (EDT)

Gord,

Combining your approach and mine, I get the following wording:

Note: Each instantiation of a generate block is considered
to be a separate generate scope. Therefore this rule implies
that a defparam statement in a generate block may not target
a parameter in another instantiation of the same generate block,
even when the other instantiation is created by the same loop
generate construct. For example...

Have I captured your intent in a slightly more compact form?
Shalom is the ultimate arbiter, since he's in control of the
official document.

-Jason


> Date: Wed, 05 May 2004 20:33:41 -0700
> From: Gordon Vreugdenhil <gvreugde@comcast.net>
> To: Jason Woolf <jasonw@cadence.com>
> CC: etf-bugs@boyd.com
> Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted
defparam usage
> X-pstn-settings: 3 (1.0000:2.0000) r p m C
> X-pstn-addresses: from <gvreugde@comcast.net> [23/2]
>
> Jason, I like the intent of the note, but might suggest slightly
> different wording. Perhaps something along the lines of the
> following:
>
> Note: Each instantiation of a generate block is considered
> to be a separate generate scope. Thus, this rule implies
> that a defparam statement in a generate block may not
> target parameters in other instantiations of the same
> source generate block. A specific application of this is
> that a defparam within a generate loop body may only target
> parameters of instances within the current instantiation of
> the generate loop body. For example ....
>
> Even if you don't like the overall wording, please modify
> the word "affect" to "target" since "affect" could be read
> as permitting a defparam that does change the value.
> Obviously that isn't the intent.
>
> Gord.
>
>
> >
> > So, I would suggest adding the following note to the rule:
> >
> > Note: Since each instance of a generate block is a separate generate
scope,
> > this rule implies that a defparam statement in a generate block may not
> > affect parameters under other instances of the same generate block. For
> > example...
> >
> > <include loop genreate example>
> >
> > -Jason
>
>

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: Jason Woolf <jasonw@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted defparam
usage
Date: Wed, 12 May 2004 13:07:06 +0300

I have no problem with any of these formulations.
Should I insert it into the proposal for generates (#113) or should we leave it separate?

Shalom


Jason Woolf wrote:

> Gord,
>
> Combining your approach and mine, I get the following wording:
>
> Note: Each instantiation of a generate block is considered
> to be a separate generate scope. Therefore this rule implies
> that a defparam statement in a generate block may not target
> a parameter in another instantiation of the same generate block,
> even when the other instantiation is created by the same loop
> generate construct. For example...
>
> Have I captured your intent in a slightly more compact form?
> Shalom is the ultimate arbiter, since he's in control of the
> official document.

From: Gordon Vreugdenhil <gvreugde@comcast.net>
To: Jason Woolf <jasonw@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/17: 12.1.3 is not clear enough about permitted defparam
usage
Date: Wed, 12 May 2004 18:09:20 -0700

Jason Woolf wrote:
> Gord,
>
> Combining your approach and mine, I get the following wording:
>
> Note: Each instantiation of a generate block is considered
> to be a separate generate scope. Therefore this rule implies
> that a defparam statement in a generate block may not target
> a parameter in another instantiation of the same generate block,
> even when the other instantiation is created by the same loop
> generate construct. For example...
>
> Have I captured your intent in a slightly more compact form?
> Shalom is the ultimate arbiter, since he's in control of the
> official document.


Yes, that is great.

Gord.




Fix replaced by Shalom.Bresticker@freescale.com on Thu Jul 8 07:24:17 2004

The following proposal was worked out by Jason and Gord,
only slightly edited by Shalom.

12.1.3 was deleted by the resolution of issue #113.

That leaves the following discussion in para. 1 of 12.2.1:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. However, a defparam
statement in a hierarchy under a generate scope or array of
instances shall not change a parameter value outside that
hierarchy. See 12.5 for hierarchical names."

(The xref is to 12.4 in 2001/D3, but issue #113 bumps 12.4
to 12.5 instead.)


This proposal is to change para. 1 of 12.2.1 to:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. See 12.4 for
hierarchical names.

However, a defparam statement in a hierarchy under a
generate scope (see 12.4) or array of instances shall not
change a parameter value outside that hierarchy.

Note: Each instantiation of a generate block is considered
to be a separate generate scope. Therefore this rule
implies that a defparam statement in a generate block may
not target a parameter in another instantiation of the same
generate block, even when the other instantiation is created
by the same loop generate construct. For example, the
following code is not allowed:

genvar i;

generate
for(i=0; i < 8; i = i+1) begin : somename
flop my_flop(in[i], in1[i], out1[i]);
defparam somename[i+1].my_flop.xyz = i ;
end
endgenerate

Similarly, a defparam statement in one instance of an array
of instances may not target a parameter in another instance
of the array.



Fix replaced by Shalom.Bresticker@motorola.com on Mon Jul 26 05:35:11 2004
The following proposal was worked out by Jason and Gord,
only slightly edited by Shalom.

12.1.3 was deleted by the resolution of issue #113.

That leaves the following discussion in para. 1 of 12.2.1:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. However, a defparam
statement in a hierarchy under a generate scope or array of
instances shall not change a parameter value outside that
hierarchy. See 12.5 for hierarchical names."

(The xref is to 12.4 in 2001/D3, but issue #113 bumps 12.4
to 12.5 instead.)


This proposal is to change para. 1 of 12.2.1 to:

"Using the defparam statement, parameter values can be
changed in any module instance throughout the design using
the hierarchical name of the parameter. See 12.5 for
hierarchical names.

However, a defparam statement in a hierarchy in or under a
generate block instance (see 12.4) or an array of instances
shall not change a parameter value outside that hierarchy.

Note: Each instantiation of a generate block is considered
to be a separate hierarchy scope. Therefore this rule
implies that a defparam statement in a generate block may
not target a parameter in another instantiation of the same
generate block, even when the other instantiation is created
by the same loop generate construct. For example, the
following code is not allowed:

genvar i;

generate
for(i=0; i < 8; i = i+1) begin : somename
flop my_flop(in[i], in1[i], out1[i]);
defparam somename[i+1].my_flop.xyz = i ;
end
endgenerate

Similarly, a defparam statement in one instance of an array
of instances may not target a parameter in another instance
of the array.


Unformatted


Hosted by Boyd Technology