[ibis-macro] Re: Making IBIS responsive to the modeling needs of the industry ... new keyword [Specification]
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 5 Dec 2008 11:43:09 -0500
Arpad,
I cannot disagree with you more. The external specifications I am pointing
to are Industry Standards (E.G. JEDEC, USB, and yes Hspice!).
When JEDEC specs DDR2 or DDR3, they are defining a set of measurement rules
that parts must comply with in order to have the JEDEC stamp of approval.
When a systems house designs a board using DDR2 or DDR3 components, and if
their simulations satisfy the JEDEC rules for DDR2/DDR3, then they can be
assured that their board will work with any qualified DDR2/DDR3 component.
So Having an IBIS part that has a model that is DDR2 or DDR3 qualified means
that that part will work as long as the simulation satisfy the JEDEC
DDR2/DDR3 rules.
What customers want are IBIS models that they can use in EDA tools that will
tell them if the simulations satisfy those JEDEC requirements. There is no
way of putting these JEDEC requirements into IBIS files today. Derating is
one example of a JEDEC rule, but there are others relating to AC, DC levels,
slew rates, how slew rates are measured, how long signals need to stay above
AC levels, . All I was saying is that IBIS needs to adapt these Industry
Standard Rules in a timely fashion either by aggressively adding measurement
parameters and keywords to IBIS, or by at least having a standard way of
pointing to Industry Standards.
IBIS has several functions, one as a pin list and assignment of models to
pins, one as an analog description of how drivers and receivers interact
with a channel, and one as a method of analyzing the signal at a receiver to
determine timing information. There are two philosophies of determining
timing information, one is to replicate the timing path inside an Rx as
accurately as possible, the second is to replicate the timing rules that
standards committees set on the requirements of chip manufactures to meet
timing steps for that standards committee's specifications.
You missed my entire point with your comment "your tool is still not going
to be able to use my eye opening description and my tool is not going to be
able to use yours.". What I said is that the [Specification] would point to
an Industry Standard Rule, not mine and not yours. I then said that each EDA
tool can implement this Industry Standard Rule in its own way. The external
file I described was just a way of describing the details of the Industry
Standard Rule. This file gets read by a human who decides on an
implementation of that rule for his EDA tool.
I think that you will find that many IBIS enhancement requests for new
keywords are simply desires to add the ability to specify industry standard
rules in IBIS.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, December 05, 2008 10:45 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Making IBIS responsive to the modeling needs of
the industry ... new keyword [Specification]
Walter,
I am not disputing the issues that there are lots of things out
there which IBIS hasn't addressed, and that EDA vendors have
developed their own way of shoehorning things into IBIS files
with proprietary methods.
But your reply doesn't answer my question. True, a new keyword
like [Specification] would help in making those proprietary
solutions official, but without describing what the content
and format of the file that it points to would not remove the
incompatibility problem, because these files would still not
be exchangeable between tools.
If my file describes the same eye opening diamond with a totally
different syntax as yours, we both may have an identical IBIS
file with the [Specification] keyword in it, but your tool is
still not going to be able to use my eye opening description and my
tool is not going to be able to use yours. This could be made to
work only if we wrote a spec for the eye opening description so
that the same file to which [Specification] points to could be
read by all EDA tools. I don't see how this [Specification]
keyword would be useful otherwise. But if we end up having to
write a specification for what goes into those external files,
I wonder why we need to go with external files at all? What is
the benefit of removing these things from the IBIS specification?
Relating to the subject line of this message, I agree we need to
do something to be responsive to the industry needs, but I don't
think that removing everything from the IBIS specification into
unspecified external files is the solution, unless we want to kill
IBIS completely and go our separate ways. We are starting to have
way too many proposals which go in this direction. The EMD proposal
suggests to put everything into external subcircuits without really
describing what the syntax of that subcircuit is (unless we end up
saying that it shall use the Interconnect-SPICE and nothing else).
There were similar suggestions in the C_comp discussions (final
stage subcircuit). This [Specification] keyword proposes another
external file without defining its format. IBIS-AMI does everything
outside the IBIS file also, but at least that one does define fairly
rigorously how the external files should interface with IBIS. (We
could even add *-AMS, ICM, PGK to this list if we want to be really
picky about how things started to be taken out of IBIS).
I am beginning to wonder, what the true motivations are behind these
recent suggestions. Do we want to make an empty egg-shell out of IBIS
that is pretty much useless for anything other than a nice display on a
shelf somewhere? Do we want every EDA tool to have their own
incompatible file formats again? If so, let's just close up shop
and say IBIS no longer exists. If not, let's try to find a more
standardized way to solve these problems.
Part of the problem is that all along the IBIS history we kept resorting
to minimalist changes, pushing off the real solutions to a later time.
These things have a tendency to accumulate and the longer we do this,
the bigger the problem-pile tends to get. When the pile gets too large
we either have to bite the bullet, take a big breath and start over, or
let the pile collapse under its own weight and leave it there. I feel
this is the situation we are approaching. The proposals we are discussing
give me the impression of putting explosives into the pile and spread it
by explosions. The original pile may reduce in size or disappear, but
the result is a bunch of new smaller piles. These may turn into big
piles of their own at a later time if we are not make drastic changes
in how they are architected.
Arpad
=========================================================================
_____
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Tuesday, December 02, 2008 7:00 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [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:
