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

From: Stuart Sutherland (stuart@sutherland-hdl.com)
Date: Fri Oct 29 2004 - 09:09:18 PDT

  • Next message: Neil Korpusik: "Re: [sv-bc] DataTypes: The wone net type"

    Steven,

    All of your reasoning is excellent and well stated. I am now satisfied that
    all that is needed is a single-driver version of wire. I'm still not sold
    on the keyword "wone". I would like to see some brainstorming on alternate
    keyword suggestions.

    Stu
    ~~~~~~~~~~~~~~~~~~~~~~~~~
    Stuart Sutherland
    stuart@sutherland-hdl.com
    +1-503-692-0898
      

    > -----Original Message-----
    > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
    > Behalf Of Steven Sharp
    > Sent: Thursday, October 28, 2004 5:11 PM
    > To: btf-dtype@boyd.com; sv-bc@eda.org
    > Subject: 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 : Fri Oct 29 2004 - 08:58:25 PDT and
    sponsored by Boyd Technology, Inc.