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

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
Cirrus Logic
(512) 851-4612
(512) 293-7248 (mobile)
-----Original Message-----
From: Scott Cranston [mailto:cranston@cadence.com]
Sent: Tuesday, August 17, 2010 2:15 PM
To: Achim Bauer; 'Kevin Cameron'; Lear, Jim
Cc: sv-dc@eda.org
Subject: RE: [sv-dc] sv-dc: please have a look

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.