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
>
>
>
Received on Fri Oct 29 09:09:20 2004