[ibis-macro] Re: Making IBIS responsive to the modeling needs of the industry ... new keyword [Specification]
- From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, "Arpad_Muranyi@xxxxxxxxxx" <Arpad_Muranyi@xxxxxxxxxx>, 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 2 Dec 2008 18:21:29 -0700
Thanks for the discussion on the topic. What was implied earlier should now be
stated -- having each EDA company point to independent include files doesn't
satisfy the reasonable expectation of component vendors and system designers
that the same input file work roughly identically in multiple tools. For
better or worse, format standards like IBIS have a somewhat commoditizing
effect, in that tool behaviors should become similar at the
lowest-common-denominator for any tool that accepts the input format.
An additional implication of keywords and subparameters such as VinH_AC is
that, if a tool supports them, it will do something with them. Unfortunately,
this assumption would disappear for any keyword that points to a separate
EDA-controlled include file. I could not guarantee that files I produce will
work similarly for tools without more rigorous tool-by-tool verification, which
may be prohibitive in terms of time and cost.
Derating and eye masks have indeed been proposed for IBIS in the past.
However, we have tended to start with keyword-based definitions for them. These
proposals tended to get derailed in favor of more ambitious schemes, such as
user-defined measurements, or in an effort to move away from keywords entirely
and toward some other paradigm.
So, if we want to see measurement improvements relatively quickly, we can have
them: we will have to be satisfied with making them very specific,
keyword-based, defined within IBIS and looking very similar to current IBIS,
however. Otherwise, the discussion will again get pulled into how to develop
something more comprehensive and flexible that won't be ready for 3-5 years.
Just my personal opinion...
- MM
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Tuesday, December 02, 2008 5:00 PM
To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Making IBIS responsive to the modeling needs of the
industry ... new keyword [Specification]
Arpad,
We passed around Cape Horne yesterday, and visited the Falkland Islands
(Malvenas) today. Seas surprisingly calm.
I understand your point, but right now IBIS is not being responsive to the
needs of the industry. If we could find a way to quickly implement things like
derating, masks, ... then this idea would not make sense. But DDR2 derating has
been around for 4 years and USB masks have been around for close to that and
IBIS has not been responsive.
For example, SiSoft has implemented all of the DDR2, DDR3 and DDR FB design
rules using |SiSoft IBIS keywords that meet JEDEC DDR rules. For each new part
that has a DDR compliant bus our customers need to include these |SiSoft
records. I expect that Mentor, Cadence, Agilent, Zuken, ... have done something
similar. Each of us has implemented these DDR rules in our own way. By having
records such as "[Specification] DDR2_667_CLKIN" SiSoft can point to our own
private "Include" file that has these DDR rules as we have implemented them.
Other EDA companies can point to their own "Include" files that implement this
specification. As new requirements get specified by Industry Standards Groups
such as JEDEC, all IC vendors need to do is have a standard way of having a
Model point to an industry standard, and this is what I am proposing.
Just look at the confusion we have created by the IBIS implementation of
VinH_AC, which kind-of satisfies the JEDEC measurement rules but in fact does
not because it handles slow and fast corners differently then the JEDEC spec.
(IBIS specifies a typ value and then uses a threshold sensitivity to adjust for
voltage corners, JEDEC specifies values for each of the corners). I think the
IBIS method could make more sense, but customers require that their designs
satisfy the JEDEC spec.
"[Specification]" is one way we can make IBIS responsive to the needs of the
IC/EDA/Customer community.
Does anyone have another approach to solve this problem?
Do we want to solve this problem?
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, December 02, 2008 1:49 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Making IBIS responsive to the modeling needs of the
industry ... new keyword [Specification]
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:
