Re: [sv-dc] Draft of SV-DC roadmap - power/back-annotation

Hi Kev,

these are important aspects.
I think even, that we mentioned/discussed them once and again.
The great thing with (user-defined) aggregates and resolution processes(!)
is,
that they already include/enable all of these features IMO.

So, what keeps you from transporting and processing power supply information
within aggregates and resolution processes?
(remark: a resolution process also takes or may take care of type
conversion)

Regarding back annotation: a powerful resolution process can also be seen as
a kind of "smart net"
and you might simply attach backannotated interconnect capacitance to the
already accumulated "regular" load capacitance
or loading strength within a particular resolved net.

(Even "distributed" nets might be supported by this approach, so that you
could backannotate resistance per wire segment
and handle IR drop; but to break-up/split a net into wire segments and
simulate those in a quasi-conservative way
would be very costly in terms of simulation performance of course.)

Kind regards,
                     Achim

Tel.: +49 8161 807 484

----- Original Message -----
From: "Kevin Cameron" <edaorg@v-ms.com>
To: "Little Scott-B11206" <B11206@freescale.com>; <sv-dc@eda.org>
Sent: Wednesday, September 08, 2010 10:16 PM
Subject: Re: [sv-dc] Draft of SV-DC roadmap - power/back-annotation

>
> At end of B (Type Conversion and Compatibility) -
>
> R+1: [SHOULD] Mechanisms for type conversions to access nominal and
> actual power supplies (for accurate conversion of logic values to
> voltages etc.).
>
> R+2: [SHOULD] Mechanisms for back-annotating circuitry (parasitics and
> wiring) that work with the above mechanisms (so that post
> place-and-route simulations will work with the models using user-defined
> wire types).
>
>
> Note: for R+1 if you had AMS Disciplines you might want to use those to
> get nominal voltages pre-synthesis, post-synthesis you want an actual
> connection. Post P&R you want a connection into the back-annotated wiring.
>
> My view is that you need to have a general scheme in mind that will
> support this functionality in the long term or things will get really
> messy. I.e. any proposal that cannot support back-annotation and power
> supply connectivity at some point in the future should be rejected (the
> Verilog-AMS connect-module methodology is partially broken in this
> respect).
>
> Kev.
>
> On 09/07/2010 08:36 AM, Little Scott-B11206 wrote:
>> Hi Kevin:
>>
>> Would you please suggest some specific wording for the power supply
>> connectivity and back-annotation items?
>>
>> Thanks,
>> Scott
>>
>>
>>> -----Original Message-----
>>> From: Kevin Cameron [mailto:edaorg@v-ms.com]
>>> Sent: Monday, September 06, 2010 10:47 PM
>>> To: Little Scott-B11206
>>> Cc: sv-dc@eda.org
>>> Subject: Re: [sv-dc] Draft of SV-DC roadmap
>>>
>>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
> --
> 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.