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

I'd have some concern about exactly how to define a
resolution function with time dependencies. I think
that it is possible *if* such a function was defined
as being equivalent to a process with known rules for
triggering and scheduling. But even then, we'd probably
need to think about this as a task since I wouldn't
want to create a special rule for resolution functions
to allow a delay within the function. With such
definitions one must also be very careful about what
kind of "connection" semantics are assumed to the
resolution function -- if one can read an input after
a delay, is the "most recent" value on the input
expected? If so, does that assume we have "ref"
semantics? That would also be a special case since "ref"
inputs are not permitted to be nets and the other modes
all follow copy semantics.

Gord.

Achim Bauer wrote:
>
> 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.
>>
>>
>>
>>
>>
>
>
>

-- 
--------------------------------------------------------------------
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.