Achim Bauer wrote:
> Hi Gordon, I inserted a few remarks.
>
> "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."
>
> That's exactly the point, if we want to cover all the applications I have
> listed in my SVDC-contribution, then we would need a process. There is
> another requirement that might be adressed by a process, by the way: if we
> want to avoid/replace connect modules on the discrete side, we anyway might
> need processes like the following short-pulse-filter within our
> real-to-digital converters for resolution of mixed nets:
> always @(posedge(Xin)) begin :GoToX // input changed to X
> #(txdig) // wait for X time delay
> if (Vout>vtlo && Vout<vthi) Dreg=1'bx; // goto X if still between
> else Xin=0; // else clear the X flag
> end
> always @(negedge(Xin)) disable GoToX; // cancel out-to-X on Xin=0
I agree that it would be good to avoid the connect modules if
possible; not doing so would likely complicate issues related to
interdependencies between the SV LRM and the Verilog-AMS LRM.
>
> "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."
>
> Sorry Gord, unfortunately I am not sure what you mean in this last section,
> I am just a little user :(
No problem -- I don't necessarily follow all the issues you guys
are debating either (I'm just a digital implementation guy...).
What I was trying to get at is that if we describe resolution
using a *function* (or task) in SV syntax, the semantics of
formal arguments will likely interfere. For example, assume I
have the following:
task do_add(input integer a, b, output integer sum);
#5 sum = a + b;
endtask
always @(inp1, inp2) do_add(inp1, inp2 ,sum);
At the call point, we *copy* inp1 and inp2 to the inputs of
the task. So if inp1 first changes at time 5 and then
again at time 7, the change at time 7 will not be taken
into account (in fact the trigger won't even occur since
the always process is still blocked in the task call).
So if resolution is expressed in something that looks like
the above, there will likely be some semantic surprises.
At very least we'd need to discuss whether the "process"
is implicit and created automatically on each triggering.
If that is the case, we need to be very careful about
when in the simulation cycle this happens since allowing
"extra" resolution calls would lead to (at least) races
in the propagation of results.
Gord.
>
> Best regards,
> Achim
>
> Tel: +49 (0)8161 807 484
> Mobile: +49 (0)160 387 63 68
>
>
> -----Ursprüngliche Nachricht-----
> Von: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] Im Auftrag von Gordon
> Vreugdenhil
> Gesendet: Mittwoch, 18. August 2010 16:12
> An: Achim Bauer
> Cc: 'Kevin Cameron'; 'Lear, Jim'; 'Scott Cranston'; sv-dc@eda.org
> Betreff: 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=0B3Q59OpAdnEcZGFkYjQ5ODctNGM1MC
>>>>>> 0 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
>
>
-- -------------------------------------------------------------------- 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.Received on Wed Aug 18 08:45:46 2010
This archive was generated by hypermail 2.1.8 : Wed Aug 18 2010 - 08:45:47 PDT