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

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

"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 :(

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
-- 
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.