[ibis-macro] Re: Summary and recomendations regarding Analog Buffer Modeling discussion (Tstonefile, ...) CLARIFICATIONS RELATED TO BIRD 144
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'Feras Al-Hawari'" <feras@xxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 09 Dec 2011 08:56:46 -0500 (EST)
All,
This e-mail got bounced, resending, apologies if you get it more than
once.
Walter
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Friday, December 09, 2011 8:38 AM
To: 'Feras Al-Hawari'; 'ibis-macro@xxxxxxxxxxxxx';
'IBIS-ATM@xxxxxxxxxxxxx'
Cc: 'Muranyi, Arpad'; 'Taranjit Kukal'; 'Ambrish Varma'; 'Terry Jernberg'
Subject: RE: [ibis-macro] Summary and recomendations regarding Analog
Buffer Modeling discussion (Tstonefile, ...) CLARIFICATIONS RELATED TO
BIRD 144
Feras,
Please note that I suggested that BIRD 116 be enhanced to allow the
following languages:
Enhance BIRD 116 to allow the following Languages, and keywords for each
language (keyword names and syntax TDB)
Touchstone
.
Generic_Tx
.
Generic_Rx
.
ISS
As defined in BIRD 116
BSS
This is same as ISS, except the subckt is compliant with IBIS Buffer Spice
Subckt (IBIS BSS). IBIS BSS is a superset of IBIS ISS. IBIS BSS contains
additional elements, such as PWL controlled sources, event detectors, and
timers. IBIS BSS subckt can be written to be equivalent to a compliant
legacy "B" element.
This satisfies all your objections:
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.
Note that I added Language Touchstone to [External Model] as you requested
in BIRD 144, so I am recommending combining BIRD 144 with 116, and also
adding Generic_Tx (Equivalent Tx) and Generic_Rx (Equivalent Rx), and a
placeholder for IBIS BSS (ISS with non-LTI elements). So this does exactly
as you ask.
The additional thing that I added is some reserved AMI parameters that
parameterized Languages Touchstone, Generic_Tx, and Generic_Rx. I suggest
that these keyword in the AMI file are also equivalent to the information
required in the [External Subckt] and recommend that when present putting
the same information into the IBIS [External Model] is not required,
redundant, error prone, I think the word "Gobbledygook" is quite accurate.
Gobbledygook is any text containing jargon
<http://en.wikipedia.org/wiki/Jargon> or especially convoluted English
that results in it being excessively hard to understand or even
incomprehensible <http://en.wikipedia.org/wiki/Understanding> .
Please remember that there are three corners to the IBIS triangle. IC
Vendors, Users and EDA vendors. You, and the other EDA Vendors are
adamant about the purity of IBIS. IC Vendors and Users have a job to get
done, and cannot wait for IBIS to solve this problem a year or two from
now. BIRD 122 was submitted well over a year ago, and a number of IC
Vendors are delivering models that uses the BIRD 122 syntax. Any EDA tool
that can read can use the data in the currently delivered .ami files and
build programmatically (by modifying the IBIS file to be compliant with
either BIRD 116 or 144) solutions for their EDA tool.
The IBIS Summit at DesignCon will be an excellent venue for us to discuss
this with all of the IBIS members to determine what IBIS should do.
Walter
From: Feras Al-Hawari [mailto:feras@xxxxxxxxxxx]
Sent: Friday, December 09, 2011 4:44 AM
To: ibis-macro@xxxxxxxxxxxxx; IBIS-ATM@xxxxxxxxxxxxx
Cc: wkatz@xxxxxxxxxx; Muranyi, Arpad; Feras Al-Hawari; Taranjit Kukal;
Ambrish Varma; Terry Jernberg
Subject: Re: [ibis-macro] Summary and recomendations regarding Analog
Buffer Modeling discussion (Tstonefile, ...) CLARIFICATIONS RELATED TO
BIRD 144
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:
