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=0B3Q59OpAdnEcZGFkYjQ5ODctNGM1MC00
>>>> 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.