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

If the longer term intention is to add resolution functions for
user-defined types, then all you need to do is use a net/driver type
that has no defined resolution function and it will have the same
effect. I would therefore view "wone" as something that is undesirable
since it will become redundant later.

 From an MS standpoint "wone" is rather pointless since you can have
multiple drivers on a net from parasitics etc. which need to be there
but are not part of the functional description. If the resolution
function for a net can be added optionally by the user, it will be
easier to get the right simulation behavior for both functional and
post-synthesis/layout simulations (since the datatype(s) and resolution
function(s) would likely be in a common header, whereas "wone" is an
embedded keyword).

Kev.

Stuart Sutherland wrote:

>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
>>
>>
>>
>>
>>
>
>
>
>

-- 
Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126