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

I personally believe an attribute would suffice. It'll not only indicate the
intent explicitly, but also lets the tools (logic synthesis in my case) to error
out if the intent does not match the expected logic.

Thanks,
- Krishna.

Stuart Sutherland wrote:
> Kevin,
>
> I like the idea of adding a $driver_count to the list of specialty system
> functions in SystemVerilog, along with $onehot and $countones. It is a
> simple PLI application to write, but alas, some of the major simulators have
> yet to fully implement that part of the Verilog-2001 VPI.
>
> I am not so keen on using assertions to determine how many sources drive a
> net, however. First, it puts the burden on the engineer to add the
> additional assertion checks. Second, if coded poorly, the assertion could
> be checking throughout simulation, when in reality it only needs to be
> checked once. Third, design errors caused by inadvertent multiple sources
> won't be caught until simulation or formal analysis is actually running.
>
> a semantic restriction of a single driving source can be an elaboration
> check that prevents me from having to actually run simulation or formal
> analysis to find a design error. SystemVerilog already adds this semantic
> restriction on variables. IMHO, it would be useful to have an orthogonal
> semantic restriction on nets. In other words, I am in favor of the
> capability of a "wone" data type, but I am not in favor of doing this
> capability as a new net type keyword.
>
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898
>
>
>
>>-----Original Message-----
>>From: Kevin Cameron [mailto:sv-xx@grfx.com]
>>Sent: Wednesday, October 27, 2004 11:39 PM
>>To: sv-bc@eda.org
>>Cc: btf-dtype@boyd.com; Shalom.Bresticker@freescale.com;
>>mckinley@cadence.com; stuart@sutherland-hdl.com
>>Subject: 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/A
>>MS-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 13:24:06 2004