[ibis-macro] Making IBIS responsive to the modeling needs of the industry ... new keyword [Specification]
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 2 Dec 2008 13:21:34 -0500
All,
I do not expect to be able to attend an ATM meeting until Dec 15. I read
last weeks minutes and cam up with an idea that might solve many of the
issues that we have been suffering through:
We are all aware of the difficulty of introducing new features to IBIS (e.g.
C_Comp, Derating, Masks, USB rules, JEDEC rules, On Die S-parameters, LTI
Differential Tx and Rx models, .).
I would like to propose a simple solution that I think will solve this
problem by introducing a single new keyword to IBIS "[Specification]". The
format of a [Specification] record is simply:
[Specification] specification_name
[Specification] records can occur in the [Component] section, or [Model]
section. Each component and each model may have multiple [Specification]
records.
A specification_name can either be registered. It is registered by being
placed in an IBIS maintained registry of registered names along with a
specification_name.txt or specification_name.pdf document describing the
specification. If a specification_name is not registered, then the
specification_name.txt or specification_name.pdf needs to be supplied along
with the IBIS file.
I think the following example will explain the usefulness of this concept.
Consider a 667 MegHz, DDR2 memory part with the following models: CLKIN,
ADDCMD, DQ, DQS. The IBIS file might be:
[Model] CLKIN
[Specification] DDR2_667_CLKIN
[Model] ADDCMD
[Specification] DDR2_667_ ADDCMD
[Model] DQ
[Specification] DDR2_667_DQ
[Model] DQS
[Specification] DDR2_667_DQS_diff
The IBIS registry would contain the following entries for DDR2 667MegHz.
There would be other entries for other speed grades, DDR3, DDR4, .
DDR2_667_CLKIN DDR2_667_CLKIN.txt
DDR2_667_ ADDCMD DDR2_667_ ADDCMD.txt
DDR2_667_DQ DDR2_667_DQ.txt
DDR2_667_DQS_diff DDR2_667_DQS_diff.txt
DDR2_667_CLKIN.txt might contain
JEDEC Standard No. 79-2C
Speed grade 667MegHz
Signal CK
This is sufficient information for an EDA tool to create a design kit for
this model. It will be up to the EDA tool to determine how it implements
this in its environment.
Similarly there can be [Specification] for eye masks, on die s-parameters,
"ladder C_comp", . EDA tool vendors can implement solutions to each of these
problems in an appropriate way based on their target market and their tool
capabilities. The key point is that [Specification] allows IC vendors to
document in their IBIS [Model]s the measurement/simulation requirements of
their models without waiting for IBIS to come up with new
keywords/parameters, and allows EDA vendors to address industry standard
measurement rules in a timely manor.
USB, JEDEC, and other industry standard specifications fit naturally into
this scheme. Fancy C_Comp solutions can be more problematic, since the
[Specification] might be ties to a specific simulation methodology or EDA
tool, but it would at least document the solution used by the IC vendor for
their analysis. I would expect that IC vendors will learn to write these
[Specifications] in a way that would be supported by the EDA tools that
their customers use.
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
Other related posts:
