Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters

From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Mon Nov 08 2004 - 12:30:00 PST

  • Next message: Shalom.Bresticker@freescale.com: "Re: Meeting next Monday"

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

    From: "Brad Pierce" <Brad.Pierce@synopsys.com>
    To: <etf-bugs@boyd.com>
    Cc:
    Subject: Re: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
    Date: Mon, 8 Nov 2004 12:35:31 -0800

     Shalom,
     
     You might want to look over the BNF changes the SV-BC recently approved for
     
        http://www.eda.org/svdb/bug_view_page.php?bug_id=0000034
     
     Maybe they should be extended to handle specparams?
     
     -- Brad
     
     -----Original Message-----
     From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of
     Shalom.Bresticker@freescale.com
     Sent: Monday, November 08, 2004 12:10 PM
     To: etf-bugs@boyd.com
     Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
     
     
     The following reply was made to PR errata/483; it has been noted by GNATS.
     
     From: Shalom.Bresticker@freescale.com
     To: Stuart Sutherland <stuart@sutherland-hdl.com>
     Cc: etf-bugs@boyd.com
     Subject: RE: errata/483: PROPOSAL - 4.2: Bit/part-selects of parameters
     Date: Mon, 8 Nov 2004 22:18:37 +0200 (IST)
     
      Stu,
     
      Thanks for the comments.
     
      On 1: specparams and localparams are not excluded. The text I added
     includes
      specparams, I added the BNF today. See item 6 in the changes.
      Throughout the LRM, the term 'parameters'
      is used for all types of parameters, except where 3.11 specifically notes
      that there are differences. Though I am sure you can find a few exceptions
      to that rule. If you want more explicit text about localparams, we can add
     it.
     
      On 2: Without taking a position, that is a completely separate issue which
     is
      out of the scope of 483. All I did was to take a note which was intended to
     be
      normative and has always been treated as normative and make it explicitly
      normative. Changing the content of the note is a new issue.
     
      With respect to the actual suggestion, I believe that SV already makes that
      change. Note that the note talks about integer variables, not integer
     types.
      An integer constant, for example, is a different story. I think it would be
      necessary to find all the places in the LRM which talk about 32 bit sizes
     in
      order to keep them consistent.
     
      Shalom
     
     
      On Mon, 8 Nov 2004, Stuart Sutherland wrote:
     
    > I have two questions:
    >
    > First is a general question. Many of the proposed changes involving
     adding
    > bit- and part-selects of parameters. Why were specparam and localparam
    > constants excluded from these changes?
    >
    > Second is a question that I'd like to hear the thoughts of other 1364 WG
    > members about. The change is to make the informative note that the size
     of
    > an integer type shall be "at least 32 bits" into normative text. Rather
    > than make this ambiguous size normative, perhaps this is the time to
     remove
    > the ambiguity and simply state that an integer type SHALL BE 32 bits
     wide.
    > I am well aware of why we made this ambiguous to begin with, which was to
    > copy the behavior of C and to possibly allow software tools to optimize
    > integer types for different operating systems. However, Verilog is a
    > hardware modeling language, whereas C is a programming language.
     Hardware
    > vector widths do not arbitrarily change sizes because the operating
     system
    > changed. Further, I do not think it would be desirable for the results
     of
    > synthesizing a Verilog model to result in very different designs simply
    > because I re-synthesized on a different platform. Since Verilog is
     modeling
    > hardware, the integer type should have a fixed, and consistent size, like
    > hardware. One could argue that the integer type should only be used in
    > testbenches and other software-like contexts, but there is nothing in the
    > language that prevents using integer types in synthesizable hardware
     models,
    > and I suspect there are many existing hardware models that use integer
    > types. In fact, even testbench constructs in Verilog, such as $fopen,
    > expect an integer type to be 32 bits. Also worth considering is what do
    > synthesis compilers do with the integer type? The 1364.1 standard says
     the
    > integer type is synthesizable, but does not specify a size. However, in
    > Section 7.10.3 of 1364.1, it specifically states "A port of an integer
     type
    > shall be treated as a 32 bit signed type,".
    >
    > In short, my second question is: Can we make the size of the integer type
     a
    > fixed 32 bits, instead of changing the informative note that it "at least
     32
    > bits" into normative text?
    >
    > Stu
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > Stuart Sutherland
    > stuart@sutherland-hdl.com
    > +1-503-692-0898
     
      --
      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
     
     

    This archive was generated by hypermail 2.1.4 : Mon Nov 08 2004 - 12:30:09 PST and
    sponsored by Boyd Technology, Inc.