[ibis-macro] Re: Analog BIRD overview slide

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 9 Jan 2012 17:44:10 +0000


While there are a lot of good thoughts in your ideas, I have strongly
mixed feelings about them.  These mixed feelings are stirring up a lot
of fundamental issues and questions related IBIS in general.

The IBIS hierarchy started out as chip centric.  Inside the [Component]
keyword, we have a [Pin] keyword with a list of pins.  Either the
component or the pins describe ("instantiate") the package.  The pins
also "instantiate" the buffer [Model]s.  The [Model]s have pointers
to [External Model]s, [External Circuit]s, and [Algorithmic Model]s.
IBIS is the central location to reach out to all of these more or less
external components.

The problem I see in some of your suggestions found in the analog BIRDs
as well as in this email is that you seem to be trying to go the opposite
way.  You are making suggestions to define and instantiate the analog models
(subcircuits) from the .ami, or .bsi files.  You are also making suggestions
to instantiate package models from the buffer [Model].  I feel I am losing
ground here.  It feels that you are trying to turn things inside out.  Or
if we kept all of these instantiation approaches, it feels as disorganized
spaghetti code (mess).

I know, these different approaches may be suitable for different types of
design work, chip design, vs. board design, or package design, etc...  I
don't know what the best approach is at the moment, going inside out, or
outside in, I am just expressing my reactions that your suggestions create
in me.  If the original pin list driven approach is not useful any more,
let's reorganize IBIS.  But I don't think it is a good idea to pretend that
we are keeping the original pin list driven approach, while we introduce
all kinds of backdoor approaches, creating a disorganized mess and confusion.

Sorry for the cold reception.  I may not see the light in this yet, but these
are my first impressions.



-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Wednesday, January 04, 2012 12:11 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Analog BIRD overview slide


Let me propose a new approach to Analog Models. I will go for the gold,
and assume that we have defined IBIS-BSS (Buffer Spice Subckts). An
IBIS-BSS will be one (or more) .bss files. There is similar complexities
of interfacing to a SPICE subkt as there are to interfacing to an AMI DLL.
My suggestion is that the interface to the subckt be a .bsi file using the
parameter tree language we defined for .ami files.

Using the various Formats, Usage and Types we can use the .bsi file to
handle more than three corners, and defining additional subckt ports and
parameters that would be passed to the subckt. Here is an example of what
an IO buffer .bsi file might look like:

(Model_Type (Value "I/O") (Usage Info) (Type String))
(Supporting_Files (List "typ.bss" "slow.bss" "fast.bss") (Usage Info)
(Type String))
(File         (Corner "typ.bss" "slow.bss" "fast.bss") (Usage Info) (Type
(Subckt  ( Corner "typ"        "slow"         "fast"        ) (Usage Info)
(Type String))
(Ports     (Usage Info) (Type String String String String String String
                 (Table  ("Stimulus" "Enable" "Pad" "Z" "PuRef" "PdRef")))
(Stimulus (Rise_Time (Corner 50e-12 70e-12 30e-12) (Usage Info)(Type
                    (VoL (Value 0.) (Usage Info)(Type Float))
                    (VoH (Value 1.) (Usage Info)(Type Float)))
(Enable (Rise_Time (Corner 50e-12 70e-12 30e-12) (Usage Info)(Type Float))
                    (On (Value 0.) (Usage Info)(Type Float))
                    (Off (Value 1.) (Usage Info)(Type Float)))
(PdRef (Value 0.) (Usage Info)(Type Float))
(PuRef (Corner 1.3 1.1 1.5)  (Usage Info)(Type Float))
(Params (Vref (Corner .65 .55 .75) (Usage In)(Type Float))
                 (Framis (Corner 53 87 24) (Usage In)(Type Float)))   

An AMI ISS Tx .bsi file might be:

(Model_Type (Value "Differential_Output") (Usage Info) (Type String))
(File         (Value "AMI(subckt_file)") (Usage Info) (Type String))
(Subckt  (Value "AMI(subckt)") (Usage Info) (Type String))
(Ports     (Usage Info) (Type String String String String))
                 (Table  ("Stimulus_H" "Stimulus_L" "Pad_H" "Pad_L")))
(Stimulus (Rise_Time (Value AMI(Trf)) (Usage Info)(Type Float))
                    (VoL (Value 0.) (Usage Info)(Type Float))
                    (VoH (Value AMI(Voh)) (Usage Info)(Type Float)))
 (Params (Rs (Value AMI(Trf)) (Usage In)(Type Float))
                   (Framis (Value AMI(Framis)) (Usage In)(Type Float)))   

I think both of these example are self-documenting, and describe exactly
how a model instance would be instantiated in a SPICE netlist.

Of course, this syntax can be included directly in the .ibs file, but it
may be convenient to have them in separate files that get delivered with
the .bss and .iss files. This way multiple .ibs files that used the same
buffer model would only need a pointer to the .bsi file in the [Model]

I think package modeling could use a similar approach. For example, all of
the pin models of a package can often use the same subckt on each pin,
parameterized by a length. So associated with each pin might be a .ips
file e.g. in the [Pin] section, instead of NA NA NA for RLC as in: 
     <pin> <signal> <mode> NA NA NA
one might have
     <pin> <signal> <mode> pkg.ips pkglen=.01

And then the pkg.ips file might be

(Model_Type (Value "Single_Ended") (Usage Info) (Type String))
(File         (Value "pkg.iss") (Usage Info) (Type String))
(Subckt  (Value "pkg") (Usage Info) (Type String))
(Ports     (Usage Info) (Type String String))
                 (Table  ("Pad" "Pin")))
(Params (pkglen (Range .015 .05 .3) (Usage In)(Type Float))
                  (Impedance (Range 50 45 55) (Usage In)(Type Float)))   

IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector:  http://www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe

Other related posts: