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=0B3Q59OpAdnEcZGFkYjQ5ODctNGM1MC00ZTNmLTlmM2EtZjFlZGRkNjc4YmRh&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.