From: Gordon Vreugdenhil (gvreugde@comcast.net)
Date: Wed May 05 2004 - 20:30:00 PDT
The following reply was made to PR errata/17; it has been noted by GNATS.
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
>
>
>
>
This archive was generated by hypermail 2.1.4
: Wed May 05 2004 - 20:30:04 PDT
and
sponsored by Boyd Technology, Inc.