Walter, This seems like a reasonable, incremental approach to me -- one that would be consistent with Michael Mirmak's presentation at DesignCon on the topic of a regular release schedule. I do think we can tackle IBIS 6.0 in a six month period if we quickly converge on an approach. We may need some additional break-out calls. Would a face-to-face meeting help get the effort off the ground? It's about time for the famous Boston fall colors. For that matter, Minnesota is a central location, and we probably have another month until the first blizzard hits! 8-) Greg Edlund Senior Engineer Signal Integrity and System Timing IBM Systems & Technology Group 3605 Hwy. 52 N Bldg 050-3 Rochester, MN 55901 From: "Walter Katz" <wkatz@xxxxxxxxxx> To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx> Date: 09/05/2012 02:11 PM Subject: [ibis-macro] Package and on-die modeling Sent by: ibis-macro-bounce@xxxxxxxxxxxxx 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 Phone 303.449-2308 Mobile 303.335-6156