[ibis-macro] Re: Package and on-die modeling
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 7 Sep 2012 00:57:32 +0000
Greg,
I agree with you, and I actually had the same thoughts
crossing my mind when I wrote my previous message.
But what you point out matters only when the spec addresses
application specific features. A well written general spec
would not run into that problem. Here is an illustration:
The various types of Submodels in IBIS are targeting very
special buffer behaviors. We couldn’t have guessed them
ahead of their time and put them into the spec because they
were treated as secret-sauce features in the buffers by the
circuit designers, and it was even hard to get any information
out of them after the buffers were designed.
But did the same designers have a hard time to model and
simulate the same buffers in SPICE? Not at all, because
SPICE is a more general purpose modeling/simulation
environment. We could say that the people who wrote the
SPICE specification were thinking way ahead of their time
and wrote a specification that worked in the future.
That’s what I was trying suggest in my previous message.
Thanks,
Arpad
=============================================================
From: Gregory R Edlund [mailto:gedlund@xxxxxxxxxx]
Sent: Thursday, September 06, 2012 1:43 PM
To: Muranyi, Arpad
Cc: IBIS-ATM; ibis-macro-bounce@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: Package and on-die modeling
Arpad,
"Also, I am not sure I like the idea of waiting for IC vendors
to give us an indication for a certain need before we start
discussing how that need could be supported in the specification."
It's always a good idea to look down the road. However, if our work as a
committee is not customer driven, then we may look back a year from now and
find that we did a lot of work on something that only one or two people decided
to use. I'm reminded of my own work on accuracy at a time when users were
struggling to get models to run at all.
What I hope we can do is quickly come up with a list of the top two or three
big ticket items that people are really clamoring for and then develop a set of
actions and milestones to tackle them. How can we generate that list?
Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N Bldg 050-3
Rochester, MN 55901
[Inactive hide details for "Muranyi, Arpad" ---09/06/2012 10:00:47 AM---While I
like the idea of a structured plan, I am not sur]"Muranyi, Arpad" ---09/06/2012
10:00:47 AM---While I like the idea of a structured plan, I am not sure I agree
with the content of the plan below
From: "Muranyi, Arpad"
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Date: 09/06/2012 10:00 AM
Subject: [ibis-macro] Re: Package and on-die modeling
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
________________________________
While I like the idea of a structured plan, I am not sure
I agree with the content of the plan below.
The problem I see here is what I mentioned many times before.
The plan below is based on specific features and sub-features,
when a single syntax could support everything. I feel we are
boxing ourselves in by addressing features and usage models
one at the time.
All we need is a specification that allows the user to define,
instantiate and connect their interconnect models. Whether
they are representing a signal trace or power, coupled or
uncoupled traces, or on-die vs. package parasitics is
irrelevant. It is only an interconnect no matter what it
represents. We just need to provide a spec that allows the
user to define it, instantiate it, and connect it. Let them
decide what the purpose of it is…
Also, I am not sure I like the idea of waiting for IC vendors
to give us an indication for a certain need before we start
discussing how that need could be supported in the specification.
There is usually a huge delay between the time we start discussing
a need and when it becomes available officially in the specification.
In the meantime we end up having “non-compliant” solutions and
models and then the discussions in the IBIS meeting start going
along the lines of “everyone does it this way, so we have to
do it this way in the specification”. In reality, what people
might be doing could be just a “make shift” solution, based on
whatever happens to be tweakable in a certain tool, using all
kinds of forgeries and band aids to get it to work, but we end up
putting these “ill-conceived” practices into the specification
because “everyone is doing it this way”. I don’t think this is
the best way of writing a specification…
Thanks,
Arpad
=====================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, September 05, 2012 2:09 PM
To: IBIS-ATM
Subject: [ibis-macro] Package and on-die modeling
All,
I would like to propose the following specific package and on-die modeling plan:
IBIS 6.0
Support only On-Die Tstonefile (s2p and s4p) interconnect models using the
[Model] sub parameters [Tstonefile] and [Tstonefile Ports].
Support package IBIS-ISS subckts as a .ipkg file which would be in Parameter
Tree format.
IBIS 7.0
Support On-Die IBIS-ISS subckts as a .idie file, similar to the .ipkg file but
between pads and buffers instead of between pins and pads.
IBIS 7.0
Create a new EMD standard
IBIS 8.0
Create a new IBISx format (.ibsx) which is .ibs in Parameter Tree format
I would defer any work on IBIS-BSS until IC Vendors make a specific request for
such functionality. Again, we need to be driven by IC Vendors desire and
ability to supply buffer models in such a modified SPICE syntax. I point out
that IBIS-AMI modeling was driven by two IC Vendors.
I make the recommendation for IBIS 6.0 because IC Vendors are only delivering
On-Die Tstonefile (s2p and s4p) interconnect models today. We should not create
an On-Die IBIS-ISS standard until we get definitive requirements from IC
Vendors. We now know the requirements for On-Die Tstonefile (s2p and s4p). If
IC Vendors do give compelling reasons to implement On-Die IBIS-ISS subckts we
can consider moving the implementation to IBIS 6.0, since much of the basic
work will be done in the implementation of package IBIS-ISS subckts as a .ipkg
file.
I recommend doing the IBIS-ISS package model in .ipkg Parameter Tree format
because
1. It is easily to parse
2. It is easily extensible
3. It satisfies all known requirements for package models currently being
delivered
4. It will slide into the new EMD standard with minimal effort
Most of the issues raise about my presentation Tuesday were on EMD and .ibsx,
since these are deferred, and once I have implemented examples with additions
IC Vendor supplied package models the syntax of the .ipkg file can refined and
ready to be reviewed in detail and documented in a BIRD.
Walter
Walter Katz
wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
