Re: [sv-dc] Draft of SV-DC roadmap

Hi,
my full agreement too!

The X and Z state/information might already be contained within the
(user-defined) aggregates.

"Z" might just be a special driving strength value, e.g. for a voltage
source with high series resistance and
"X" might just be a generalization for a more specific (error) notifier,
      e.g. for "(voltage) value out of range" or "slew rate too small in net
x at time y"

kind regards,
                    Achim

----- Original Message -----
From: "Lear, Jim" <Jim.Lear@cirrus.com>
To: "Gordon Vreugdenhil" <gordonv@model.com>
Cc: "Kevin Cameron" <edaorg@v-ms.com>; "Little Scott-B11206"
<B11206@freescale.com>; <sv-dc@eda.org>
Sent: Tuesday, September 07, 2010 8:34 PM
Subject: RE: [sv-dc] Draft of SV-DC roadmap

> 100% agree, Gordon.
>
> Kindest Regards,
> Jim Lear
> Cirrus Logic
> (512) 851-4612
> (512) 293-7248 (mobile)
>
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Tuesday, September 07, 2010 12:30 PM
> To: Lear, Jim
> Cc: Kevin Cameron; Little Scott-B11206; sv-dc@eda.org
> Subject: Re: [sv-dc] Draft of SV-DC roadmap
>
> On 9/7/2010 9:15 AM, Lear, Jim wrote:
>> Gordon, I don't think aggregate is synonymous with user defined.
>
>
> Not necessarily, I agree. But I'd really like the
> case of a 4-state real net with resolution be describable
> using exactly the same mechanism as we'll need for
> aggregates. Structurally trivial (non-aggregated)
> user defined types/resolutions/connectivity should not
> *require* anything different in terms of mechanism than
> true aggregated types. If we choose to make simpler types
> special for expressiveness or other reasons, that should
> be a separate discussion. I consider the ability to
> describe simple types part of the "completeness" test
> for the aggregate mechanism.
>
> Gord.
>
>
>> Kindest Regards,
>> Jim Lear
>> Cirrus Logic
>> (512) 851-4612
>> (512) 293-7248 (mobile)
>> -----Original Message-----
>> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
>> Gordon Vreugdenhil
>> Sent: Tuesday, September 07, 2010 9:20 AM
>> To: Kevin Cameron
>> Cc: Little Scott-B11206; sv-dc@eda.org
>> Subject: Re: [sv-dc] Draft of SV-DC roadmap
>>
>> R05-R09 covers aggregate (user defined) types and resolutions.
>>
>> It is actually still to be determined if a 4-state real
>> value type and related net type need to be directly part
>> of the work. It is listed to ensure that any *mechanism*
>> would be able to describe that simpler model and as a
>> separate question whether it is still desirable to have
>> the simple case directly described versus through a more
>> general mechanism.
>>
>> Once we have the general mechanism defined, we can discuss
>> whether the special case 4-state real should be added as well.
>>
>> Gord.
>>
>> On 9/6/2010 8:46 PM, Kevin Cameron wrote:
>>>
>>> I would prefer to see something like "user defined type" used instead
>> of
>>> "real valued". The aim (I think) is to support low level hardware
>>> modeling in ways that are not currently supported, which would
> include
>>> RF modeling with types other than simple real values. SV has a whole
>>> class type scheme already, seems limiting ourselves to "real valued"
>>> probably won't simplify much.
>>>
>>> Is the "X" and "Z" stuff really a "must"?
>>>
>>> Might want to add a "could" or "should" for power supply
> connectivity,
>>> and for back-annotation.
>>>
>>> Kev.
>>>
>>>
>>> On 09/06/2010 08:01 PM, Little Scott-B11206 wrote:
>>>> Hi all:
>>>>
>>>> I have attached a draft of the SV-DC roadmap. We will discuss this
>> in
>>>> the SV-DC meeting on Wednesday. If you believe that the roadmap
>> needs
>>>> to be changed and would like to discuss it on the list prior to the
>>>> meeting please send specific suggestions.
>>>>
>>>> Thanks,
>>>> Scott
>>>>
>>>>
>>>
>>>
>>
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.