DATE: 02/11/04 SUBJECT: February 2, 2004 EIA IBIS Summit Meeting Minutes VOTING MEMBERS AND 2004 PARTICIPANTS Ansoft Corporation (Eric Bracken) Apple Computer (To Be Determined) Applied Simulation Technology Norio Matsui* Cadence Design Systems C. Kumar*, Lance Wang* Cisco Systems Syed Huq* Fairchild Semiconductor (Graham Connolly) Hitachi ULSI Systems (Kazuyoshi Shoji) Huawei Technologies (Jiang Xiang Zhong) Intel Corporation David Keates*, Peter T. Larsen* Wilson Leung*, Michael Mirmak* Arpad Muranyi*, Steve Peterson* LSI Logic Frank Gasparik Matsushita (Panasonic) Atsuji Ito* Mentor Graphics John Angulo*, Weston Beal* Guy de Burgh, Ian Dodd* Micron Technology Paul Gregory*, Randy Wolff* Molex Incorporated (Gus Panella) Motorola (Rick Kingen) National Semiconductor (Lee Sledjeski) NEC Electric Corporation (Itsuki Yamada) North East Systems Associates Edward Sayre* Philips Semiconductor (D.C. Sessions) Samtec (Corey Kimble) Siemens AG Eckhard Lenski Siemens Medical (Acuson) David Lieby* Signal Integrity Software Robert Haller*, Barry Katz* Sigrity Raymond Chen*, Jiayuan Fang* Sun Microsystems (Tim Coyle) Synopsys (Hailong Wang) Texas Instruments Hector Torres* Teraspeed Consulting Group Tom Dagostino*, Scott McMorrow*, Bob Ross* Time Domain Analysis Systems Steve Corey* Zuken (& Incases) (Michael Schaeder) OTHER PARTICIPANTS IN 2004: Apache Design Yu Liu* Bayside Design Daniel Lambalot*, Kevin Roselle* Conexant Garry Felker* Cortina Systems Robert Badal* EFM Ekkehard Miersch* Extreme Networks Lin Shen* GEIA (Chris Denham) Green Streak Programs Lynne Green* Independent Kim Helliwell*, Jon Powell* Netlogic Microsystems Eric Hsu* Samsung Il Seong* Silverback Systems Gil Gafni* In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. UPCOMING MEETINGS The bridge numbers for future IBIS teleconferences are as follows: Date Telephone Number Bridge # Passcode February 20, 2004 European SUMMIT, Paris, France NO TELECONFERENCE February 20, 2004 1-916-356-2663 3 673-0282 All meetings are 8:00 AM to 9:55 AM US Pacific Time. Meeting agendas are typically distributed seven days before each Open Forum. Minutes are typically distributed within seven days of the corresponding meeting. When calling into the meeting, provide the bridge number and passcode at the automated prompts. If asked by an operator, please request to join the IBIS Open Forum hosted by Michael Mirmak. For international dial-in numbers, please contact Michael Mirmak. NOTE: "AR" = Action Required. --------------------------------MINUTES----------------------------------- INTRODUCTIONS AND MEETING QUORUM The IBIS Summit Meeting was held in Santa Clara, California at the Westin Hotel in conjunction with the International Engineering Consortium's (IEC) DesignCon 2004 Conference. The summit was co-sponsored by IBIS, DesignCon, and Cisco Systems. 40 people representing 25 organizations attended. The notes below capture some of the content and discussions. The meeting presentations and other documents are uploaded at: http://www.eda.org/pub/ibis/summits/feb04a/ Michael Mirmak opened the meeting. Michael thanked the IEC and DesignCon for providing a room and other logistics, noting that IBIS is a co-sponsor of DesignCon. Michael also thanked Syed Huq and Cisco for providing the summit refreshments. He also singled out Lynne Green for her assistance with calls for papers and setting the agenda. Finally, Michael thanked the presenters and participants for attending. Michael asked everyone in the room to introduce themselves. The group was well-attended by semiconductor vendors and model providers (eleven), EDA tool vendors (six) and users of IBIS models (three). Michael asked if there were any new issues or discussion items to add to the agenda. No issues were raised. PRESENTATIONS AND DISCUSSION TOPICS The rest of the meeting consisted of presentations and discussions. These notes capture some of the content and discussion. More details are available in the documents uploaded to the location noted above. IBIS CHAIR'S REPORT Michael Mirmak, Intel Corporation Michael reviewed the recent work of the IBIS Open Forum and IBIS community at large. The Open Forum has made stunning progress in advancing behavioral modeling over the past six months. In addition to approving IBIS 4.1, which introduces links to Verilog-AMS and VHDL-AMS models into IBIS, a golden parser for IBIS 4.0 has been publicly released. Further, the IBIS Interconnect Modeling Specification (ICM) 1.0 was issued and a golden parser released to the public, under an open-source license agreement. The IBIS Quality Committee continues to provide feedback on models and modeling issues. Despite a slow economy, Michael observed that finances continue to be strong, with 28 paid members and ten purchasers of (IBISCHK4) Golden Parser licenses. While IBIS Open Forum work has been successful, challenges still remain ahead for IBIS as a whole. In order to better support IBIS tool vendors, model makers, and users, Michael reiterated his call for cookbooks for both ICM and IBIS 4.0. Michael also suggested that more corporate and industry-publication guidance be provided on the new languages linked to IBIS under version 4.1. Further, the Open Forum should continue to expand and enhance a global IBIS community; support of the European DATE summit must continue, but the Open Forum should also consider holding "Electronic Roadshow" presentations, which Michael detailed in his "IBIS Futures Roadmap" presentation (see below). Finally, Michael thanked the IBIS Open Forum participants and community members for their continued support. IBIS QUALITY Robert Haller, Signal Integrity Software (SiSoft) Robert reviewed the purpose of the Quality Committee and summarized the backgrounds of the various participants. He then provided an overview of the current, untitled IBIS Quality document and its chapters. Robert noted that the first draft is complete and has some material cross-referenced with the earlier IBIS Accuracy Handbook. The key idea behind the IBIS Quality document is its description of quality levels. A Level 0 model has passed the simple IBISCHK parser checks without errors. At Level 1, the model has additionally passed basic simulation testing with transmission lines and the like. A Level 2a model has been correlated in simulation with a transistor-level model. Robert observed that comments within the model are used to document the various levels and the outcome of testing. A separate document is not intended to be created for distribution with the model. Some participants expressed concern that these checks, even if completed automatically, might result in changed model text. Robert acknowledged these concerns, but noted that the core IBIS data would not be changed by the IBIS Quality procedure. Robert concluded his presentation by noting and thanking the committee participants. For additional information on the quality committee and to be included on the mailing list send mail to ibis-quality@freelist.org. The IBIS quality committee web site is available on the IBIS web page or at http://www.sisoft.com/ibis-quality IBIS DIE V-T TABLES FROM PART OR BOARD MEASUREMENTS Bob Ross, Teraspeed Consulting Group Bob summarized his presentation material by observing that IBIS at-die V-T tables can be generated from at-pin or at-board measurement data through a mathematical process. Specifically, the process consists of a linear transformation of the time-domain information taken at the non-die-pad location. If package and board loading information is available, this can be added in simulation to an IBIS model containing at-pin or at-board V-T curves and the differences noted; these same differences can then be adjusted out of the original at-pin data. To demonstrate the process, Bob provided an example data set with a package modeled with LC components. Using Bob's method, a model V-T curve set could be created with from 0.8% to 7.2% mismatch against the I-V curves. Michael Mirmak noted that this process still required rather accurate die capacitance (C_comp) information. Scott McMorrow observed that this could be derived from TDR measurements fairly accurately, with minor losses in the package for edges up to 100 ps. He further observed, however, that the LC modeling technique for the package parasitics is likely to cause errors for edges faster than 1 ns. Steve Peterson suggested that the method did not account for losses or any DC shifting in the V-T curves between the die pads and the measurement points. Jon Powell inquired as to how division of the data into typical, minimum and maximum corners could be justified, as parts which reflect full manufacturing tolerances may not be available. Bob agreed and stated that temperature and voltage variations were used to approximate the entire range of manufacturing variations. CREATING IBIS MODELS FOR STACKED-DIE PACKAGES Steve Peterson, Intel Corporation Steve began by describing his group's applications for IBIS. Typically, designs call for several dice to be combined within a single package; as the dice are from separate vendors, schematics and detailed transistor- level models are not available. Instead, to perform simulations, Steve described a process by which I-V and V-T curves are generated for use under the [Model Selector] keyword, as combinations of the driving die effects and the loading of the non-driving dice. A single package model is used per pad. At present, EBD is used to model package parasitics, but other formats are being investigated, particularly for "Y" structures. The EBD includes a worst-case inductance as a sum of the inductances of all paths. Lance Wang and Lynne Green raised questions regarding die capacitance. Should the C_comp values of each of the combined dice be summed or should some other adjustment method be used to account for die capacitance and loading? Steve mentioned that correlation data was so far indicating a good match to silicon behavior, but that other methods of C_comp adjustment were under investigation. IBIS FUTURES ROADMAP Michael Mirmak, Intel Corp Michael summarized the history of IBIS parsers and IBIS specification releases since version 1.0. On average, a new parser version has been released 28 months after the final release of the corresponding IBIS specification. In addition, Michael noted that a new major IBIS release is approved every 24 months, on average. To ensure that IBIS remains useful to the industry, Michael suggested tightening these time delays, observing that, as the PC, transportation, and consumer electronics industries converge, product cycles are also converging on an 18 month pace. The Open Forum should be more proactive in seeking out and including support for new technologies, rather than waiting for industry adoption before including support in IBIS. To address this, he suggested a revived Futures Subcommittee, which would be chartered to develop IBIS and ICM improvements. A few have already been proposed: explicit digital states for 4.1 input ports, user-definable measurement and input threshold parameters, and formal links between ICM and IBIS. In addition, to better support the IBIS community in adopting new technologies and modeling approaches, Michael proposed a formal Cookbook Subcommittee to revise the 1997 IBIS 2.1 cookbook. This would clarify the meaning and use of the 3.2 and 4.0 keywords introduced since that time, and provide appropriate examples plus data extraction guidance. Further, Michael elaborated on his "E-Roadshow" proposal. As the global economic situation still does not permit extensive travel, but globalization is still spreading in the industry, a new method is needed to assist and train IBIS users and model makers worldwide. The Open Forum should provide short training sessions, called "E-Roadshows," in time zones convenient to the US, Europe and Asia, featuring one or two summit-quality presentation and question periods. This would help bring state-of-the-art training to other parts of the globe while not incurring the costs associated with international travel. Michael showed a graphical timeline illustrating the most desirable milestones for these deliverables, and noted that both of the new committees would begin forming in the coming weeks. Several participants commented that EDA tool product cycles are also approximately 18 months, so a compression of the specification-to-parser time may be very difficult to accomplish. In addition, Bob Ross noted that more than just one or two early adopter organizations would be necessary to ensure full acceptance of new modeling features, even with cookbooks and training. Lance Wang also raised the issue that, even with awareness of time zones, language barriers might still make such training sessions difficult. ADDING ON-CHIP CAPACITANCE IN IBIS FORMAT FOR SSO SIMULATION Raymond Chen, Sigrity Raymond described the method used to add loading to approximate power delivery and SSO effects in system simulations. IBIS in general is useful for these analyses, as it is faster than a transistor-level simulation and is often the only kind of data available from external vendors. Package models, either IBIS RLC or using matrices, include the coupling and mutual effects needed to analyze aggressor/victim behavior. Sigrity's tool approach for IBIS power delivery is to add package and power delivery networks automatically between the power/ground pins and the die pads using the [Pin Mapping] keyword. In general, the Sigrity approach to IBIS instantiation resembles the Synopsys HSPICE* B-element. Several kinds of analysis -- active signals, plus "stuck high" and "stuck low" for victims -- can be included to note power delivery network impact on system simulation results. An additional Cdie, to represent die capacitance not specifically associated with buffers but between power and ground supplies, is added to make simulation results more realistic (SSO sims with IBIS can be too pessimistic without an additional Cdie). More accuracy can be added with an Rdie in series with the Cdie. Arpad Muranyi noted that a non-IBIS Cdie may not be required, as a [Series Element] capacitance could be used between [Pin Mapping] ground and power pins, with Rdie included. Raymond agreed and observed that the industry should be including Cdie information with their models, regardless of series element support. In general, the value of Cdie is typically 10 nF to 100 nF for dice with advanced interfaces, with the value representing the entire die. Bob Ross suggested consulting the 2001 summit presentation archive, as some data there suggested Cdie values in the femtofarad range. Jon Powell and Ian Dodd inquired about crowbar current during switching, which IBIS may or may not be explicitly including. Raymond responded that IBIS data can be represented using two non-linear switches for the pullup and pulldown circuit behaviors. This would account for crowbar currents and is already included in Sigrity's tools. Further, Raymond observed that the current EBD format for package data does not adequately represent on-die power delivery networks, as coupling information is excluded and a one-to-one pad-to-pin mapping is assumed. Jon Powell suggested that a nodal representation is required, which Sigrity's tool assumes when reading IBIS data. Arpad Muranyi noted that ICM permits more detailed network modeling, but that more explicit IBIS descriptions of die pads vs. die pins may be required, perhaps with a pad-level keyword or the 4.1 [Node Declarations] keyword. John Angulo responded that, as 4.1 was currently defined, this approach would be limited to use with VHDL-AMS, Verilog-AMS or Berkeley SPICE buffer representations. A VHDL-AMS TRUE DIFFERENTIAL BUFFER MODEL USING IBIS V3.2 DATA Arpad Muranyi, Intel Corp. Arpad began his presentation by referring to earlier summit discussions on VHDL-AMS representations of IBIS buffer data, in 2002 and 2003. Using his earlier VHDL-AMS single-ended buffer code, he developed a differential representation which uses totem-pole IBIS data for the common mode components and a specially-fitted curve for the differential relationship between the die pads. He then presented the actual code changes from his original single-ended model. The code now includes differential capacitance estimates and the adjustments required to the V-T curves for this new capacitance. The new code also adds the necessary coefficients for V-T and I-V curve matching. Finally, a second-order equation is used to create an I-V surface to represent the differential currents. Arpad then demonstrated how the VHDL-AMS model compares to transistor-level model performance and also against Synopsys HSPICE*, using the B-element [Series MOSFET] keyword to represent the differential currents. Overall, the matching was best for differential loads matching the cases used to generate the V-T data for the model. Load values lower than those used in the original V-T curves also showed good correlation. Values higher, especially for open circuits, showed increasingly poor correlation against the circuit model, though the [Series MOSFET] model behavior was comparable. Michael Mirmak suggested that perhaps more accurate models for manufacturing tolerances and corners should be generated with V-T curve fixtures deliberately higher than the PCB targets anticipated. Bob Ross observed that the poor behavior of the unloaded circuit may be due to current starvation, which IBIS models do not predict well without additional data. TRUE DIFFERENTIAL BUFFER MODELS (CASE STUDY) Arpad Muranyi, Intel Corp. Arpad Muranyi summarized the history of differential model analysis at previous summits. In 2002 and 2003, he presented a new way of using surface plots and other methods to determine the common mode and differential mode currents in circuit designs. Now that a VHDL-AMS model of a differential buffer is available (see above), what process should be used, if any, to automate the differential data collection process? Arpad noted that several types of buffers, such as LVDS, contain on-die terminations between die pads, implying a differential current flow. However, the differential current response of other types (PCIe, S-ATA, etc.) is not clear. Arpad analyzed several types of buffer designs, including LVDS with and without on-die termination and a S-ATA buffer. In all cases without on-die termination, the differential impedance seen in surface plots of the operating region was in excess of 100 Mohms. Only the on-die termination LVDS design showed a lower differential impedance, specifically 600 ohms. Even with pre-emphasis, a 100 Mohm differential impedance was still seen when on-die termination was not present. From this, Arpad concluded that the current method of representing differential IBIS models using two single-ended models with complementary switching is adequate for even high-speed applications. Michael Mirmak noted that die capacitance may still be a problem for pre-emphasis designs, but that overall Arpad's findings agreed with his experience. OTHER DISCUSSIONS AND AD HOC PRESENTATIONS Michael Mirmak raised four issues for discussion: non-monotonicity in curves as detected by the parser; package modeling and connectivity, as described by Raymond Chen in his presentation; IBSI 4.1 issues; and [Driver Schedule] interpretations. Paul Gregory posed his question on parsing of non-monotonic waveforms to the group: does the current IBIS parser report I-V monotonicity issues before or after the clamp curves are summed with the drive curves? Bob Ross explained that, in version 4.0.1 of the parser, IBIS 3.2 models would continue to be interpreted without summation, while IBIS 4.0 models would be checked after summation. Bob explained that this was consciously decided by the IBIS Open Forum, in order to preserve the states of existing IBIS models. Michael Mirmak raised the issue that a parser specification, which would be publicly accessible, would help to inform the community as to the interpretations and assumptions of the various parser versions. On package modeling and connectivity, Bob Ross pointed out that a new [Pad] or [Pad Mapping] keyword may not be needed, as the [Node Declarations] keyword allows splitting of package or routing paths to multiple pads. Weston Beal noted that, outside of the IBIS 4.1 syntax, a [Pad] keyword might make tracking of the pin or pad of interest difficult to do automatically at the tool level (IBIS 4.1 has subparameters to address this with the *-AMS languages). At present, Bob observed that pads are implicitly named through the [Pin] keyword for traditional IBIS models. Weston also noted that separating pads and pins may make buffer behavior evaluation difficult, especially with subparameters such as SI_location and Timing_location. Regarding IBIS 4.1, John Angulo raised the question of traditional or native IBIS (I-V and V-T curve data) with the new [External Circuit] keyword. At present, IBIS 4.1 permits detailed on-die connectivity or package models using [External Circuit], but the language of IBIS 4.1 does not allow these to be used with traditional IBIS, but only with *-AMS or Berkeley SPICE buffer models. Michael Mirmak deferred this discussion to the Futures Subcommittee. Jon Powell raised the question of co-simulation, where two different model types or languages had to be synchronized in the same tool. Ian Dodd commented that most tools had several engines to deal with different languages, but that a major problem still existed in synchronizing events and simulation steps between the digital and analog domains for mixed signal simulations. Kim Helliwell inquired about the IBIS Quality committee. He noted that a Level 0 model is tested by the golden parser, but that, to his knowledge, receiver thresholds, Vmeas and driver loads and overshoots are not checked in any way and might be good requirements to add to a future IBIS specification or parser. Lynne Green confirmed that missing input thresholds would generate a warning, but agreed that the specification language could be clarified on whether the parameters Kim mentioned were absolutely required. INTERPRETING THE [DRIVER SCHEDULE] KEYWORD (AD HOC TOPIC) Arpad Muranyi, Intel Corp. Arpad Muranyi reviewed a short presentation on interpreting the [Driver Schedule] keyword. Arpad noted that some controversy still existed regarding special cases of [Driver Schedule] and that some tool vendors may be adopting incorrect interpretations. He summarized the parts of [Driver Schedule] and commented that he assumed the "NA" characters to be different in meaning than "0." His recent BIRD, 84.1, clarifies how the polarity subparameter is to be used and also defines the term "event" in the specification. He noted, though, that initial conditions are still undefined and that two interpretations of initial conditions exist: one based on the input stimulus (Arpad's approach) and another based on "reverse engineering" from a known state. Arpad also addressed over-clocking of buffers and noted that the BIRD84.1 interpretation does not assume that scheduled buffers have any type of "memory" when delays are calculated. Arpad's presentation is uploaded to the eda.org website as muranyi3.pdf. [DRIVER SCHEDULE] MODEL INITIALIZATION (AD HOC TOPIC) Bob Ross, Teraspeed Consulting Group Bob responded to Arpad Muranyi's presentation with his own presentation from 2001, which outlined the original intent of [Driver Schedule]. A "full cycle" method was assumed for interpreting the scheduled driver turn-on and turn-off times, with a table of known initialization states provided. The table is not present in the current IBIS specification, but can be re-derived if needed. Over-clocking is not comprehended nor is it supported. Bob suggested that tools not implementing [Driver Schedule] using the "full cycle" interpretation and initialization states may cause significant errors in fairly simple simulation situations. Bob's presentation is uploaded to the eda.org website as both ross2.zip and ross2.pdf. The "Driver Schedule Modeling" presentation by Chris Reid and Bob Ross given June 2001 is archived under: http://www.eda.org/pub/ibis/summits/jun01/ Both Bob and Arpad accepted an AR to write a BIRD to finally clarify how [Driver Schedule] is to be interpreted. They also accepted an AR to develop a simple test suite of models which could be used by tool vendors to validate their interpretations of the keyword. CONCLUDING ITEMS Michael Mirmak again thanked the presenters and IEC sponsors for their help and support in making the Summit a success. After reminding the participants regarding the next Open Forum teleconference, Michael closed the IBIS Summit Meeting. NEXT MEETING The next Open Forum teleconference has been scheduled for February 20, 2004 from 8:00 AM to 10:00 AM US Pacific Standard Time. A vote regarding the approval of BIRD87 is scheduled. The next IBIS Summit will take place at DATE 2004 on February 20, 2004 in Paris, France. ======================================================================== NOTES IBIS CHAIR: Michael Mirmak (916) 356-4261, Fax: (916) 377-1046 michael.mirmak@intel.com Senior Analog Engineer, Intel Corporation M/S FM6-45 1900 Prairie City Rd. Folsom, CA 95630 VICE CHAIR: Lynne Green (425) 788-0412, Fax (425) 788-4289 lgreen22@mindspring.com Green Streak Programs 20130 181st PL NE Woodinville, WA 98077 SECRETARY: Randy Wolff (208) 363-1764, Fax: (208) 368-3475 rrwolff@micron.com Simulation Engineer, Micron Technology, Inc. 8000 S. Federal Way Mail Stop: 1-711 Boise, ID 83707-0006 LIBRARIAN: Roy Leventhal (847) 590-9398 roy.leventhal@ieee.org Consultant, Leventhal Design and Communications 1924 North Burke Drive Arlington Heights, Illinois 60004 WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504 shuq@cisco.com Manager, Hardware Engineering, Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 POSTMASTER: John Angulo (425) 497-5077, Fax: (425) 881-1008 John_angulo@mentor.com Development Engineer, Mentor Graphics 14715 N.E. 95th Street, Suite 200 Redmond, WA 98052 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: majordomo@eda.org In the body, for the IBIS Open Forum Reflector: subscribe ibis In the body, for the IBIS Users' Group Reflector: subscribe ibis-users Help and other commands: help ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibis-bug@eda.org To report ibischk3 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibis_bugs/bugform.txt along with reported bugs. icm-bug@eda.org To report icmchk1 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/icm_bugs/icm_bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt and /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants and actual IBIS models are available on the IBIS Home page: http://www.eigroup.org/ibis/ibis.htm Check the IBIS file directory on eda.org for more information on previous discussions and results: http://www.eda.org/pub/ibis/directory.html * Other trademarks, brands and names are the property of their respective owners.