AW: [sv-dc] sv-dc: please have a look

 
Scott, Jim, Kevin, thanks for your interesting comments and ideas!

Just a few short remarks:

> Scott: "I don't think it is unreasonable to build some sort of saved-state
ramp behavior
> into the discrete algorithm for, say, real nets."

Sounds good :)
That would be a worthwhile feature i.m.o, especially for assertions.

> Jim: "Achim and I talked last week, and -- correct me if I'm wrong, Achim
-- I think we agree
> that it's possible to have the state maintained by the driver or the
monitor rather than
> the resolution function or net."

We discussed my proposal of a powerful methodology for event-based,
quasi-conservative solution
of analog components that might occur within a system's netlist. For such a
methodology it
would have been required to implement resolution "processes" with inner
states and not only
plain functions.
I emphasized, that the particular resolution process associated with each
(hierarchical) net/node
should naturally contain and evaluate all the information that is available
there;
a net's state (vector) should not merely be scattered over all of its
environment i.m.o.
Jim, you gave me the impression, that you would not strongly support this
methodology
and so I do not see much reason to further explain/promote this approach
within the committee.
Of course I agree with you, that it is possible to copy/shift a net's state
to all its
drivers, loads and monitors.

Best regards,
             Achim

 
Tel: +49 (0)8161 807 484
Mobile: +49 (0)160 387 63 68

-----Ursprüngliche Nachricht-----
Von: Kevin Cameron [mailto:edaorg@v-ms.com]
Gesendet: Mittwoch, 18. August 2010 01:01
An: Lear, Jim
Cc: Scott Cranston; Achim Bauer; sv-dc@eda.org
Betreff: Re: [sv-dc] sv-dc: please have a look

You should be able to implement arbitrary length hold-up on nets using the
driver access functions in Verilog-AMS - a sort of discrete capacitor model
(like trireg) - but it only works properly if you can accumulate the
capacitance of the net (multiple discrete models in parallel would just give
the behavior of the largest individual instance). Resolution functions can
accumulate capacitance so you get more accurate behavior.

It's probably worth having some way of saying that if you have multiple
"capacitance drivers" then they can be resolved together before being
resolved with current drivers - in a previous posting I suggested promoting
current and capacitance drivers to a combined driver before resolving, but
the capacitances are likely to be constant so they only need resolved once.
This is similar to the lossy/non-lossy conversion attribute I mentioned in a
previous post, i.e. currents and capacitances resolve with themselves in a
non-lossy manner (they just add), while logic resolves with itself in a
lossy manner (1 and 0 -> X).

So my addition to the previous postings
(http://www.eda-stds.org/sv-dc/hm/0062.html,http://www.eda-stds.org/sv-dc/hm
/0078.html)
would be that you resolve with the nearest (typewise) non-lossy resolution
function in type-hierarchical manner until everything is resolved.

E.g. if you see capacitance drivers, current drivers and logic drivers on
the same net then you look to see if each driver type can resolve to itself
without loss and after that if it will convert to one of the other types.
Assuming that there is a non-lossy logic -> current connect/conversion
function, but it doesn't resolve to itself without loss, you convert all
logic drivers to currents. Currents resolve to a single current,
capacitances to a single capacitance, and those two resolve to a PWL
voltage. Something like the following (for three logic drives, one current
and two caps):

  logic->current->\
  logic->current-> |
  logic->current-> |
                   |->current ->\
  current ->/ |
                                    |-> PWL Voltage
  capacitance ->\ |
                   |->capacitance->/
  capacitance ->/

In this scheme the resolved value can be determined with minimum effort
since static analysis will tell you which drivers are constant at
elaboration and you can prune the evaluation tree.

Kev.

