RE: [sv-bc] DataTypes: The wone net type

From: Steven Sharp (sharp@cadence.com)
Date: Thu Oct 28 2004 - 17:10:50 PDT

  • Next message: Steven Sharp: "RE: [sv-bc] DataTypes: The wone net type"

    Stu asked about single-driver versions of all the existing net types, and
    essentially suggested using a mechanism for declaring a single-driver net
    that would be orthogonal to the net type. I am in favor of orthogonality
    when the features are actually independent. However, I believe that a
    closer examination of the net types reveals that they are not orthogonal
    with a single-driver restriction.

    The net types essentially specify the resolution behavior for the net,
    indicating the resulting value when driven by zero or more drivers. The
    "wone" type also specifies resolution behavior, namely that there must
    not be any need for resolution. An alternate name proposed for the type
    was "wun", standing for "wire unresolved". And if we look at each of
    the existing net types, we find that a single-driver version of that
    net type is equivalent to "wone" or makes little sense.

    The "wire" net type restricted to a single driver is equivalent to "wone".
    The "tri" net type is a synonym for "wire", so it is also equivalent to
    "wone" (and "tri" supposedly indicates an intention to have multiple
    drivers anyway). The "wand" and "wor" are only different from "wire"
    in their resolution of multiple drivers. A single-driver version would
    be equivalent to "wone". The "triand" and "trior" net types are synonyms
    for "wand" and "wor".

    The other net types essentially differ from "wire" in starting out with
    an extra implicit driver on them (a pullup or pulldown for "tri1" or "tri0",
    a capacitor for "trireg", or the power supply for "supply1" or "supply0").
    In a sense, they violate the single-driver rule as soon as they are
    connected. If we only consider single explicit drivers, they still have
    little use.

    A pullup or pulldown is generally used to prevent a net from floating
    (having a z value) when all of its drivers are tristated. But on a net
    intended for a single driver, that driver generally won't be able to
    tristate. If the driver never goes to z, then there is no difference
    between "tri1" or "tri0", and "wire". With a single non-tristate driver,
    they are equivalent to "wone".

    A "trireg" is similarly only different if its driver goes to z. There
    may be some uses for "triregs" that only have a single driver, such as
    in low-level modeling of DRAMs, so this case is not as clear as the
    pullup/pulldown case. However, I suspect that anyone modeling at that
    low level won't be following single-driver design rules. For example,
    DRAMs modeled at that level will have lots of multiple-driven nets.
    With a single non-tristate driver, they are equivalent to "wone".

    For "supply1" or "supply0", it doesn't make much sense to have a single-
    driver rule. It doesn't make sense to have any explicit drivers on them
    at all. If you wanted to enforce a design rule for them, it would be
    that they have zero drivers (except perhaps bidirectional tranifs).
    There is no point in having a single-driver version of these.

    If anyone with more extensive hardware experience sees any errors in
    my arguments, I welcome a correction. If there are real reasons for
    needing single-driver versions of other net types, we should consider
    them.

    The suggestion of using an attribute was considered as an alternative.
    Any tool would be free to implement an attribute that caused such a
    check to be performed. That would be a very appropriate use for an
    attribute. It wouldn't require adding anything official to the language,
    and other tools would quietly ignore it. If we were considering this
    as just a nice extra feature for our tools, that is probably what we
    would have done.

    However, the goal was to extend the checking that SystemVerilog does
    for variables, to cover nets. That checking is built into the language,
    and is not optional. To match it requires something for nets that is
    built into the language, and is not optional. Also, it needed to be
    specified to cross port boundaries. The existing rules for port collapsing
    and net domination are a natural match for this. They are based on net
    types, and can be extended easily with a new net type, to get the desired
    behavior across the hierarchy. Using a new net type for this works out
    very nicely.

    Steven Sharp
    sharp@cadence.com

    This archive was generated by hypermail 2.1.4 : Thu Oct 28 2004 - 16:59:59 PDT and
    sponsored by Boyd Technology, Inc.