[ibis-macro] Re: Yes, we can afford to automate package model connection given the limited resources of everyone on the committee!
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'Gregory R Edlund'" <gedlund@xxxxxxxxxx>
- Date: Fri, 17 Aug 2012 13:02:59 -0400 (EDT)
Greg,
Of course. But we have to get our story right first. Although IBIS-ATM has
been EDA company centric, both SiSoft and Sigrity have extensive experience
developing tools and models to support package and on-die interconnect an
power delivery, and both SiSoft and Teraspeed have extensive consulting
experience in this area as well. In addition, a number of IC Vendors have
been active in the recent discussions on package and on-die modeling.
Walter
From: Gregory R Edlund [mailto:gedlund@xxxxxxxxxx]
Sent: Friday, August 17, 2012 12:43 PM
To: wkatz@xxxxxxxxxx
Cc: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'; ibis-macro-bounce@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Yes, we can afford to automate package model
connection given the limited resources of everyone on the committee!
Walter,
"The IBIS-ATM committee should accept the syntax I have proposed..."
It's a good effort, but not the only one. Given that the IBIS Open Forum is
a democratic organization where we try to consider equally the needs of all
parties (including non-members who are the end customers of our product, the
ever-evolving spec), I propose that we hear directly from some of those
customers about what they think their needs are and which ones are most
important to them. Since we don't have many users on the weekly calls, we
could solicit input from the SI List and even invite some of the respondents
to attend one of the calls to make their voices heard. I'd be willing to
organize that.
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 "Walter Katz" ---08/17/2012 10:55:16 AM---Greg,
The answer to your question “can we afford to automa"Walter
Katz" ---08/17/2012 10:55:16 AM---Greg, The answer to your question “can we
afford to automate package model
From: "Walter Katz" <wkatz@xxxxxxxxxx>
To: Gregory R Edlund/Rochester/IBM@IBMUS, <Arpad_Muranyi@xxxxxxxxxx>
Cc: "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
Date: 08/17/2012 10:55 AM
Subject: [ibis-macro] Yes, we can afford to automate package model
connection given the limited resources of everyone on the committee!
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx
_____
Greg,
The answer to your question “can we afford to automate package model
connection given the limited resources of everyone on the committee?” is
Yes.
The IBIS-ATM committee should accept the syntax I have proposed in the last
two IBIS-ATM meetings (to be summarized succinctly in the next IBIS-ATM
meeting). The syntax is simple, addresses exactly the functionality you
require as well as the functionality requested by all of the IC Vendors in
the committee, and our IC Vendors partners. It will take some effort to
write the BIRD to document the syntax and various usage models, but if you
review the syntax and examples in the presentations I plan for the next
meeting it will become evident that completing the BIRD should be
straightforward.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Gregory R Edlund
Sent: Friday, August 17, 2012 11:37 AM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM; ibis-macro-bounce@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Arpad,
"Like I said before, if I am completely off the wall, let me
know and I will shut up do something else..."
Ha ha! I think we may all be off the wall after working on IBIS for so
long!
To automate, or not to automate. That is the question. Yes, I think that's
it in a nutshell. Or at least, can we afford to automate package model
connection given the limited resources of everyone on the committee?
Let's do a gedanken experiment and imagine that an asteroid fell on each of
our houses while we were sleeping. What would the users and semiconductor
vendors do without a package model spec? For simplicity of discussion,
let's also assume that all chip vendors agree to supply Touchstone models
for each package pin. For any given chip, they'll probably make one or two
.s2p files for the slow pins (short and long, maybe). Then they'll create
two more .s4p file for the differential pins. And if someone like IBM is
nagging them for three significant digits, they'll make a .s12p file to
model crosstalk, which is probably swamped out by losses in a well-designed
package. The user will have to figure out how to read a Touchstone file
into the schematic and hook up 2, 4, or 12 terminals to the corresponding
IBIS models and channel. Now for completeness, imagine replacing the
Touchstone file with an ISS subcircuit.
Maybe I'm simplifying things too much. I have that tendency. I haven't
addressed the topic of power distribution modeling, for instance, which
requires a boat load of complexity and is probably best suited for automated
extraction tools which we're not addressing anyhow.
Thanks for taking the time to bat this back and forth. It's really healthy
for all of us to think about it.
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" ---08/16/2012 05:58:45 PM---Greg,
You raise pretty good questions. Here is the way "Muranyi,
Arpad" ---08/16/2012 05:58:45 PM---Greg, You raise pretty good questions.
Here is the way I see the
From: "Muranyi, Arpad" < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>
To: IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>
Date: 08/16/2012 05:58 PM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Sent by: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx
_____
Greg,
You raise pretty good questions. Here is the way I see the
situation.
Yes, essentially the discussion revolves mostly around how
to write the new IBIS package modeling specification which
basically consists of instantiating the IBIS-ISS subcircuits
and/or the Touchstone files and connecting these with the
terminals of the IBIS [Model]s, die pads, and device pins.
In short, instantiation and connection, i.e. netlisting.
The reason I am so vocal about developing a general purpose
syntax that covers all situations is to avoid: “to take a lot
of effort and time to ferret out all the permutations and contingencies”.
My
favorite example is SPICE, they didn’t invent many different
syntaxes of instantiating resistors, inductors and capacitors
and all of their permutations, they just defined
ElementName n+ n- value
and it works miraculously for all of these elements in all
possible combinations.
Regarding whether it makes sense for us to spend the time to
develop a specification like that, I see it this way:
Given a specification, the model maker can write the models,
instantiate them and connect them, all in the .ibs and .pkg
files. Do it once, and it works in all EDA tools, for all
users. What you are suggesting is the opposite. The model
maker just writes a model any whichever way they feel like it,
toss it over to the users, and every single user will have to
figure out how to instantiate and connect them. Add to that
that not all users might have the expertise to do this, and
different EDA tools might need this done in different ways.
Now we multiplied the amount of work needed to be done by
the number of users and possible the number of EDA tools.
Even the model makers might have to put in more time to
help their less experienced customers, so they might end
up having to work on this together with (several of) their
customers.
So the model maker will do more customer support, and all the
customers will spend a lot of their time on fiddling with the
models to get them to run. This is a very good way to make the
design time of every new product longer. Also, this does not
go together very well with the last letter of the acronym “EDA”.
Why shouldn’t we apply a little factoring and let the model
maker do this once, and let the users plug and play with
designing their products, instead of wrestling with the
models?
Like I said before, if I am completely off the wall, let me
know and I will shut up do something else...
Thanks,
Arpad
==============================================================
From: Gregory R Edlund [ <mailto:gedlund@xxxxxxxxxx>
mailto:gedlund@xxxxxxxxxx]
Sent: Thursday, August 16, 2012 12:59 PM
To: Muranyi, Arpad
Cc: IBIS-ATM; <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Arpad,
If I understand the proposals on the table, the main thing we're trying to
accomplish with the new package syntax is instructing the EDA tool in how to
connect the ISS or Touchstone package model. Correct me if I misunderstand.
It's going to take a lot of effort and time to ferret out all the
permutations and contingencies. I'm questioning which option is more
painful: spending the effort and time or connecting the package model
manually.
We will always get a wide variety of package models that depend on personal
preferences, what they're trying to model, etc. If people stay within the
ISS and Touchstone specs and document what they've done, we should be OK. I
want to stress the word document. As a model user, I will always want to
know about the internal structure of the model, what tools were used to
generate it, under what conditions it is valid, etc. That means I will
always need a PDF file to accompany the model. May as well tell me how to
hook it up at the same time. As I see it, this is really a model quality
issue.
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" ---08/16/2012 09:17:19 AM---Greg,
Thanks for your comments again. Certainly, we cou"Muranyi,
Arpad" ---08/16/2012 09:17:19 AM---Greg, Thanks for your comments again.
Certainly, we could do
From: "Muranyi, Arpad" < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>
To: IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>
Date: 08/16/2012 09:17 AM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Sent by: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx
_____
Greg,
Thanks for your comments again. Certainly, we could do
a survey on what people think we should spend our time
on. But we need to make a good list then that people
could prioritize with numbers. Some of that list could
come from the agenda I send out every week for the ATM
meetings, because I have a few topics listed there which
are ahead of us, but we don’t get to discuss in the meetings
because we take the ones which are on the top of the list.
But regarding the package improvements question, at its
current state, the package modeling in the IBIS specification
is pretty much useless. If we don’t do anything about it, we
can pretty much say goodbye to anyone using it for anything
useful. That means that you will get package models in all
kinds of different shapes and form, and you will constantly
have to tailor them to the tool you happen to be using for
any given project.
If you looked at the BIRDs list on the IBIS website:
<http://www.eda.org/pub/ibis/birds/> http://www.eda.org/pub/ibis/birds/ and
searched for “package”,
you will see that the last BIRD was 64.4 in year 2000 adding
the [Alternate Package Model] keyword to the spec, and before
that we had BIRD 54 in 1998 with some corrections, and before
that we had BIRD 37.3 and 28.3 with some enhancements in years
1996 and 1996. This means that the last time we enhanced the
package modeling syntax in IBIS was over 16 years ago! To me
this alone is an indication that we should put a high priority
on upgrading the package modeling capabilities in IBIS, but
this is with the assumption that we want to have a standard
for it. If people don’t want to have a modeling standard for
package modeling, we might as well drop the discussions today
and spend our time on other topics.
Thanks,
Arpad
=================================================================
From: Gregory R Edlund [ <mailto:gedlund@xxxxxxxxxx>
mailto:gedlund@xxxxxxxxxx]
Sent: Thursday, August 16, 2012 8:46 AM
To: Muranyi, Arpad
Cc: IBIS-ATM; <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Arpad,
In addition to the actual model, I expect to get a document from the
supplier explaining how to use the model. The automation is not a high
priority for me because it's not labor-intensive. Getting the model to run
at all is definitely a high priority, and my EDA suppliers are saying they
have very little diagnostic information when a model crashes. If the model
developer didn't use the same tool I'm using, that means I'm pretty much
stuck in the middle. Neither the EDA supplier nor the model supplier can
help me debug the problem.
Since we all have limited resources, I would like to see us prioritize our
work items. The package extension has the potential to generate a lot of
traffic and consume many weekly calls. Is it the thing that will best help
advance the state of IBIS AMI in 2012? Is there some way we can survey the
users to find out what their highest priorities are?
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" ---08/15/2012 10:47:46 AM---Greg,
Thanks for your comments. Like you, I would like "Muranyi,
Arpad" ---08/15/2012 10:47:46 AM---Greg, Thanks for your comments. Like
you, I would like to see
From: "Muranyi, Arpad" < <mailto:Arpad_Muranyi@xxxxxxxxxx>
Arpad_Muranyi@xxxxxxxxxx>
To: IBIS-ATM < <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>
Date: 08/15/2012 10:47 AM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Sent by: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx
_____
Greg,
Thanks for your comments. Like you, I would like to see
more comments from other users too.
But to answer your question, “along with a document saying "use this model
for these pins"”
is what we would like to make the .ibs and/or .pkg file
to do for you (based on a standardized specification),
so that you won’t have to do it by hand. Does that make
sense?
As an illustration I would say that we want to make a
specification which allows model vendors to send you a
machine readable netlist instead of a Word document
that describes what the circuit looks like…
Thanks,
Arpad
==========================================================
From: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx [ <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Gregory R Edlund
Sent: Wednesday, August 15, 2012 10:29 AM
To: <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx; IBIS-ATM;
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> ibis-macro-bounce@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Here's one user's perspective:
I'm happy getting .s4p files from my chip suppliers along with a document
saying "use this model for these pins" (among other things). And if
coupling is worth simulating, then I'm happy with an .s12p file. I can get
along without a CAD file to tell me how to hook up the s-parameters in the
EDA tool. Or is there something else going on that I'm not seeing?
To me, it seems like there are bigger fish to fry, e.g. getting IBIS 5.1 out
the door, jitter modeling, error reporting when a DLL crashes, etc.
Any other users care to weigh in?
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 "Walter Katz" ---08/14/2012 04:24:02
PM---[attachment "IBIS_ISS_Package_Modeling_120807.pdf" deleted "Walter
Katz" ---08/14/2012 04:24:02 PM---[attachment
"IBIS_ISS_Package_Modeling_120807.pdf" deleted by Gregory R
Edlund/Rochester/IBM] [atta
From: "Walter Katz" < <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx>
To: "IBIS-ATM" < <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>
Date: 08/14/2012 04:24 PM
Subject: [ibis-macro] Straw Poll vote on IBIS-ISS Package Modeling
Sent by: <mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
ibis-macro-bounce@xxxxxxxxxxxxx
_____
[attachment "IBIS_ISS_Package_Modeling_120807.pdf" deleted by Gregory R
Edlund/Rochester/IBM]
[attachment "IBIS_ISS_Package_Modeling_Discussion_1_120814.pdf" deleted by
Gregory R Edlund/Rochester/IBM]
[attachment "PackageFunctionalityStrawPoll.xlsx" deleted by Gregory R
Edlund/Rochester/IBM]
All,
I have put 28 questions in a spreadsheet. I think it will take too much time
to do the voting in the meeting, so I request that you put entries 1:4 in
column 1 of each question. The meanings of 1:4 are.
4
Advocate I need this!
3
Support I support this
2
Abstain I have no opinion
1
Object I object to this functionality
Return them to me or all IBIS-ATM and I will collate the results and publish
them by Tuesday AM. I am including the .xlsx file in case you have
difficulty editing the spreadsheet in the body of this e-mail. Also
including this and last weeks presentation.
Walter
4
Advocate I need this!
3
Support I support this
2
Abstain I have no opinion
1
Object I object to this functionality
Should we add keywords Pullup_Signal_name, Pulldown_Signal_name,
Power_clamp_Signal_name, and Ground_clamp_Signal_name to the [Model]
section?
Should we add a section to the .ibs file to define the voltage values of
supply signal names?
Should we add a list of supply die pad names?
Should we add an x-y coordinate for each pin and die pad?
Should we support two signal pins connected to the same die pad (Forked
Signal)?
Should we be able to associate a package model with a [Model]?
Should we be able to associate a package model with a Pin_name?
Should we be able to associate a coupled package model with a [Model]?
Should we be able to associate a coupled package model with a list of
Pin_names?
Should we support package models with coupling between signals and power?
Should we support a coupled package model that hooks up to two or more
[Model] names?
Should we support package models with more than 3 corners?
Should we support package Touchstone files directly?
Should we support sparse usage of large package Touchstone files?
Should we support package “Quadrants” (e.g. Banks, Interfaces)?
Should we support full package models?
Should we support on-die models?
Should we be able to associate an on-die model with a [Model]?
Should we be able to associate an on-die model with a Pin_name?
Should we be able to associate a coupled on-die model with a [Model]?
Should we be able to associate a coupled on-die model with a list of
Pin_names?
Should we support on-die models with coupling between signals and power?
Should we support a coupled on-die model that hooks up to two or more
[Model] names?
Should we support on-die models with more than 3 corners?
Should we support on-die Touchstone files directly?
Should we support sparse usage of large on-die Touchstone files?
Should we support on-die “Quadrants” (e.g. Banks, Interfaces)?
Should we support full on-die models?
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
Other related posts:
