Re: enhancement/17: 12.1.3 is not clear enough about permitted defparam usage

From: Jason Woolf (jasonw@cadence.com)
Date: Tue May 11 2004 - 13:20:00 PDT

  • Next message: Shalom Bresticker: "Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source"

    The following reply was made to PR errata/17; it has been noted by GNATS.

    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
    >
    >
     

    This archive was generated by hypermail 2.1.4 : Tue May 11 2004 - 13:20:09 PDT and
    sponsored by Boyd Technology, Inc.