Subject: Agenda, IBIS Cookbook/Futures Committee Meeting for 2/24/05 From: "Mirmak, Michael" Date: Thu, 24 Feb 2005 10:52:05 -0800 To: "Angulo, John" , "Colin Warwick" , "Dodd, Ian" , "Green, Lynne" , "Huq, Syed" , "Istvan Novak" , "Mark Alexander" , "Muranyi, Arpad" , "Otto Bennig" , "Powell, Jon N" , "Ross, Bob" , "Wang, Lance" CC: "Donald Telian" ====================================================================== IBIS FUTURES/COOKBOOK SUBCOMMITTEE MEETING MINUTES Date: February 10, 2005 Attendees: ---------- Cisco - Vinu Arumugham, Syed Huq Green Streak Programs - Lynne Green Intel - Michael Mirmak, Arpad Muranyi, Jon Powell, Ke Wang Mentor Graphics - John Angulo Samtec - Otto Bennig Teraspeed - Bob Ross ====================================================================== Next Meeting: Thursday, February 24 1 PM - 2 PM US Pacific Time (ONE HOUR ONLY FOR THIS WEEK) Telephone Bridge Passcode 916-356-2663 1 205-7619 Agenda: 1 - 1:05 PM Opens 1:05 - 1:20 PM Futures Discussion - BIRD95.2 Update (Syed Huq) - SPICE Macromodeling Summary (Telian) - Macromodeling Questions (Mirmak) NO COOKBOOK DISCUSSION THIS WEEK ====================================================================== Futures Minutes Bob Ross summarized the status of the IBIS 4.1 parser 1) IBIS-ICM: need new BIRD to cover this, no mechanism exists in the parser to treat this. 2) An open question for the specification still remains: when are certain power rails required for certain [External Model] models? For example, can we omit [Pullup Reference] for Open Drain models using [External Model]? No objections were raised to recommending the parser be released as-is. Michael began reviewing some of his proposals for linking ICM and IBIS. Hurdles still remain, especially on support of "native" IBIS with ICM package models. The lack of a [Pad] keyword and the assumption of one-to-one mapping from pin to pad is a major point of confusion. Arpad suggested that [External Circuit] could be used, with an order dependency for ICM nodes and pins vs. [Node Declarations]. Bob further proposed using [External Circuit] with its own "ICM" specific model type, though port and node naming becomes an issue here. Arpad suggested new syntax to limit [Model] and ICM support to one-to-one for the "native IBIS" case: pinname.signalout, powersupplynames, etc. The [Pin] list would still instantiate models, and "Side" could be used to distinguish pins from pads. However, a standard set of "dot" names would define how the connections would be handled. Parsing of ICM becomes a requirement under IBIS if ICM packages are supported. Syed suggested using a "-ICM" switch in the parser, and integrating the ICM parser source code. Bob mentioned the issues of whether ICM files as packages can be placed in the same IBIS file as the buffer models, or in a different file. EBD must be in a separate file, for example. --------------------------------------- BIRD95.1 Syed provided a brief overview of a new proposal for simplifying the power integrity integration into IBIS: separate BIRD95 into three BIRDs, each addressing I-T, ICM and ICEM integration individually. Team agreed this would help adoption, but that some text still needs considerable work. Bob Ross commented that the BIRD still needs some "nitty gritty" information on model type matching; for example, what should be the proper I-T treatment for Open Drain models (should it follow current IBIS model support)? Bob also suggested addressing all 23 model types and their treatment under BIRD95. A table is fine for this, though no receiver coverage is anticipated. Syed noted that I-T tables should match the V-T waveforms included, but that the I-Ts should still include the high-impedance case. Bob asked if we need to have an I-T table with EVERY V-T waveform? Syed responded in the negative. A single I-T should be possible. Bob also raised concerns that the internal RLC circuit modeling the frequency-domain impedance behavior be included in the BIRD95 text even without the ICM spec. He took the AR to create a proposal for this. ARs Syed - put table together on I-T handling per Model_type Bob - create proposal for internal RLC handling, absent ICM integration, for BIRD95 I-T curves ====================================================================== Cookbook Minutes Arpad provided an overview of the new differential chapter, including details on buffer common mode and differential mode impedances and how to extract them. Further, a significant amount of text was added to explain the differences in usage of the term "differential" in the electronics industry today. The new chapter was positively received, with Bob Ross recommended checking the documents' terminology consistency, including unusual usages such as "CMOSFET" etc. Bob also reiterated his comment that the document would be highly useful even if released in the current draft form. John Angulo suggested making stronger mention of the fact that differential components aren't often required for "differential models" (in other words, that complementary single-ended models describe most designs available today).