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

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: gedlund@xxxxxxxxxx
  • Date: Fri, 17 Aug 2012 12:07:55 -0400

Greg

I'd have to disagree about crosstalk in packages for serial links.  Based
on my measurements, simulations, and optimizations of organic wirebond,
organic multi-layer buildup, and ceramic multi-layer buildup packaging,
 Crosstalk is hardly insignificant or swamped out by package losses.  Today
I routinely see 16 Gbps+ packaging, and my customers are in design on 20 to
32 Gbps production devices, in both organic and ceramic technologies.
 Typical differential trace losses in multi-layer buildup packages is on
the order of 0.1 dB/mm at 10GHz, or 1 dB for a 10 mm long trace, which is
not unreasonable. Ceramic differential trace loss is about 60% lower, at
about 0.4 dB per 10 mm.  This is not what I call "high loss" that swamps
out crosstalk.  In my experience, the loss that most people report for
packages occurs in the bump via and ball via fields, due to impedance
mismatch, and cavity injection, which is directly correlated to near and
far end crosstalk between the vias.  A significant amount of energy is lost
in these cavity transitions.

As a result, we often model complete ball and via fields encompassing up to
8 differential pairs in an s32p file.

Without this kind of detailed crosstalk modeling, you can pretty much give
up any sort of accurate Serdes link modeling with IBIS AMI.  Everything
that you don't model is what breaks the links. An s4p link model is only
sufficient for a long lossy link simulation if, and only if, Tx and Rx
channels have better than -45 dB isolation within the package.  This is
extremely difficult to achieve.


Scott




On Fri, Aug 17, 2012 at 11:37 AM, Gregory R Edlund <gedlund@xxxxxxxxxx>wrote:

> 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
>
>
>
> [image: 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" <Arpad_Muranyi@xxxxxxxxxx>
> To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
> Date: 08/16/2012 05:58 PM
>
> Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
> Sent by: 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 <gedlund@xxxxxxxxxx>]
> *
> Sent:* Thursday, August 16, 2012 12:59 PM*
> To:* Muranyi, Arpad*
> Cc:* IBIS-ATM; 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
>
>
>
> [image: 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*<Arpad_Muranyi@xxxxxxxxxx>
> >
> To: IBIS-ATM <*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: *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* <gedlund@xxxxxxxxxx>]
> *
> Sent:* Thursday, August 16, 2012 8:46 AM*
> To:* Muranyi, Arpad*
> Cc:* IBIS-ATM; 
> *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
>
>
>
> [image: 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*<Arpad_Muranyi@xxxxxxxxxx>
> >
> To: IBIS-ATM <*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: *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:* *ibis-macro-bounce@xxxxxxxxxxxxx* <ibis-macro-bounce@xxxxxxxxxxxxx>
>  [*mailto:ibis-macro-bounce@xxxxxxxxxxxxx*<ibis-macro-bounce@xxxxxxxxxxxxx>]
> *On Behalf Of *Gregory R Edlund*
> Sent:* Wednesday, August 15, 2012 10:29 AM*
> To:* *wkatz@xxxxxxxxxx* <wkatz@xxxxxxxxxx>; IBIS-ATM; *
> 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
>
>
>
> [image: 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* <wkatz@xxxxxxxxxx>>
> To: "IBIS-ATM" <*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: *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* <wkatz@xxxxxxxxxx>
> Phone 303.449-2308
> Mobile 303.335-6156
>
>


-- 

Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC

GIF image

Other related posts:

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