[ibis-macro] Re: Analog BIRD overview slide
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 09 Jan 2012 12:58:46 -0500 (EST)
Arpad,
There is nothing in what I propose that is at all inconsistent with IBIS.
An IBIS file is a list of components. Each component is a list of pins.
Each pin points to a [Model] and a package subckt. Each [Model] either
points to its own IV/VT curves, or [External Model], or External BSS/ISS.
Each [Model] can also point to an AMI file.
When a [Model] points to IV/VT curves, [External Model], External BSS/ISS,
or an AMI file it is a valid point, should all of the "wrapper" data for
IV/VT curves, [External Model], External BSS/ISS, or an AMI exist in the
IBIS file itself, or in separate files. It is quite annoying for IC
Vendor's to supply a set of IBIS files that all contain the same [Model]s.
This is an opportunity to not have the [Model] data repeated in each IBIS
file but be considered a library element.
What is wrong with this approach?
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, January 09, 2012 12:48 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog BIRD overview slide
Correction, [External Circuit]s are pointed to by the CIRCUITCALL
mechanism, not the buffer [Model]. But this doesn't change what I was
trying to describe in general...
Arpad
======================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, January 09, 2012 11:44 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog BIRD overview slide
Walter,
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.
Thanks,
Arpad
==========================================================================
====
-----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
Arpad,
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
String))
(Subckt ( Corner "typ" "slow" "fast" ) (Usage Info)
(Type String))
(Ports (Usage Info) (Type String 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
Float))
(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]
section.
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)))
Walter
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
