Re: Orthogonal Data Types - Rough Proposals

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Apr 05 2004 - 06:53:06 PDT

  • Next message: Dave Rich: "2-state 4-state behaviour"

    Hi, Shalom, et al -

    Do I need to request to be added to the btf_dtype email reflector or am I
    already on it?

    Comments below.

    At 04:39 AM 4/5/2004, Shalom.Bresticker@motorola.com wrote:
    >Cliff,
    >
    >I believe you are again mixing between data kinds and data types,
    >which is one way of doing things, but it is different from the Cadence
    >proposal, which distinguishes between them. Our group has also
    >tentatively accepted this approach.

    It has been hard to find minutes from the group to know the discussion
    threads but I think I understand.

    >The data kind deals with resolution functions, how a kind can be
    >assigned a value, etc.
    >
    >The data type deals with the value set, e.g, 2-state vs. 4-state.

    Understood.

    >Resticting the discussion for the moment to data kinds, I understand
    >that SV extended regs to encompass most cases of wires, e.g., allowing a
    >reg to be written by a single continuous assignment.
    >
    >What it seems that you are proposing is the reverse direction as well,
    >allowing wires to be driven by procedural assignments in a single
    >process. This would make the overlap between wires and regs greater.
    >
    >Is that a correct understanding?

    This is correct.

    This means that for unresolved types, I could use 4-state logic and 2-state
    bit/bool for all declarations and the simulator "would do the right thing."

    This also means that for resolved types, I could use 4-state wire and
    2-state ??? for all declarations and the simulator "would do the right thing."

    I also have requested a 2-state data type with wire-resolution data kind
    (if I understand the distinctions correctly).

    >On Sun, 4 Apr 2004, Clifford E. Cummings wrote:
    >
    > > Hi, Kathy & team -
    > >
    > > SUBJECT:
    > > (1) We need orthogonal variable and net types
    > > (2) We need a 2-state resolved net type
    > >
    > > Thursdays are hard days for me to attend meetings. I am very frequently on
    > > the road during the latter half of many weeks, so I will have to
    > > participate by email as much as possible.
    > >
    > > I read Jay Lawrence's Data Types proposal some time back and generally
    > like
    > > it. I also read in one of the operating procedures minutes for the VSG(?)
    > > that orthogonality should play an important role when considering
    > enhancements.
    > >
    > > I believe Jay's proposal still lacked two important pieces of
    > orthogonality.
    > >
    > > (1) SystemVerilog now permits one or more assignments -OR- a single
    > > continuous (or driver - such as gate primitive or instance output)
    > > assignment to Verilog variables. The logic and bit types first added this
    > > capability and then it was extended to all variable types (I don't care if
    > > we call the bit type "bit" or "bool"). Now logic and reg are essentially
    > > the same data type (I do like "logic" better than "reg").
    > >
    > > I still wonder if we should replace "logic" with "rlogic" (resolved logic)
    > > and "ulogic" (unresolved logic) and similarly, "bool" with "ubool" and
    > "rbool."
    > >
    > > For orthogonal reasons, to still preserve backward compatibility with
    > > Verilog-2001 and to remove a very annoying rule of the Verilog language, I
    > > would like to orthogonally enhance Verilog wire types.
    > >
    > > reg - as defined by the SystemVerilog LRM (No change)
    > > · allows one or more procedural assignments
    > > · allows one driver assignment
    > > · syntax error to make both driver and procedural assignments to the
    > > same variable
    > >
    > > PROPOSED: wire
    > > · allows one or more resolved driver assignments (current Verilog
    > > behavior)
    > > · ADD - allow procedural assignments from a single procedural block
    > > to a wire type
    > > · syntax error to make both driver and procedural assignments to the
    > > same variable
    > >
    > > This proposal would enforce a good coding style (do not make
    > assignments to
    > > the same variable from multiple procedural blocks) and allow engineers to
    > > use "logic" and "bool" for 4-state and 2-state designs that require
    > > unresolved types and would allow engineers to use "wire" and "???" for
    > > 4-state and 2-state resolved types.
    > >
    > > This is more VHDL-like (something that VHDL does well) and removes the
    > > annoying requirement of changing a declaration any time an assignment is
    > > moved from a procedural block to a continuous assignment. (Every time I
    > > teach Verilog to VHDL-trained engineers, they complain about this
    > > requirement and I absolutely agree - I just taught another group of
    > > VHDL-trained engineers last week and the issue was again raised - VHDL
    > > engineers always ask me "what value is there in changing a declaration
    > just
    > > because an assignment moved from a procedural block to a continuous
    > > assignment?" I tell them there is no value, that it's just a silly rule of
    > > the Verilog language!)
    > >
    > > (2) For orthogonality reasons, we need a 2-state resolved net type.
    > > Yes, I really want a 2-state type that cannot go to X or Z. What
    > happens if
    > > I drive conflicting values onto the 2-state net? It goes to 0. What
    > happens
    > > if I drive HiZ onto a 2-state net? It goes to 0.
    > >
    > > As I have discussed this option with engineers, most would also like the
    > > ability to use some type of compiler directive to force the 2-state X to
    > > any of the following: 1, 0 or random. Similarly, engineers would like a
    > > compiler directive to force 2-state Z to any of the following: 1, 0 or
    > > random. I would be satisfied with a 2-state net going to 0 and consider
    > the
    > > other enhancements later.
    > >
    > > Higher-speed 2-state simulations would be one advantage. Additional
    > > debugging is also achieved when X's and Z's are changed to 2-state (see
    > > Bening & Foster - Principles of Verifiable RTL design for additional bugs
    > > that are detected when doing 2-state simulation).
    > >
    > > Through the use of SystemVerilog "logic" and "bit" data types, engineers
    > > have a very nice way to switch between 4-state and 2-state unresolved
    > > simulations. We do not have a similar capability using resolved data
    > types.
    > > This is an orthogonality issue.
    > >
    > > I will provide more details and examples as warranted. I will also
    > write up
    > > formal proposals if I see progress being made in this direction.
    > >
    > > Regards - Cliff
    > >
    > > ----------------------------------------------------
    > > 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, SystemVerilog, Synthesis and Verification Training
    > >
    > >
    >
    >--
    >Shalom Bresticker Shalom.Bresticker@motorola.com
    >Design & Reuse Methodology Tel: +972 9 9522268
    >Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
    >POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
    >
    >[x]Motorola General Business Information
    >[ ]Motorola Internal Use Only
    >[ ]Motorola Confidential Proprietary

    ----------------------------------------------------
    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, SystemVerilog, Synthesis and Verification Training

    This archive was generated by hypermail 2.1.4 : Mon Apr 05 2004 - 06:35:58 PDT and
    sponsored by Boyd Technology, Inc.