SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to champion the proposal

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Jan 27 2003 - 15:37:39 PST

  • Next message: etf@boyd.com: "errata/77: PROPOSAL - Table 30: Last LHS line is not clear"

    Subject: SV-EC Proposal: Implicit Universal Data Type - Cliff Cummings to
    champion the proposal

    Hi, All -

    At the SV-BC meeting, the users were sorely under-represented. I am asking
    for all users on these groups to offer email support for the following
    proposal.

    I tried to get the logic data type modified to become the universal data
    type that designers want, but at the all-day BC meeting last week, I was
    shot down and crashed and burned (lots of smoke and deep despair!)

    Per the SystemVerilog-BC minutes sent by Johny on Jan 25, 2003:

    There will be new var or varports with procedural last-assignment-wins
    behavior at a higher level of hierarchy - this was good.

    I think we passed Dave Riches proposal to prohibit multiple output or inout
    connections to a logic type at a higher level of hierarchy (this previously
    allowed last-assignment-wins behavior from two lower level modules that
    made procedural assignments to a logic variable) but I'm not sure which
    part of the minutes show this or if this was even actually voted.

    My proposal to allow multiple drivers to logic types and make logic the
    default data type in SystemVerilog was crushed (logic will not be the
    universal data type and must always be declared).

    The minutes show that a straw-poll vote was made to remove logic as a
    SystemVerilog data type. Other email discussion suggests that this was
    withdrawn but I do not see that in the minutes.

    And finally, I was given this action item:

    Cliff's implicit datatype can now be implemented via a new
    'default_nettype because local decisions can be made. However,
    we have not said that we would allow implicit declaration of
    procedurally defined variables. If Cliff wants to continue, he
    can make a proposal to EC.

    SystemVerilog-EC Proposal: The Universal Data Type

    After thinking this over and getting feedback from various designers on the
    committees, I think we have come full circle. I think we may have support
    for the universal data type that I first proposed back in the 1997-1998
    time-frame and detailed in an HDLCon 2000 paper (attached).

    I propose that "wire" become our universal data type.

    Inside of a module, if assignments are made to a wire type from a
    procedural block, the wire is treated like a reg with no strength
    information and the release command will treat the wire-variable like a reg
    (no immediate update - next updated by procedural assignment).

    Inside of a module, if assignments are made to a wire type from primitives,
    instances or continuous assignments (collectively referred to as driver
    assignments), the wire is treated like a wire with optional strength
    information and the release command will treat the wire-assignment like a
    wire (immediate resumption of driven value upon release). And of course,
    resolution of multiple drivers occurs.

    Jay Lawrence (and previously Peter Flake) had suggested that reg be the
    type that permits both driver and procedural assignments, but I strongly
    oppose that idea just because reg is already a misunderstood type name. Now
    the resolved default data type used in interfaces would be called reg (very
    confusing). I would like reg to become obsolete and largely forgotten in
    the future (except for backward compatibility).

    Jay Lawrence had rejected the notion of an undeclared type "morphing" into
    a reg or net type based on use, but that is exactly what happens with VHDL
    std_logic type. In VHDL you can make concurrent signal assignments or
    process assignments but not both, and you get resolution from concurrent
    signal assignments. This is what I want - except in true Verilog fashion, I
    don't want to have to declare these universal wires except for internal
    wire-buses.

    We already know that Verilog regs on output ports must be implicitly
    converted to a continuous assignment to drive a wire, so now it becomes a
    procedural wire that transforms into a continuous assignment wire hidden to
    the Verilog user.

    The nice thing about choosing a Verilog wire as the universal data type is
    that engineers already think of wires as connections, it is not a new
    keyword, and it is the default data type in Verilog so we don't have to
    create new rules for a default type that would not have to be declared.

    This way, we could also keep the logic type as the SystemVerilog unresolved
    type that requires declaration, which is what Matt Maidment of Intel
    wanted. I still think logic keyword should be changed to ulogic to more
    accurately reflect the unresolved nature and not confuse VHDL engineers
    that transition to SystemVerilog (same argument for bit/ubit).

    At the SV-BC meeting, the users were sorely under-represented. I am asking
    for all users on these groups to offer email support for this enhancement.

    Please - a vote of confidence for the universal default data type called wire!

    Attached is my HDLCon paper that gave greater detail on this proposal.

    Regards - Cliff Cummings



    ----------------------------------------------------
    Cliff Cummings - Sunburst Design, Inc.
    14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
    Phone: 503-641-8446 / FAX: 503-641-8486
    cliffc@sunburst-design.com / www.sunburst-design.com
    Expert Verilog, Synthesis and Verification Training

    This archive was generated by hypermail 2.1.4 : Mon Jan 27 2003 - 15:44:05 PST and
    sponsored by Boyd Technology, Inc.