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.