[Fwd: RE: [sv-bc] DataTypes: Revised BNF changes]

From: Neil Korpusik (Neil.Korpusik@Sun.COM)
Date: Thu Nov 11 2004 - 14:59:55 PST

  • Next message: Kathy McKinley: "[sv-bc] DataTypes: LRM changes for internal review"

    Hi Kathy,

    Attached is what appears to be the latest that I have receieved.

    Neil

    Kathy McKinley wrote:
    > I seem to have misfiled Steven's grammar changes. I am ready to send
    > out the LRM changes when I get this one missing piece. Can someone
    > forward it to me again?

    -------- Original Message --------
    Subject: RE: [sv-bc] DataTypes: Revised BNF changes
    Date: Wed, 10 Nov 2004 18:59:54 -0500 (EST)
    From: Steven Sharp <sharp@cadence.com>
    Reply-To: Steven Sharp <sharp@cadence.com>
    To: btf-dtype@boyd.com, sv-bc@eda.org

    Here is a revised version of the BNF changes for tomorrow.

    Steven Sharp
    sharp@cadence.com

    -- 
    ---------------------------------------------------------------------
    Neil Korpusik                                     Tel: 408-720-4852
    Member of Technical Staff                         Fax: 408-720-4850
    Frontend Technologies - ASICs & Processors (FTAP)
    Sun Microsystems
    email: neil.korpusik@sun.com
    ---------------------------------------------------------------------
    

    Changes to BNF to allow data types on nets:

    Commentary:

    The proposed BNF syntactically allows a lot of data types that we won't
    necessarily allow for nets. They will be eliminated by a semantic rule
    about what types are supported for nets. Such a semantic rule will be
    needed anyway, since a typedef is syntactically legal but could represent
    a type not supported for nets. Trying to define a separate net_data_type
    production for a syntactic restriction would be a lot messier. Brad
    Pierce has said he agrees with this general approach.

    Brad also suggested the approach in the port BNF of using simpler grammar
    with a footnote. In the LRM, it would be a numbered footnote, like the
    existing footnotes. Brad also suggested changing the name of port_type
    to net_port_type, which can be done as a separate change.

    LRM Changes:

    In Annex A.2.1.3, CHANGE

     "net_declaration ::=
         net_type_or_trireg [drive_strength|charge_strength] [vectored|scalared]
           [signing] {packed_dimensions} [delay3] list_of_net_decl_assignments;"

    TO

     "net_declaration ::=
         net_type_or_trireg [drive_strength|charge_strength] [vectored|scalared]
           data_type_or_implicit [delay3] list_of_net_decl_assignments;"

    Also add the preceding BNF excerpt to the appropriate syntax box in the
    appropriate section.

    In Syntax 18-4 and Annex A.2.2.1, CHANGE

     "port_type ::= [net_type_or_trireg] [signing] {packed_dimension}"

    TO

     "port_type* ::= [net_type_or_trireg] [signing] {packed_dimension} |
                     [net_type_or_trireg] data_type

      *When a port_type contains a data_type, it shall only be legal to omit
       the explicit net_type_or_trireg when declaring an inout port."



    This archive was generated by hypermail 2.1.4 : Thu Nov 11 2004 - 14:48:07 PST and
    sponsored by Boyd Technology, Inc.