[ibis-macro] Re: Making IBIS responsive to the modeling needs of the industry ... new keyword [Specification]
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 2 Dec 2008 10:49:28 -0800
Walter,
In general, this [Specification] proposal looks very much like
IBIS-AMI, adding one simple keyword to IBIS and do the rest outside.
In the case of AMI, we wrote a whole new specification to describe
what AMI actually is, describing parameters, the format of the
parameter files, etc... I feel we will need to do the same in
this case too. Otherwise how would a tool know how to parse the
content of the file that [Specification] points to.
So while this seems to be an easy fix in the IBIS specification,
I don't see any reduction of work, because somewhere it must be
defined what the file contains and what its syntax is. Or did I
miss something?
Another topic: This proposal is yet another example, where we are
diverting things from the IBIS specification to some other, external
file or specification. If we keep this trend up, there will be
nothing left in IBIS itself, except a bunch of pointers. This
makes me wonder again about the conversation we are doing on the
overhauling of IBIS... Any comments?
Thanks,
Arpad
=====================================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, December 02, 2008 12:22 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Making IBIS responsive to the modeling needs of
the industry ... new keyword [Specification]
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:
