AW: Minutes from meeting on 2010.06.08 - solvers

Hi Jim,

thanks, now I understand the considerations about matices you issued last
time in the meeting.
Following I am freely quoting you out-of-context, sorry for being a bit
manipulative ;)
My opinion ( quick one, not deeply thought through ) is:

Jim: "The resistor model will drive port N with the Thevenin values (VPe,
RPE+R)."

Achim: "In general, a real-value model is transporting discrete information
about its actual
internal driving characteristic through the ports (e.g. via structs) to the
outside,
where it is resolved."

Jim: "However, this won't work when plugging into a matrix solver.
The matrix solver will present either a voltage or current.
This could be a problem the EDA firms might be able to solve."

Achim: "This is, where connect modules might come into play.
E.g., if a sophisticated connect module must "resolve" a multi-driver
situation with a few
analog drivers (part of the matrix) and a few digital drivers, e.g. a "weak"
pull down and
a "strong" digital buffer, then the connect module takes the digital drivers
and replaces them
by a simple equivalent V-R-C network: the digital signals are taken and
translated into
corresponding voltage levels that each control an ideal voltage source; the
weak source e.g.
gets a 1MOhm resistor in series, the strong one 10KOhm (use
$driving_strength function).
Via this mapping of the discrete state to an equivalent circuit within the
connect module,
the discrete information (e.g. Thevenin) becomes part of the analog network
matrix.
In practice it must be possible for the user to write such connect modules;
it will not work out well
exclusively with black-boxed and hence unflexible objects proprietory to the
particular flow.
So in the future some committee might specify this methodology in detail
(e.g. for structs).
But this is not really within the discrete SV-DC focus."

Jim: "I was just thinking out loud how one might improve the plug and play
ability."

Achim: "Yes, plug & play is a very important feature for
application-specific abstraction
of mixed-signal systems ! ;)

-----Ursprüngliche Nachricht-----
Von: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] Im Auftrag von Lear,
Jim
Gesendet: Samstag, 12. Juni 2010 03:57
An: Kevin Cameron
Cc: sv-dc@eda.org
Betreff: Re: Minutes from meeting on 2010.06.08 - solvers

What you say is correct. I was pondering systems of modeling simultaneous
equations in discrete time. Currently, real and wreal ports can handle
simple contributions. However, they can't handle simple discrete devices,
such as resistors or capacitors.

The resolution functions described in my article have enough power to model
such devices. However, modeling discrete devices requires a
knowledge of the Thevenin equivalent for all other devices on a port.
Most spice solvers don't explicitely calculate such values.

For example, a resistor model has two ports, P and N, and a resistor value
R. P is attached to some external circuits that driving a Thevenin VPe (e is
for external) and RPe. The resistor model will drive port N with the
Thevenin values (VPe, RPE+R). The value driven onto the P port is similarly
calculated from the external drivers on the N port. For this to work, one
must be able to ascertain the external driver values. This is easily done in
a discrete time situation because one knows the resolved value on a port
(which includes external drivers as well as the internally generated
driver).

However, this won't work when plugging into a matrix solver. The matrix
solver will present either a voltage or current. This could be a problem the
EDA firms might be able to solve.

But I was pondering an ability to pass parts of the matrix as a port type,
instead of a Thevenin equivalent. Could such a type system interface better
with continuous time solvers?

Regardless, I was just thinking out loud how one might improve the plug and
play ability.

Kindest regards,
Jim Lear

On Jun 11, 2010, at 8:13 PM, "Kevin Cameron" <edaorg@v-ms.com> wrote:

>> JL: That occurred to me. Matrix solvers don't have ports and drivers
>> they just have nodes. Possible to describe port or block in some
>> matrix form?
>
> The analog (Verilog-AMS) equivalent of a driver is a contribution.
> You need a solver when contribution values are simultaneously
> dependent on each other i.e. for Kirchoff's current law to hold the
> sum of the current contributions needs to be zero. If the
> contributions are not simultaneously dependent then a solver is not
> necessary, e.g. if you have a bunch of currents into a resistive load,
> and you want the resistor voltage -
>
> analog V(R) <+ (I1+I2)*Res;
>
> - the voltage can be determined analytically and no solver is required
> if I1 and I2 have no dependence on each other or V(R).
>
> The D2A elements in Verilog-AMS convert drivers to contributions.
> D2As generating voltages are not generally simultaneously dependent on
> anything else (partly due to latency through the digital circuitry).
>
>
> Note: ports should have no significance in simulation (analog or
> digital), they are just part of the syntax of how you hook things up.
>
> Kev.
>
>
>

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