[ibis-macro] Re: Summary and recomendations regarding Analog Buffer Modeling discussion (Tstonefile, ...) CLARIFICATIONS RELATED TO BIRD 144
- From: Feras Al-Hawari <feras@xxxxxxxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 9 Dec 2011 06:41:31 -0800
Hello Walter,
My comments below in red:
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
Feras> This is in agreement with what we are proposing in BIRD 144
...
Generic_Tx
...
Generic_Rx
...
Feras> I am not sure if I missed something regarding the above two. But I
personally don't like the idea of having Generic_Tx and Generic_Rx, as I
consider them extra baggage in the IBIS spec. As such circuits (if I am not
wrong) can be represented using ISS or any other SPICE (or even VHDL/Verilog).
Hence, using an [External Model] with language ISS should be good enough to
model such blocks as they are intended to model Tx/Rx, which belong to IBIS
block (b) i.e., the analog I/O buffer block. So the user can construct the
Generic_Tx and Generic_Rx circuits using the appropriate SPICE elements inside
the subckt wrapper without the need to introduce new language/constructs in the
IBIS spec.
Feras > My concern is how many generic blocks or something alike does the IBIS
spec need to accommodate in the future. The best way to address such an issue
is using standard/generic constructs/languages that enable the user to model
whatever circuit is needed (e.g., SPICE, Touchstone, VHDL, etc).
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.
Feras> I agree and based on that BIRD 144 should not be rejected but rather
merged with BIRD 116 as you suggested above.
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.
Feras> I am in agreement regarding adding Touchstone, ISS, and BSS. But I have
concerns regarding the Generic_Tx and Rx.
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.
Feras> Again, I strongly recommend keeping the IBIS boundaries clean and clear.
As an organized and consistent spec/standard will always make everything that
depends on it fall in place in a much easier way. I understand that users are
always pushy, but that should not distract us (EDA vendors) from delivering the
best solutions/standards in a timely manner. Based on that, I strongly believe
that anything related to an analog I/O buffers should be separated/removed from
the IBIS AMI block. Specifically, in this case, it should be done in the
[External Model] section.
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.
Feras> Yes that is true.
Best regards,
Feras
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:
