SystemVerilog: "logic" or "ulogic?"

Discussion in 'VHDL' started by Cliff Cummings, Sep 16, 2003.

  1. Hi, All -

    Request for user feedback.

    Two data types have been added to the SystemVerilog language: "logic"
    and "bit."

    The new types are actually unresolved types (similar to the VHDL
    std_ulogic_type) and are called "logic" (4-state type) and "bit"
    (2-state type).

    I believe we would be doing the Verilog and VHDL communities a favor
    by at least choosing the more VHDL-like keywords: ulogic & ubit.

    I am also guessing that "ulogic" will kill fewer existing designs than
    "logic" (same argument for "ubit" vs. "bit"). I also like the
    VHDL-like "u" to indicate "unresolved."

    Unfortunately, the Accellera SystemVerilog committees are mostly
    staffed by EDA vendors who do not want to change the keywords as they
    are currently defined in the SystemVerilog 3.0 & 3.1 standards.

    I have been given the chance to solicit user input one more time
    before this issue is dismissed.

    If you have an opinion one way or the other, please send an email
    message to the:

    SystemVerilog Design Committee ( )
    with the Subject: logic -vs- ulogic - user input

    And voice your opinion that either "logic" and "bit" should keep the
    current keywords, or
    "logic" and "bit" should be changed to the more VHDL-compatible names
    of "ulogic" and "ubit."

    I really would like more user feedback before we cast this in stone in

    Thanks in advance to anyone who responds.

    Regards - Cliff Cummings
    Cliff Cummings, Sep 16, 2003
    1. Advertisements

  2. But in VHDL type bit is an unresolved type!
    So only need a change from 'logic' in 'ulogic' is sufficient from a VHDL
    point of view.

    Egbert Molenkamp
    Egbert Molenkamp, Sep 17, 2003
    1. Advertisements

  3. I agree.

    The larger problem is that SystemVerilog "types"
    cannot be applied to wires (signals).

    -- Mike Treseler
    Mike Treseler, Sep 17, 2003
  4. (Posted to both comp.lang.vhdl and sv-bc mailing list)

    Hang on a minute there! _logic_ and _bit_ in SV are not in any
    real sense "unresolved" types - they're variables! Just because
    they can be used in a rather similar way in hardware designs
    doesn't make them the same.

    I disagree. Any attempt to align SV type names with VHDL could
    sow the seeds of massive confusion. SV divides its data types
    along an entirely different axis than does VHDL.

    SV introduces the ability to use a variable as the target of
    a continuous assignment (explicitly with _assign_ or implicitly
    across a port). When used in this way, variables of any type
    behave somewhat like VHDL unresolved signals. When NOT used
    in this way, however, SV variables have the semantics of
    traditional Verilog variables, which is entirely different.
    Thus, SV variables gain or lose "VHDL unresolved" status
    depending on how they're used. This is why I would be very
    unhappy to see any attempt to make them into ersatz VHDL
    types by choice of name.

    Once again I disagree. Compilers will have no trouble identifying
    abuse of a keyword in existing designs. As a user switching from
    Verilog to SV I would be prepared to accept, as a price of change,
    the kind of "brokenness" that is easily and explicitly identified
    by the first pass of a compiler, and won't compile at all. It's
    far better than silent brokenness that compiles happily but delivers
    silly results; and it's easy to fix.

    There are so many new keywords in SV anyway, that this issue is
    down in the noise. I'm sure someone will come up with a preprocessor
    that will hunt down any SV keywords in existing Verilog designs
    and flag them, so that they can be decorated somehow to avoid clashes.
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

    Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
    Tel: +44 (0)1425 471223 mail:
    Fax: +44 (0)1425 471573 Web:

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
    Jonathan Bromley, Sep 17, 2003
  5. Bummer! You're right!

    I still like the idea of having ulogic and ubit to be new unresolved
    types in SystemVerilog (I think it would break fewer existing Verilog
    designs), but if you would prefer ulogic and bit, please email your
    preference to:

    SystemVerilog Design Committee ( )
    with the Subject: logic -vs- ulogic - user input

    Again, I would like more user input passed to the Accellera

    Side-note: My limited VHDL experience has been that most VHDL
    designers do not use the bit-type. Is this true?

    Regards - Cliff Cummings
    Cliff Cummings, Sep 17, 2003
  6. I think so.
    std_logic_vector and unsigned
    are much more common.

    -- Mike Treseler
    Mike Treseler, Sep 17, 2003
  7. Hi, Jonathan -

    Thanks for the feedback. All feedback pro and con is welcome.

    As you note later, we now have the ability to make single continuous
    or instance-driven assignments to variables, including logic and bit.

    This means that if you want to design with all unresolved signals and
    have the compiler check to see if you have made a mistake, the logic
    (4-state) and bit (2-state) types can be used as your near-universal
    data types. This was very important to Intel, as they discussed in
    their DAC 2003 presentation.

    I think you also allude to the fact that SV does not have equivalent
    resolved types (one reason for objecting to tying SV and VHDL data
    types together by comparison?). This is true. I would like to have
    equivalent 4-state and 2-state resolved types in SV, but unlike VHDL,
    I would like to prohibit continuous (VHDL-concurrent signal
    assignments) and procedural (VHDL-process assignments) assignments to
    the same resolved variable. If we permitted procedural assignments to
    wires (I know - I have been out-voted on this many times!) we would
    have the 4-state resolved type, and would just be missing the 2-state
    resolved type.

    Intel engineers have suggested that it would be useful to add the
    capability to define 2-state Z and X conversions separately, so that
    2-state simulations could be done with ZX=00, ZX=01, ZX=10 and ZX=11.
    This would allow for some very good 2-state testing. I like the idea.

    It would be so useful to do a resolved data type design (one that uses
    tri-states) and quickly switch the typdefs to unresolved types to find
    all of the tri-state busses and to do a quick lint-check to find any
    unintended resolved assignments.
    I was trying to realign the axes to be backward compatible with
    existing Verilog designs while removing the all-too-confusing
    net-vs-variable issues in Verilog.
    Compared to logic and bit, I think most of the new SV keywords are not
    going to be nearly as noisey!

    Thanks for weighing in on this debate. I am interested in more user
    Regards - Cliff
    Cliff Cummings, Sep 18, 2003
  8. Cliff Cummings

    cc0139808 Guest

    My 2c: if you use bit in a real chip, you will not propagate 'X', hence
    you might have hard to debug mismatches between RTL and gates.
    Yes, I know many people say "Silicon has only '0' or '1', does not have
    'X'!", but you do your sign-off based on simulations, not on silicon.

    Dan Ciobanu
    cc0139808, Sep 20, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.