[ibis-macro] Re: My recommended course of action for IBIS
- From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 20 Jan 2009 10:53:54 -0700
Walter (and list),
Thanks for your recommendations (and sorry for the long time taken to respond).
If I may comment, I have a few suggestions of my own, shown below in priority
order:
1) Fix the package format
2) Fix the package format
3) Fix the package format
Did I mention fixing the package format? :)
4) Add differential measurements, in the style of current IBIS
My reasoning: we need to address the areas where IBIS is actually weaker than
proprietary alternatives AND weaker than what the industry requires. Lossless,
uncoupled packages are no longer suitable and haven't been for some time.
Similarly, with so many interfaces being SerDes, not having eye masks and
similar measurements makes IBIS antiquated.
In general, I understand the resistance to deprecating parts of the existing
specification. However, we need to distinguish between:
- features that simply aren't used very much
- structures and assumptions that actually limit or prohibit expansion, or make
improvement very difficult.
Transit Time is my favorite example of the first type. We don't need to spend
time removing it from the specification, even if no one uses it, as its
presence doesn't limit anyone. It also does not interact very much with other
keywords. The lack of explicit, named pads in IBIS is my favorite example of
the second type. The one-to-one pin-to-pad assumption actually makes expansion
of the specification complicated and difficult to understand.
To address this second kind of issue, we would likely have to create an
"IBIS-Lite" specification that is similar but not backward compatible with the
IBIS 5.0 and previous specifications (see below).
My other recommendations are procedural:
5) Let us not make the perfect be the enemy of the good (or, as the CPR classes
say, "imperfect care given is better than perfect care withheld")
In other words, when confronted with a problem, let's not start developing a
comprehensive, far-reaching solution that may never get released when a more
specific, directed solution would do the trick and could be implemented fast.
I believe we may have started down this path twice now, with both package
modeling and with C_comp improvements.
6a) Let's not confuse *format* with *solution* (as may be happening in the SSO
discussion on the SI-List)
6b) We should ban the following phrase from our discussions: "But you can
already do that with the XYZ format/language"
We have gone back and forth on the need for table-driven keywords vs.
languages. We have also talked about the three audiences for IBIS: tool
vendors, IC vendors/designers and system designers. I am realizing that IC
vendors/designers can be split into two camps: those who can or do create
behavioral algorithms for their parts, and those who cannot or do not. For the
latter group, table-based keywords have one enormous advantage over algorithmic
or code-based models: they don't require a lot of knowledge to generate. An IC
vendor doesn't need to actually know how to create a sim algorithm using DC I-V
data to use [Pulldown], [Pullup], etc. They simply need to know the rules of
extracting the data, because the burden of developing the algorithm has already
been taken up by the spec committee and the tool vendors. Code-based models do
indeed enormously increase flexibility, but only for those who know how to
write behavioral models to describe the effects in which they're interested.
In short, creating a format to express a solution is not the same as having the
solution. I would request that we keep that distinction in mind.
- MM
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Tuesday, January 06, 2009 1:07 PM
To: IBIS Macro
Subject: [ibis-macro] My recommended course of action for IBIS
All,
Summary of discussion on my proposed direction for IBIS.
1) Things that could be done quickly with simple new keywords.
2) Major effort, totally new package methodology.
3) and 4) Items that can be done in the Wednesday Interconnect meeting.
5) 6) 7) Probably will not be done.
Walter
1) Implement keywords to address differential and high speed
differential buffers
a. Final Stage Subckt (frequency dependent C_Comp and loss)
b. Differential Termination Subckt (makes IBIS models True differential)
c. Differential Standard Load Subckt
d. Common Mode Voltage
e. Simple N-Tap FIR equalization for Tx models
f. Simple LTI impedance model instead of IV curves
g. Cookbook for generating and using IBIS differential models
h. Implement [Specification] statement to point to industry standard
measurement and timing rules
2) Package models based on IBIS Interconnect Spice
3) Sparse Touchstone Data
4) Touchstone Port Data (wrapper)
5) Deprecate (remove) lots of unused and useless IBIS stuff from the
spec.
6) External Model DLL API
7) Better support for ODT
Other related posts:
