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 Thu Oct 28 17:10:56 2004