[ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 20 Aug 2012 16:12:02 +0000

Walter,

We are talking about two different questions here.


1)  Whether or not to put data and instructions behind

commented lines in an otherwise compliant model file

in general

2)  Whether or not to add x-y coordinates to the IBIS v6.0

specification



I don't think I will change my position on the first

question any time soon.  On the other hand, while my

current position is that x-y coordinates don't belong

in the IBIS specification, I am not opposed at anyone

writing a BIRD on the subject and have discussions on

it to see whether our majority agrees with approving

it for an upcoming version of the specification.



Thanks,



Arpad

==========================================================



From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, August 20, 2012 10:53 AM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling

Arpad,

As I suggested:

"If you would prefer to add "MCP" data to the IBIS 6.0 specification, I suggest 
you submit a BIRD to that affect."

I point out that you strongly objected to adding x-y coordinates of Pins and 
Die pads. If IBIS chooses not to support the BIRD I suggested, then what other 
choices does Sigrity/Cadence have?

Walter


From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Muranyi, Arpad
Sent: Monday, August 20, 2012 11:46 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling

Walter,

Regarding:

"I would suggest for these advanced applications to not complicate IBIS, but 
recommend that you add an "MCP" section within IBIS using the same technique of 
adding "MCP" records using the native IBIS comment character "|", similar to 
the way you add "MCP" records to the SPICE subckts using the SPICE comment 
character "*"."

I disagree as strongly as you can imagine...

Putting modeling data, instructions, etc... behind comments
in an otherwise IBIS or SPICE compliant file defeats the
purpose of having a standard.  Using this technique, any
vendor could develop their proprietary tools and models which
only work in that specific tool, and they wouldn't even be
obligated to explain to the rest of the world what all this
is about.  And claiming that the models are IBIS compliant
because they pass the parser is a rootless advertisement lie,
because the model really works as designed in a specific tool
that understands the commented features.

I would discourage anyone from using these practices.

Thanks,

Arpad
==============================================================


From: Walter Katz [mailto:wkatz@xxxxxxxxxx]<mailto:[mailto:wkatz@xxxxxxxxxx]>
Sent: Monday, August 20, 2012 9:31 AM
To: kenw@xxxxxxxxxxx<mailto:kenw@xxxxxxxxxxx>; Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling

Ken,

I generally agree with your comments on how some very advanced users are 
generating package and on-die models. The question is where to put the "MCP". 
The IBIS approach, and the approach that supports most IBIS users is to put the 
"MCP" inside of the IBIS file. For the advanced user who has access to the 
package and die layout it is very convenient to put the "MCP" inside the subckt 
that the package layout and IC layout tool generates - as you do in your flows.

It would be very convenient for your flows to have the x-y coordinate of the 
package pins and die pads in the IBIS file. I would suggest for these advanced 
applications to not complicate IBIS, but recommend that you add an "MCP" 
section within IBIS using the same technique of adding "MCP" records using the 
native IBIS comment character "|", similar to the way you add "MCP" records to 
the SPICE subckts using the SPICE comment character "*".

If you would prefer to add "MCP" data to the IBIS 6.0 specification, I suggest 
you submit a BIRD to that affect.

Walter

From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Ken Willis
Sent: Monday, August 20, 2012 10:16 AM
To: Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>; IBIS-ATM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling

Hi Arpad and Greg,

Good discussion on the package modeling. Just a quick look back on the topic 
... when the IBIS package modeling initially came out, there were a lot of 
off-the-shelf packages and everybody was looking at basically lumped per-pin 
parasitics. Putting together a syntax to cover that was fairly straightforward.

It is a big contrast to what is going on now, with so many huge, custom, flip 
chip packages. Multiple die, wirebond and flip-chip, interposers, etc. The 
advanced packages are much more like mini-PCBs than the original packages IBIS 
covered. There is all kinds of coupling to include, ex. via-via, 
wirebond-trace, etc. And if you want to do power-aware simulations, that means 
you have to include the package PDS, which adds more elements and ports and 
complexity. And not only that, but you really have to include the on-chips PDS 
then too, and be able to hook it up to the package and IO drivers/receivers. 
That brings yet another level of modeling to the picture.

Looking at these kinds of challenges, it appears unlikely to me that we will be 
able to spec our way out of it with new syntax in EBD or other approaches. All 
of these kinds of things are done today with Spice subcircuits (including 
incorporation of sparams). So leveraging regular Spice syntax (through ISS), 
and not inventing new syntax, makes sense to me. I don't think any of that 
wheel needs re-inventing.

Once you have the subcircuits, the challenge then becomes hooking them up 
properly in a full topology. We need some intelligence in the subcircuits that 
helps users hook them up, and also enables automation to occur in EDA tools. In 
the Sigrity flow, this was done by just putting a simple MCP (Model Connection 
Protocol) header into the Spice subcircuits as comments. MCP has been offered 
to the IBIS standard more than once, I think we should consider it in these 
discussions. This kind of simple augmentation, together with the well-defined 
Spice syntax that has worked for decades, would be very powerful if 
standardized in IBIS.

thanks,

Ken Willis
Cadence Design Systems
980-245-7595

________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> 
[ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad 
[Arpad_Muranyi@xxxxxxxxxx]
Sent: Thursday, August 16, 2012 6:57 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
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:[mailto:gedlund@xxxxxxxxxx]>
Sent: Thursday, August 16, 2012 12:59 PM
To: Muranyi, Arpad
Cc: IBIS-ATM; 
ibis-macro-bounce@xxxxxxxxxxxxx<mailto: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" 
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Date: 08/16/2012 09:17 AM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx<mailto: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/ 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]
Sent: Thursday, August 16, 2012 8:46 AM
To: Muranyi, Arpad
Cc: IBIS-ATM; 
ibis-macro-bounce@xxxxxxxxxxxxx<mailto: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" 
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>>
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Date: 08/15/2012 10:47 AM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx<mailto: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: 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: wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>; IBIS-ATM; 
ibis-macro-bounce@xxxxxxxxxxxxx<mailto: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" <wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>>
To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>>
Date: 08/14/2012 04:24 PM
Subject: [ibis-macro] Straw Poll vote on IBIS-ISS Package Modeling
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx<mailto: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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156

GIF image

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 08-2012