RE: [sv-bc] DataTypes: Plans for Dec. 1

> From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
>
> "wone" has been suggested as a keyword for a wire that is restricted to
> having a single source. It has not been voted on, even within the data
> types subcommittee, as far as I know. Personally, I have problems with
> "wone", which I assume is short "wire one driver". There are several other
> net net types: tri, wor, trior, wand, triand, tri0, tri1, supply0, supply1,
> and trireg. What are the contractions for a single driver version of these?
> Is it "tone", "wone", "toone", "tone0", "tone1", "sone0", "sone1" and
> "wonereg"? I HOPE NOT! I think there needs to be better way to specify a
> net that is restricted to a single source. Perhaps it could be an
> attribute, and perhaps it could be a keyword that could be paired with any
> of the net types.
>
> Something to discuss in an upcoming data types meeting.

One of the things that AMS adds is some "driver access" functions in particular
$driver_count, so you can do something like:

  assert($driver_count(some_net) == 1) ...

The AMS LRM is at http://www.eda.org/verilog-ams/htmlpages/public-docs/lrm/2.1/AMS-LRM-2-1.pdf
and the drivers access functions are in section 8.10.

The driver access functions are used to build D-to-A convertors in AMS, but can be
used in purely digital simulation to build behavioral models for bidirectional components
(like resistors and capacitors).

Kev.

>
> 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 Shalom.Bresticker@freescale.com
> > Sent: Wednesday, October 27, 2004 9:16 PM
> > To: Kathy McKinley
> > Cc: btf-dtype@boyd.com; sv-bc@eda.org
> > Subject: Re: [sv-bc] DataTypes: Plans for Dec. 1
> >
> > "wone" may have been proposed in 1364, but so far it has not
> > been approved there, as far as I know.
> >
> > Shalom
> >
> >
> > On Wed, 27 Oct 2004, Kathy McKinley wrote:
> >
> > > Hello,
> > >
> > > Johny Srouji suggested that we follow a convention for tagging
> > > datatype-specific emails under sv-bc, to make it easier to
> > filter and
> > > organize our mails. I think that this is a great idea. I have put a
> > > "[sv-bc] DataTypes:" at the start of the subject line for
> > this mail,
> > > and I will do so for the background mails as well.
> > > We can agree on a different convention in our first meeting
> > if people
> > > have other ideas.
> > >
> > > I met with Matt Maidment to discuss how to get resolution
> > on a "nets
> > > on datatypes" extension by Dec. 1. I have appended a
> > schedule that we
> > > agreed could get our primary objective accomplished. We
> > can discuss
> > > this at our first meeting.
> > >
> > > Kathy
> > >
> > > >Initial net datatype work covers 2 areas:
> > > >1) Extending syntax and semantics for net declarations
> > > >2) 2-state net semantics
> > > >
> > > >The first area is the primary goal of the subgroup.
> > > >The second area is a stretch goal of the subgroup.
> > > >
> > > >Proposed Schedule:
> > > >Nov 4 - last day to call for future face-to-face meeting
> > Nov 11 -
> > > >first draft of proposal Nov 15 - special edition sv-bc meeting to
> > > >review proposal Nov 18 - second draft of proposal Nov 22
> > - vote on
> > > >proposal if possible Nov 30 - third draft of proposal if
> > needed Dec
> > > >1-3 - special edition sv-bc meeting for a final vote if needed
> > > >
> > > >Face-to-face meeting will only be called if progress is slow or
> > > >consensus is challenging. Face-to-face meeting would likely be
> > > >schedudule for Nov 18 or Nov 19.
> > > >
> > > >There is a regularly scheduled SV-BC meeting on Dec 6th. We would
> > > >like the P1800 to consider this date as a last possible chance to
> > > >vote on the proposal.
> > > >
> > > >Subgroup Logistics:
> > > >Weekly conference calls to be scheduled pending
> > participant feeback
> > > >on day/time preferences.
> > > >
> > > >SV-BC reflector will be used for all related e-mail communication.
> > > >
> > > >Cross-committee impact:
> > > >Subgroup would benefit from representation from sv-ec champion and
> > > >sv-cc champion (DPI). sv-ac impact would appear minor.
> > > >
> > > >DPI specification will not be addressed by the subgroup.
> > > >
> > > >VPI specification will not be addressed by the subgroup.
> > > >Kathy will pursue a VPI donation related to this work.
> > > >
> > > >Other:
> > > >Details of adding a new net type 'wone' has been done through
> > > >1364 to-date and Kathy believes it should remain there.
> > >
> >
> > --
> > Shalom Bresticker Shalom.Bresticker
> > @freescale.com
> > Design & Verification Methodology Tel:
> > +972 9 9522268
> > Freescale Semiconductor Israel, Ltd. Fax:
> > +972 9 9522890
> > POB 2208, Herzlia 46120, ISRAEL Cell:
> > +972 50 5441478
> >
> > [ ]Freescale Internal Use Only [ ]Freescale Confidential
> > Proprietary
> >
> >
> >
>
>
>
Received on Thu Oct 28 01:40:52 2004