RE: Minutes of BTF meeting, May 3, 2004

From: Brophy, Dennis (dennisb@model.com)
Date: Sun May 16 2004 - 19:07:12 PDT

  • Next message: Stefen Boyd: "Re: 5/13 Datatypes Meeting Minutes"

    Config is already approved for use with an unconstrained scope in Verilog-2001. There is at least one implementation of such with users already placing config in Verilog text. You will find it hard to take away from users something they have already been given.

    The language in the minutes below expresses a purported hypothetical outcome of 'config' if a constraint to it is not imposed. I can understand this hypothesis if one is still stuck in Verilog-95 land, then every feature in Verilog-2001 has implications. I think everyone needs to get out of Verilog-95 land. In case anyone missed the news, Verilog-2001 was balloted and approved. There is no hypothetical issue here. You can try to go back and recreate time, but you will find it hard to regress behavior to simply your implementation and support issues.

    Users have voted. They are using config as defined in Verilog-2001 and dealing with 'config' as a keyword. I suggest everyone else do the same.

    Lastly, I find the argument specious and hallow to suggest the specification of 'config' is in the class of errata. This is NOT an editorial issue.

    There are even sillier arguments on the semicolons for config. I'm willing to live with Verilog-2001 as approved. The arguments about poorly written BNF, well written examples and excellent intentions only leaves one to conclude that to use the specification one must in order of significance obey the following: (1) be a mind reader, (2) follow non-normative examples or (3) use the specification to only have it challenged for adherence to the other two rules.

    Fix your semicolon issues and leave config alone.

    It almost makes me wonder if anyone ever read the Verilog-2001 LRM before and during its ballot.

    -Dennis

    -----Original Message-----
    From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On Behalf Of Steven Sharp
    Sent: Tuesday, May 04, 2004 3:16 PM
    To: btf@boyd.com
    Subject: Minutes of BTF meeting, May 3, 2004

    Minutes of BTF meeting on May 3, 2004, 10:40 AM PDT.

    In attendance:
            Kurt Baty
            Stefen Boyd
            Steven Dovich
            Tom Fitzpatrick
            Ronald Goodstein
            Francoise Martinolle
            Kathryn McKinley
            Karen Pieper
            Brad Pierce
            Dave Rich
            Steven Sharp
            Alec Stanculescu

    Steven calls the meeting to order at 1740 UTC.

    Kurt reminds that nominations are open for VSG officer positions, as described in http://boydtechinc.com/btf/archive/btf_2004/2197.html.

    The minutes of the April 19, 2004 meeting, available at http://boydtechinc.com/btf/archive/btf_2004/2183.html,
    are reviewed. Kurt moves to accept. Dave seconds.
    No opposed. Stefen abstains. Tom abstains. Minutes approved.

    Steve Dovich reports on the IP Encryption subgroup. It has had one meeting so far, on April 21, 2004, as announced in http://boydtechinc.com/btf/archive/btf_2004/2182.html.
    Interest level is good. Its next meeting will be May 12, 2004 at 1500 UTC.

    Steven reports that the prioritization group had a meeting and determined an initial list of high priority items as noted in http://boydtechinc.com/btf/archive/btf_2004/2195.html.

    Issue 350 (http://www.boyd.com/1364_btf/report/full_pr/350.html).
    Steven suggests that configs only be allowed in library mapping files, not in source code, because of keyword conflicts. 'config', for example, would no longer be a keyword in Verilog text, but only in library mapping files. There was consensus for this suggestion.
    Steven has the action items to make a formal proposal and to discuss editorial mechanics with Shalom. Mac suggests that VSG issue an opinion soon. Steven has action item to make such a motion at VSG once proposal is ready. Should this change be done by deprecation or removal? Consensus is to remove as an erratum, but with an explicit informative note about the history.

    Issue 298 (http://www.boyd.com/1364_btf/report/full_pr/298.html),
    specifying a minimum field width for integer formats in the $display family. Why not just do everything C does in printf()? May not be able to entirely, because %0d already has a different meaning in Verilog. Some C format possibilities don't even make sense for Verilog. Only a subset is needed. Steven asks for vendor experience and user input. Consensus is that it's a good thing, and when possible, should try to make it like C, but many details still need to be worked out. Stefen advises to start small. Steven has action item to make a proposal.

    Issue 354 (http://www.boyd.com/1364_btf/report/full_pr/354.html),
    consensus to add $feof() function. Steven has action item to make proposal.

    Issues 387/390 (http://www.boyd.com/1364_btf/report/full_pr/387
    and http://www.boyd.com/1364_btf/report/full_pr/390.html). Kurt is strongly opposed to using $ identifiers for mathematical functions.
    He wants at least a built-in math package in which, say, ln would call $ln, to import the names into the namespace. A one-layer alias.
    The motivation is to dodge the $ identifiers, but some feel it's not really that important, or that packages are not necessary. Kurt wants to postpone issue 390 until the discussion of packages. Mac and Steven point out that the user could just `define ln $ln. Kurt thinks this issue should be tied into 293 about variable-width floating-point, and strongly feels that nothing should change for Verilog-AMS users regarding the use of these mathematical functions.
    No consensus reached. But there was consensus that some system functions should be allowed in constant expressions. Steven has action item to spin off a new enhancement issue about that.

    Meeting adjourned at 1900 UTC.

    Next meeting is on May 17, 2004, 10:40 AM PDT

    This archive was generated by hypermail 2.1.4 : Sun May 16 2004 - 18:46:57 PDT and
    sponsored by Boyd Technology, Inc.