From: Mirmak, Michael Sent: Wednesday, October 10, 2012 6:54 AM To: IBIS-Interconnect (ibis-interconn@freelists.org) Subject: IBIS Interconnect Task Group Oct. 3 Minutes and Oct. 10 Agenda (RESEND) ====================================================================== IBIS INTERCONNECT TASK GROUP MEETING http://www.eda.org/ibis/interconnect_wip/ Mailing list: ibis-interconn@freelists.org ====================================================================== Next meeting: Wednesday, Oct. 10, 8 AM US Pacific Daylight Time Agenda: - Call for Patents - Opens - Topic: Keywords and Structures Interacting with/Restricting Package Improvements o Includes Oct. 3 E-mail from Walter Katz - Progress to Schedule - Next Meeting Logistics and Agenda Teleconference Logistics For international numbers, please contact Michael Mirmak. 916-356-2663, Bridge: 2, Passcode: 862-5431 Join online meeting https://meet.intel.com/michael.mirmak/3RSJGG35 First online meeting? [!OC([1033])!] ====================================================================== Attendees, Oct. 3 Agilent Technologies Radek Biernacki Cadence Design Systems Brad Brim Intel Corp. Michael Mirmak Mentor Graphics Arpad Muranyi Signal Integrity Software Walter Katz Teraspeed Consulting Group Bob Ross Minutes Michael Mirmak called the meeting to order. No patents were declared. During Opens, Walter Katz noted that he had submitted an e-mail for discussion regarding new approaches to bare die, multiple levels of output vs. continuous levels of output and other areas affecting packaging and IBIS generally. These will be part of the discussion on Oct. 10. Michael Mirmak presented “Update, Change or Fork?”, available on-line, detailing options and examples for ways to approach support of package modeling under IBIS. The key question is whether the current IBIS structures are too limiting to permit updating and, if so, whether deprecation of keywords/structures or staring “fresh” with a new specification would be preferable. Brad Brim asked why “useful” was used as a qualifier for package models. Michael noted, in a later slide, that current structures aren’t that relevant to today’s devices; his sense was that the current format is out of date for most users. Walter stated that he very strongly believes that we should only add (not change) keywords, due to existing infrastructure of tools, models and users with IBIS-reading tools. Arpad Muranyi asked about the emphasis on only adding; does this include deprecation? Walter responded that this could be allowed, on a limited basis. In response to Michael’s question on how many models are using today’s intended use of IBIS, Walter noted that he has seen all three, but Michael’s original question was not precise. Industry creates pin-centric and component-centric/hierarchical models. If you don’t have something on a pin, you can have it on the component level. Lowest hierarchy is pin, next is model, next is component. He noted that he has not seen [Pin Mapping] or [External Model] used. As for how many new packages will use old buffer model data: there will be lots of them. Package data might be updated but also on-die interconnect data. If IBIS interconnect support were extended to S- parameters for on-die interconnect, you would still see lots. Bob Ross agreed that adding keywords or starting from scratch are preferred; invalidating/deprecating structures will upset IBIS’s structural balance of maker/user/tool. Bob noted that, in response to Michael’s question on slide 3, he does business with IC vendors who contract him to create models that work with EDA tools, usually in legacy mode. Generally his work doesn‘t support multi-lingual extensions and not many [Pin Mapping] applications; also supports S- parameters. His work has a traditional/legacy modeling approach and believe it important not to destroy this. IBIS is putting modeling back “on the table” as the most important topic for the industry. Sometimes have to downgrade models to make them useful across tools. In contrast to Michael’s presentation, Bob doesn’t distinguish 4.0 from 4.1 from 4.2; his work supports some EBD files as well. Walter clarified that 4.2 comments generally refer to multi-lingual extensions; Arpad agreed that 4.2 means multi-lingual IBIS. Bob continued that he is against forking the specification, as this would be hard for parser development and expensive to update/maintain/correct. Radek Biernacki suggested two possibilities for deprecation. Deprecation may not be syntax/parser- related, but may refer to what is used or not used in a particular version number. A keyword may not be illegal, but it may be ignored. He agreed that smooth parser work is important. Walter observed that deprecation means in the software industry a two-step process: declare certain keywords/sections as “deprecated”, in that some future release the keyword will not be supported but in the current release/parser it is still supported. Walter suggested deprecating, in this specific sense, multi-lingual and [Pin Mapping]; models and files will continue to support them. For new package structures, we would not have to consider multi-lingual and [Pin Mapping] keyword interactions with the new stuff and other existing stuff. Second stage is removal. Bob replied that he has no problem with that. He would not call it deprecation but simply specifying usage. This results in a testable rule: if A, then the use of B means an error. Arpad asked Walter to clarify his thoughts on only adding keywords and preserving keywords vs. forking vs. the deprecation/variation concept just outlined. Walter replied that he does not want the specification to handle the interaction of new stuff with Pin Mapping, etc. Radek added that he did not see much difference between the first approach and the second approach; one can effectively deprecate with a change in usage. Michael raised the idea of [IBIS Ver] as new “A” that invalidates use of “B”, as a pathological case that eliminates the distinction between specifying, deprecation and forking. Walter stated that he totally rejects a “blank sheet” approach. Arpad asked how Walter’s earlier proposal for separating IBIS chapters into individual documents is distinct from a blank sheet approach. Walter replied that this was an editorial, not structural, approach to making specification development easier. A full new parameter tree approach for IBIS would be a mistake now due to need for existing infrastructure. Bob noted that separate LISP-like parameter trees in multi-lingual format is possible, but multi-lingual IBIS is inconsistently supported. Michael noted that, per this discussion, starting with a blank sheet of paper is not supported. Discussion was focused on keywords and multi-lingual support, but what about assumptions, like one-to-one mapping between pins and models? Bob suggested expanding that assumption to many-to-one connections. Walter disagreed, suggesting that [Model], not power/ground, needs one-to-one correspondence for simplicity. Exceptions include RAMBUS clocking and multi-chip modules, which could be handled through EBD and die-only IBIS files. Additional questions surround supporting drivers that have two outputs. Arpad added that we may not need to keep the one-to-one assumption, but could use an updated keyword to support the concept. Michael reiterated that, per this discussion, starting with a blank sheet of paper is not supported. Further, formal deprecation by eliminating support for keywords is not preferred, either. New keywords can be added, but with careful statements as to which other structures, assumptions and keywords in today’s specification would not interact or could not be used with them. The next meeting will focus on identifying those keywords, structures and assumptions.