On 08/17/2010 12:26 PM, Lear, Jim wrote:
> Achim and I talked last week, and -- correct me if I'm wrong, Achim -- I
think we agree that it's possible to have the state maintained by the driver
or the monitor rather than the resolution function or net. My memory is a
little fuzzy now, so perhaps Achim can correct.
>
> Kindest Regards,
> Jim Lear
> ...
> -----Original Message-----
> From: Scott Cranston [mailto:cranston@cadence.com]
> To: Achim Bauer; 'Kevin Cameron'; Lear, Jim
>
> Hi all,
>
> Plain vanilla Verilog has something called a "trireg" which provides a way
to model charge decay on a net. These nets will "spontaneously" go to X
after a set period of time when all the drivers are removed. Given this
precedent I don't think it is unreasonable to build some sort of saved-state
ramp behavior into the discrete algorithm for, say, real nets. Also don't
think it is that hard to implement, but don't quote me on that.
>
> -- Scott
>
>
----------------------------------------------------------------------------
---------------------------------------------------------
> Scott Cranston | AMS Designer Simulation Group | Cadence
> P: 978.262.6217 M: 978.771.2696 www.cadence.com
> ----------------------------------------------------------------------
> ---------------------------------------------------------------
> "The American Republic will endure until the day Congress discovers that
it can bribe the public with the public's money."
> - Alexis De Tocqueville
>
>
> -----Original Message-----
> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
> Achim Bauer
> Sent: Thursday, July 29, 2010 5:24 PM
> To: 'Kevin Cameron'; 'Lear, Jim'
> Cc: sv-dc@eda.org
> Subject: AW: [sv-dc] sv-dc: please have a look
>
> Hi Jim, Hi Kev,
>
> my example is NOT about pseudo-analog simulation of lumped conservative
networks!
> It is just about a reasonable model to render/resolve the delay/slew in
multi-driver real-value nets.
> This is merely driven by events in the particular drivers, there is no
need for any additional time stepping or tolerances in that case!
>
> For the given example the function for the net value n(t) is as simple
> as
> that:
> t>te: n(t) = n(te) + ((a(te)-n(te))/RC)*(t-te)
> t>te+RC: n(t) = a(te)
> Each new driver event (@te) and new real-value to be driven (a(te))
requires an update of this equation based on the actual net value (n(te)).
> If an assertion "pokes" the net, n(t) is evaluated also.
>
> You both are considering a more powerful, comprehensive methodology for
"discrete" simulation of analog networks.
> In my opinion that is very interesting and important (I wrote about this
in my last proposal).
> But unfortunately I doubt, that you will find positive vibes for this
among the SV-folks.
>
> Achim
>
>
> -----Ursprüngliche Nachricht-----
> Von: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] Im Auftrag von
> Kevin Cameron
> Gesendet: Donnerstag, 29. Juli 2010 20:49
> An: Achim Bauer
> Cc: sv-dc@eda.org
> Betreff: Re: [sv-dc] sv-dc: please have a look
>
>
> As you say a voltage pulse is a bad idea, from a modeling perspective
> I'd want to do this one as current driven - i.e. drive a current into
> the net until the voltage hits the rails (then turn it off). In order
> to do that meaningfully you need to know what the capacitance is, and
> to do that you need to add up the contributions from the various
> components attached to the net. So you end up with something where all
> the drivers have capacitance and/or a current contribution, and the
> net resolves to a voltage. It's not hard to do, but it's hard to
> define cleanly at a language level, you have multiple types -
>
> Current drivers (discrete real)
> Capacitive drives (discrete real, maybe const)
> Combined current & cap (two reals)
> Voltage driver/resolution result (PWL - discrete in 1st
> derivative)
>
> The process is then to promote the individual Current and Cap drivers to
combined Current/Cap drivers, do a resolution of those to get the PWL
voltage (which is pretty much the same as the analog/electrical type in
AMS). It's an interesting case in that the resolution yields a different
type from the drivers being resolved, and it maybe raises the issue of can
you do "cross" as a member function for that type?
>
> You can also create Resistor models that will fit in with that scheme - I
= V/R, the resistor model gets the terminal voltages and drives the
appropriate current, you just need to work out the event for re-evaluation.
> Which raise the syntax issue of how do you type a receiver and driver
differently for the same port - in AMS this is done indirectly through the
access functions potentential() & flow(), so maybe those need to be member
functions of the driver/receiver classes.
> So you might end up with something like:
>
> module resistor #(real R=1) (a,b);
> my_i_drive a,b; // local driver type
> always @(a.change(1e-3) || b.change(1-e3)) begin // sensitive to
1mv
> real i = (a.potential() - b.potential())/R; //
> a.set_flow(i);
> b.set_flow(-i);
> end
> endmodule
>
> You can have the compiler work out whether you are referring to a driver
or receiver by the name of the methods - in this case the drivers don't
support "potential", the resolved type doesn't support "set_flow".
> Likewise "change" is a method returning an event for the resolved type.
>
> Just food for thought,
> Kev.
>
>
> On 07/29/2010 10:55 AM, Achim Bauer wrote:
>
>> Hi Kev, thanks for the tip!
>>
>> Let's simply replace the digital receiver "D" by an "analog"
>> real-value receiver, then we are pure real-value; that does not alter
>> the intention/motivation of the example.
>>
>> By the way, a comprehensive resolution function in my opinion should
>> be able to resolve digital drivers together with the real ones. If a
>> testcase contains only discrete models (logic or real-value), then a
>> powerful (hierarchical) resolution function might be all we need; so
>> we would not have to worry about connect modules.
>>
>> Achim
>>
>>
>>
>> On Thu, 2010-07-29 at 10:15 -0700, Kevin Cameron wrote:
>>
>>
>>> I notice your example uses a mixed net (analog/real driver, digital
>>> receiver). We have not discussed how/whether to do cross-type
>>> conversions or resolution in SV yet, so you might want to hold that
>>> for later, meanwhile it's probably a question to direct at the ASVA
>>> committee.
>>>
>>> Kev.
>>>
>>> On 07/29/2010 05:56 AM, Achim Bauer wrote:
>>>
>>>
>>>> Hi everybody,
>>>>
>>>> in yesterday´s discussion I tried to point out a crucial
>>>> requirement for resolution of real-value nets.
>>>> Since this is VERY IMPORTANT FOR THE VERIFICATION of weak/highZ
>>>> drivers or critical/heavy/erroneous loading effects, I illustrated
>>>> the example once again for you ( it´s just a single page :)
>>>>
>>>> Please have a look and let me know about your opinion !
>>>>
>>>> Thanks, regards,
>>>> Achim
>>>>
>>>> P.S. the doc is also available via google-link:
>>>> http://docs.google.com/fileview?id=0B3Q59OpAdnEcZGFkYjQ5ODctNGM1MC0
>>>> 0 ZTNmLTlmM2EtZjFlZGRkNjc4YmRh&hl=en&authkey=COPZqc8O
>>>>
>>>> --
>>>> 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.
>>>
>>>
>>
>>
>
> --
> 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.
>
>
>
>
>
>

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