[ibis-macro] Re: Control inputs for building blocks

  • From: "Todd Westerhoff (twesterh)" <twesterh@xxxxxxxxx>
  • To: <arpad.muranyi@xxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 30 Aug 2005 10:55:38 -0400

Sorry for the delay in reply - I vote for starting simple; constant
valued R, L, C elements, et al.

Todd. 


Todd Westerhoff
High Speed Design Group Manager
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@xxxxxxxxx
ph: 978-936-2149
============================================
 
"Always do right.
 This will gratify some people and astonish the rest."
 
- Mark Twain


-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, August 23, 2005 5:30 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Control inputs for building blocks

To all,

This subject came up again in today's macro modeling meeting.
Here is a short summary to recap the issue.

Parameters in both *-AMS languages are handled as constants, which means
that they can only be changed at the beginning of a simulation.  If
there is a need for a "dynamic" parameter which can change during a
simulation, such as a voltage controlled resistor (VCR), then we need to
add another terminal or port to the model which contains the control
input.  This can be done very easily in the *-AMS languages, no problems
there.

The question revolves around the original goal of the "standard macro
modeling library" idea.  The purpose with this was to make macro models
possible using the *-AMS netlisting syntax using the building block in
the standard library, and then SPICE vendors who don't have *-AMS
capabilities could substitute their own native elements for the building
blocks found in the library.

With this goal the question becomes, can a resistor, capacitor etc...
*-AMS model be substituted by a corresponding SPICE element if it has
more than just two terminals?  It was suggested that this could be done
by writing a wrapper around a "normal" element.  For example, in HSPICE
we could write the following code to substitute such a controlled
resistor:

.SUBCIRCUIT  myVCRmodel  n1  n2  ctrl  ctrl_ref
R1  n1  n2  R='V(ctrl, ctrl_ref)'
.ENDS

where the voltage between terminals "ctrl and ctrl_ref"
contains the value for the resistor, represented as a voltage.

The follow-on question is whether this could also be done when the
control terminal in the *-AMS model is not a voltage or current
(electrical type), but simply just a "real" number?
I.e., the conversion from voltage or current to a real number would take
place outside the building block, and the building block would only have
three terminals.

This option is less SPICE like, so from the macro model writer's
perspective it may be a less familiar syntax.

I am now in the process of writing the building blocks for the library.
I would like to solicit responses to the following
questions:

1)  Should we include this capability in the building block
    library, or is it enough to have a set of constant valued
    R, L, C elements?
2)  If we had this capability, should we have two additional
    terminals for a controlling voltage or current, or should
    we make the control input a single terminal where a real
    number is supplied to the building block?

Please speak up now, or forever hold your piece...

Thanks,

Arpad
==============================================================

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
(twesterh)
Sent: Wednesday, August 17, 2005 1:18 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Charge conserving capacitor model

My vote:

Keep it simple for now, and come up with a solution for a charge
conserving model when we're developing a model template that needs one.

Todd.


Todd Westerhoff
High Speed Design Group Manager
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@xxxxxxxxx
ph: 978-936-2149
============================================

Other related posts: