Re: Orthogonal Data Types - Rough Proposals

From: Shalom.Bresticker@motorola.com
Date: Mon Apr 05 2004 - 04:44:25 PDT

  • Next message: Clifford E. Cummings: "Re: Orthogonal Data Types - Rough Proposals"

    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.

    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.

    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?

    Shalom

    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. 

    -- 
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

    This archive was generated by hypermail 2.1.4 : Mon Apr 05 2004 - 04:29:54 PDT and
    sponsored by Boyd Technology, Inc.