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

I would like to suggest the use of wireu in place
of wone. Since it is so close to the existing wire keyword it would
naturally be thought of as a special type of wire. The 'u' can be
thought of as representing several different characteristics of this
net type.

   wireu

     unidirectional
     unidriver
     unresolved

You can take your pick of these interpretations based on your
favorite way of thinking about this net type. The only problem I see with
wireu is that it may cause people to think it means "unsigned wire".

Another possiblity is

   wired

where the 'd' stands for one driver.

The attractive thing about wone is that it has the same number of letters
as wire.

Neil

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

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Member of Technical Staff                         Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------