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

From: Jason Woolf (jasonw@cadence.com)
Date: Wed May 05 2004 - 08:50:00 PDT

  • Next message: sharp@cadence.com: "enhancement/580: Add some system functions for use in constant expressions"

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

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

    This archive was generated by hypermail 2.1.4 : Wed May 05 2004 - 08:50:12 PDT and
    sponsored by Boyd Technology, Inc.