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

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <gedlund@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>, <ibis-macro-bounce@xxxxxxxxxxxxx>
  • Date: Wed, 15 Aug 2012 11:46:12 -0400 (EDT)

Greg,



Agreed, IBIS 5.1 is schedules for a vote in the next Open Forum. As soon as 
IBIS 5.1 is approved, and the template for making BIRDs against IBIS 5.1 is 
approved, I will reformat the Jitter BIRD (123). BIRD 123 has been agreed to 
by IBIS-ATM, and is waiting for a rewrite in IBIS 5.1 format which will be 
taken up next in the Open Forum.



Walter



From: ibis-macro-bounce@xxxxxxxxxxxxx 
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Gregory R Edlund
Sent: Wednesday, August 15, 2012 11:29 AM
To: wkatz@xxxxxxxxxx; IBIS-ATM; 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>
To: "IBIS-ATM" <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

  _____



[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

GIF image

Other related posts:

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