Subject: [IBIS] IBIS ICM 1.0 Draft comments [LONG]
From: Mirmak, Michael (michael.mirmak@intel.com)
Date: Mon Sep 30 2002 - 14:20:54 PDT
All,
The draft IBIS ICM spec is a great start to finally standardizing the
representation of interconnects across EDA tools. After reviewing the
document in detail, I have the following questions and comments:
1) P. 13, Section 7.0 - [Begin ICM Model] defines "ICM_Model_Type" as a
Subparameter, and states explicitly that only "one ICM_Model_Type is allowed
per interconnect model." Since ICM_Model_Type covers various data
representations of a specific interconnect, such as "S-Parameter,"
"SLM_even_mode," etc., this effectively means that users cannot use several
different sets of data to describe the same connector under the same ICM
Model declaration.
An example may be illustrative here. I may wish to describe a particular
connector with s-parameter data, even mode RLGC data AND odd mode RLGC data,
in order to capture the connector's behavior under different stimulus
conditions. I cannot see a straightforward way to do this under the current
spec. I could create separate ICM models. However, the [ICM Model List]
keyword ties together models within the same "family," which is implied to
be a grouping of similar designs, not necessarily models of the same
interconnect under different stimulus conditions. An EDA tool would have no
way to recognize models within the same "family" as also being of the same
physical connector and using all the relevant data within a simulation of
that connector.
Can "ICM_Model_Type" be redefined as a keyword, to allow multiple data types
to simultaneously describe the same physical interconnect?
2) Same section - the word "direction" is used ambiguously in describing how
a signal is transitioning with respect to even and odd modes. More specific
language should be used to distinguish between data signal polarity (e.g.,
high to low) and propagation (e.g., port 1 to port 2 vs. port 2 to port 1).
3) P. 14, Same section - The ICM_Model_Type value of "S-parameter" is
defined as exclusively "multi-line," which could be confusing for
interconnects which consist of only one physical transmission line. The
use of the words "single-" and "multi-line" in several contexts in
confusing. The use of "multi-line" should be clarified as referring to the
presence of coupling in the model data, not to the number of physical
transmission lines in the interconnect.
4) Same section - Multi-line models (MLMs) are "not to be used in
simulations with perfect ground planes on both sides of the interconnect
model." What is the justification for this recommendation?
5) Same section, under "SGR" - the signal-to-noise ratio definition assumes
that any interconnect's SGR can be reduced to a single value against the
number one (1). This implies that both integers and reals are permitted for
use in describing the number of non-ground signals in the interconnect (for
example: if I have 5 grounds and 17 signals in my connector, the spec limits
me to using "3.4:1" as my SGR). Was this use of reals intended? We could
conceivably end up with cases like "1.6666666:1" as a valid description of
an interconnect with 5 signals and 3 grounds.
6) P. 17, Same section - the examples make frequent use of the word "Port"
with no attempt made to define exactly what a "Port" is. In fact, the only
place a "Port" is even partially defined in the entire document is on P. 22
(see below).
7) P. 22, Same section, [Nodal Path Description], under "N_section" - the
use of the phrase "[a] port for the S-parameter data is defined between a
node and the ideal ground" excludes the expression of mixed-mode
S-parameters (SDD11, SCC11, etc.). While this is perfectly legitimate --
differential buses can be completely described in terms of single-line
s-parameters -- was it intended? This will make calculation of mode
conversion effects more difficult. If this was intended, it should also be
noted that differential interconnects can only be completely described in
not less than 16 single-port measurements (S11, S34, S23, etc.).
8) P. 17 - 20, Same section, Examples - the [Tree Path Description] examples
given do not bear any direct relationship to the Model_PinMap examples given
later in the document. This makes them significantly less useful than the
[Nodal Path Description] examples, which do match the [ICM Node Map]
examples later in the document. The first Tree Path example is also highly
confusing, in that it implies that either the interconnect described by the
matrix reverses at least two connections along its length or that there is a
misprint in the naming of the Model_PinMap -- no other example shows an
unreversed set of internal connections AND connectors at both ends with the
same naming, appearance and connection scheme. The nature of the
interconnect should be clarified, perhaps best with a diagram.
9) P. 27, Same section, [ICM Swath Parameters] - the word "banded" is used
to describe the column or row swath matrix. This should be distinguished
from a "Banded Matrix" (capital "B") which is defined as a set of data
relative to and surrounding the matrix diagonal. The "banded" matrix of a
swath is not so limited.
10) P. 41 - 45, [Derivation Method], under "Matrix Descriptions" - this
section specifically describes how simulation tools should interpret missing
matrices, such as the optional resistance matrix. It also indirectly
implies that off-diagonal elements in the Maxwellian capacitance matrix can
be negative. However, the section never explicitly deals with cases which
can result under some solvers: negative resistances, negative inductances,
etc. Should these cases -- including positive off-diagonal Maxwellian
capacitances -- be excluded as illegal or allowed but "not recommended?"
The document should specifically address this point.
11) Same section - The RLGC matrix descriptions are significantly weakened
by the lack of a subparameter declaring at what frequency the data was
collected. Further, the specification does not allow multiple sets of RLGC
data to be included for different frequencies (unless a distinctly different
model is defined for the same physical interconnect; see item #1 above).
This will hamper direct conversion of existing data formats under many tools
into the new ICM format.
In addition, there are several editorial corrections which should be made:
a) P. 2, Section 2.0 - this section needs significant revision to improve
its clarity and grammar. I would suggest the following replacement:
"This specification is intended to describe an industry-standard method to
electronically transport IBIS-like interconnect modeling data between
interconnect design and simulation tools. The following document specifies
a consistent format that can be parsed by software, allowing simulation tool
and interconnect vendors to create models compatible with their own
products.
One goal of this standard is to incorporate the current IBIS format and data
representation while allowing growth to include more complex model
structures and modeling methods. This will be accomplished through
revisions of the base specification and possibly the addition of new
keywords, subparameters and the like.
Another goal of this standard is to ensure that model creation is simple
enough for interconnect vendors, simulation tool vendors and customers to
use, while ensuring rigid enough definitions for simulation tool vendors to
write reliable parsers.
This standard is meant to allow a complete description of the elements of an
entire interconnect. This specification is intended to provide a basis for
future versions, which are expected to be backward compatible with this
initial version."
Note that the word "standard" applies generally to the ICM concept, while
"specification" refers to the specific language and content of ICM at this
revision level.
b) P. 3, Section 3.0, Subsection 2 - The phrase, "Except for keywords (words
enclosed by a square bracket [])..." should be replaced with the phrase,
"Except for keywords (phrases enclosed by a set of square brackets [])..."
c) P. 11, under "Unmated_side_A" - the text which reads, "that is attached
to a baseboard, or the socket which holds the socket of an IC" should be
changed to, "that is attached to a baseboard, or the socket which holds the
package of an IC."
- Michael Mirmak
Intel Corp.
michael.mirmak@intel.com
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Mon Sep 30 2002 - 14:34:55 PDT