The back-annotation scheme is not specific to analog, and you could use
it for ECOs too. It's just support for using behavioral models with
actual wiring so you don't have to resort to Spice etc.
Kev.
On 09/09/2010 11:28 AM, Achim Bauer wrote:
> Kevin,
>
> I am not sure if the backannotation of analog(!) parasitics is in the
> focus of SV-DC ?
> Analog layout is typically done in full-custom manner, and normally
> the interconnect parasitics
> are already constrained and taken into account during analog circuit
> implementation.
> What advantages do you see for backannotating highly accurate
> interconnect parasitics
> to "highly inaccurate" (System)Verilog(-AMS) models ?
>
> If you are thinking of backannotating parasitics to digital high-speed
> circuits,
> or to (very slow) digital ultra-low power architectures, then I
> understand your case.
> Please can you give an example for a typical application of your
> proposed methodology?
>
> Kind regards,
> Achim
>
>
>
> ----- Original Message ----- From: "Kevin Cameron" <edaorg@v-ms.com>
> To: <sv-dc@eda.org>
> Sent: Thursday, September 09, 2010 7:07 PM
> Subject: Re: [sv-dc] Draft of SV-DC roadmap - power/back-annotation
>
>
>>
>> There's a standing proposal for AMS for back-annotation which is just
>> the ability to redirect port/oomr connections at elaboration, i.e. after
>> you instantiate the hierarchy of the design you do a pass to fix where
>> things are connected - something like the defparam pass. Once the
>> connections are defined the normal rules of connectivity apply. The
>> back-annotated information is just regular Verilog rather than different
>> language (like SDF).
>>
>> In my opinion OOMRs are best treated as "virtual ports", and their
>> connection would normally be handled about the same time as you want to
>> do the back-annotation redirects.
>>
>> http://www.eda-twiki.org/svdb/view.php?id=866
>> http://www.eda-twiki.org/cgi-bin/view.cgi/VerilogAMS/BackAnnotationProposal
>>
>> Related issues -
>>
>> http://www.eda-twiki.org/svdb/view.php?id=2343
>>
>> Note: the back-annotation and supply connectivity stuff is mostly
>> something that is dealt with at elaboration time and as such is
>> orthogonal to simulation semantics.
>>
>> Kev.
>>
>>
>> On 09/09/2010 02:20 AM, Achim Bauer wrote:
>>> 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.Received on Thu Sep 9 11:35:55 2010
This archive was generated by hypermail 2.1.8 : Thu Sep 09 2010 - 11:35:55 PDT