[ibis-macro] Re: Summary and recomendations regarding Analog Buffer Modeling discussion (Tstonefile, ...) CLARIFICATIONS RELATED TO BIRD 144
- From: Feras Al-Hawari <feras@xxxxxxxxxxx>
- To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>, "IBIS-ATM@xxxxxxxxxxxxx" <IBIS-ATM@xxxxxxxxxxxxx>
- Date: Fri, 9 Dec 2011 01:44:18 -0800
Hello Walter,
Regarding your recommendation to reject BIRD 144:
1) IBIS draws clear boundaries between (a) AMI (the dll, which is a
blackbox to model equalization, CDR, etc), (b) the analog I/O Buffer itself,
and (c) the package parasitics.
2) Currently, the analog I/O buffer is always defined in block (b) above
i.e., in between the AMI and package parasitics blocks.
3) Also, the I/O buffer itself can be represented using the regular VT/VI
tables or using a SPICE-like subckt in the [External Model] section.
Based on the above IBIS boarder lines, I think that the most suitable place to
point to a linear/analog I/O buffer that is represented using S-parameter data
(in a Touchstone file) is from the [External Model] section.
Unlike BIRD 122, both BIRDs 116 and 144 conform with the above IBIS hierarchy.
BIRD 116 suggests referencing a Touchstone file from within an ISS SPICE subckt
wrapper (which is OK). While BIRD 144 augments BIRD 116 by allowing the user to
DIRECTLY reference the Touchstone file (i.e., without the need to wrap it
inside a SPICE-like subckt) from either an [External Model] or an [External
Circuit].
Referencing the Touchstone from the [External Model]/[External Circuit]
sections allows the user to use a linear/analog I/O buffer represented using
S-parameter data WITH/WITHOUT the AMI block (i.e., in a general manner). Hence,
it does not limit the usage of Touchstone files with the existence of the AMI
block in the IBIS file. So, our approach is more general and allows the user to
use a Touchstone S-parameter file:
- From the right IBIS block
- Independently from the AMI block
- With/Without the AMI and package parasitics blocks
- To represent a linear I/O buffer when referenced from an [External
Model] section
- To represent other passive blocks (e.g., RDL, ODT) when referenced
from an [External Circuit] section
In addition, like BIRD 122, BIRD 144 proposes the idea to allow the user to
specify various Touchstone S-parameter files (that represent many user defined
corners other than the typical min/max/typ corners). The effort to specify
those corners is comparable in both BIRDs. However, BIRD 122 suggests doing
that in the AMI configuration file, which: 1) limits the usage of the
Touchstone files to the existence of the AMI block, 2) adds extra baggage to
the AMI configuration file as that file is supposed to be used to define the
parameters to the AMI block (the dll block). Conversely, BIRD 144 proposes to
add the user defined corners (to reference many Touchstone files) in the right
IBIS blocks (i.e., [External Model] and [External Circuit] sections), which
again will allow the usage of those files in a general fashion with/without the
AMI block.
Best regards,
Feras Al-Hawari
Cadence Design Systems
Chelmsford, MA
Other related posts: