================================================================================ IBIS INTERCONNECT TASK GROUP http://www.ibis.org/interconnect_wip/ Mailing list: ibis-interconnect@freelists.org Archives at http://www.freelists.org/archive/ibis-interconn/ ================================================================================ Attendees from March 27, 2019 Meeting (* means attended at least using audio) ANSYS Curtis Clark* Cadence Design Systems Bradley Brim* Intel Corp. Michael Mirmak* Keysight Technologies Radek Biernacki Mentor, A Siemens Business Arpad Muranyi* Micron Technology Justin Butterfield*, Randy Wolff* SiSoft Walter Katz*, Mike LaBonte* Teraspeed Labs Bob Ross* Michael Mirmak convened the meeting. No patents were declared. Justin Butterfield took minutes. Review of Minutes: - Michael called for review of the minutes from the March 20, 2019 meeting. Mike LaBonte moved to approve the minutes. Brad Brim seconded. The minutes were approved without objection. Review of ARs: - Michael and Mike to draft an email survey to the SI list on the usage of Touchstone 2.0 models. - Michael reported that this is on the bin list of items for discussion. Opens: - None. EMD Status and Features Needed: Walter Katz shared the latest draft of the EMD proposal BIRD. The BIRD is a rewrite of the EBD section to replace the Path Descriptions with the Interconnect Modeling syntax. He reviewed the Statement of the Issue, and noted there are numerous editorial changes required to clean up the document. The Requirements are based on BIRD189, excluding requirements related to die and package models. Walter reviewed the EMD Introduction. EMD is intended to be a stand-alone file describing a module, which could be a printed circuit board (PCB), Multi Chip Module (MCM), stacked die, interposer or substrate. The syntax follows EBD with [Pin List] and [Reference Designator Map] keywords. And, it follows BIRD189 with Interconnect Model keywords and including [Interconnect Model Group] and [Interconnect Model Set] keywords. Arpad Muranyi noted that [Interconnect Model Group] is not listed in the list of keywords. Walter corrected this in the draft. Walter noted the Interconnect Models are different for EMD. The terminals are pins at some location, either at the external interface of the module or at a component. The terminals can be a signal or a rail. The component terminals include the reference designator. Walter noted we may want to consider an enhancement for adding process and etch corner capability shortcuts in the [Interconnect Model] keyword syntax for both EMD and BIRD189. He also presented an example for a DIMM model. Michael asked if we want to keep the same scope as EBD or expand it. He asked if EMD would support PCBs with no active devices. Walter replied this would be supported. Michael would like to have support for a completely passive description of a PCB. Walter stated the reference designator could be empty in this case. Brad asked if EMD could be a netlist. Walter stated EMD can be thought of as a netlist between specific pins. You could have connections between components that don't connect to the outside. In EMD, you can connect from pin to pin, pin to device, or device to device. Michael noted that EBD and EMD have a strong focus on DIMMs and asked if EMD can support PCI riser cards as well. He noted that it would be good to have an example focused on a SerDes application. Walter stated this can be done, and you could do connectors as well with EMD, but a different format would be better for connectors. Connector models would typically be limited number of port S-parameter model using swathing. He would like to see a new modeling approach for connector models. Brad stated the description of a system includes schematic, layout, and netlist. He asked what does an EMD do to model the system and how it would differ from the netlist. Walter gave some examples. DIMMs would be one example, where we can use EMD to more accurately model the DIMM interconnect. Another example would be stacked DRAM packages. Brad asked if anything would prevent you from representing your motherboard with EMD. Walter stated there is nothing to prevent this. Brad asked if you can have drivers and receivers in EMD. Walter replied that the drivers and receivers are modeled as IBIS components which are referenced in the EMD. The goal of EMD is to describe the interconnect of DIMMs and complex packages with multiple silicon die. Arpad asked if it would help to allow elements such as capacitors outside of the subcircuits to simplify things. Walter suggested all the circuit elements be in the spice subcircuits to keep things simple. Michael asked if Walter sees EMD as a BIRD to the IBIS specification or a separate specification. Walter responded that this is something we should discuss and decide. Mike commented he is leaning toward keeping EMD as a part of IBIS. Bob Ross stated, since there is a lot of interaction with IBIS, he prefers to keep EMD in the IBIS specification. Arpad asked how we will handle EBD. Bob commented that we cannot deprecate EBD, as it is still used. Michael suggested to make a statement about not mixing the two formats. Brad asked about the schematic, layout, and netlist flow, where the netlist is not driving changes in the design. Walter commented that these steps may be done in different EDA tools. Brad asked if we have an EMD with drivers, receivers, and the interconnect instantiated, if this is not the system. Brad stated we seem to be going toward a system level description. Michael commented that the system may be described by other standards such as IEEE 2401. Arpad asked about the case where you have a daughter board connecting to both a DIMM and a motherboard. Walter stated that EBD and tools today can handle this. He added you could do this EMD, but each EMD has well defined interfaces. Arpad asked Brad if this becomes the system model. Brad stated he is trying to determine the bounds of the system and where is the limit and scope of EMD. Walter noted all EMD includes is the netlist. Bob commented that it could be a partial system. Mike commented that a module is a part of a complete system; the module would be the biggest part of the system that you would want to model. Bob thought it might be better to call it ESD for Electrical System Description. Mike noted this would be an acronym overlap. Walter noted that it is not the intent of EMD to model the entire system. Michael asked if we need to settle this system question before moving forward. Walter replied no. Walter suggested for everyone to thoroughly review the draft to see if it is functionally correct and meets the current needs. Walter saved this version as draft 2 and asked if Mike can post it to the website. Mike to post draft 2 of the EMD BIRD to the website [AR]. Next Meeting: The next meeting will be April 3. Mike moved to adjourn. Arpad seconded. The meeting adjourned without objection.