====================================================================== IBIS INTERCONNECT TASK GROUP http://www.eda.org/ibis/interconnect_wip/ Mailing list: ibis-interconnect@freelists.org Archives at http://www.freelists.org/archive/ibis-interconn/ ====================================================================== Attendees from September 2, 2015 Meeting (* means attended) ANSYS Curtis Clark Cadence Design Systems Bradley Brim Cisco David Siadat Intel Corp. Michael Mirmak Keysight Technologies Radek Biernacki* Mentor Graphics Arpad Muranyi* Micron Technology Justin Butterfield*, Randy Wolff Signal Integrity Software Walter Katz*, Mike LaBonte* Teraspeed Labs Bob Ross* University of Aveiro in Portugal Wael Dghais Arpad Muranyi led the meeting. He noted that minutes from the previous meeting were not yet available for review. No patents were declared. No opens were raised. The discussion focused on the alternative proposals for the "Terminal" structure in the draft Interconnect BIRD. ARs: - None Terminal Syntax: We reviewed two proposals. Walter showed an email sent by him suggesting a syntax that uses both [Pin Mapping] and [Buffer Rail Mapping]. All terminals can be subdivided by [Pin Mapping] bus labels. For example DQ and address pins might use separate rails and bus labels VDD1 and VDD2 might be used. [Pin Mapping] should be enhanced to have bus labels be signal names. Power and ground signals should not be used across bus labels. Walter said bus rails are items effectively connect by small resistance, but not really shorted. Arpad said we should not go by resistor value, sometimes people use small resistors to create shorts. Walter said that Bob's example associating buffer rails with pad names may be a problem. Walter showed a table showing allowed terminal types, with a bus_label column. Bob showed a presentation "Updated Interconnect Proposal". This has a table similar to the one shown by Walter but without the bus_name column. Buffer_rail is a terminal type. Arpad asked about the case where a signal is an aggressor in one simulation but a victim in another. Walter said models can have signals with only crosstalk and no data. These would be used only as aggressors. Bob proposed a new [Pin Mapping] sub-parameter Pad_signal_name. One example specifies terminals for both pins and pads, so [Pin Mapping] is not needed. Another example uses Pin_rail terminal type. Walter said [Pin Mapping] would still be needed for that. Bob said IBIS-ISS would make the hookup. Walter said [Pin Mapping] would be needed to know which buffers need VDD, for example. Radek asked for the definition of the ??? keyword. Bob said making connections by signal name brings in all pins on those signals, and [Pin Mapping] details the inner connections. More work is needed on the proposal. Radek noted that think short circuit lines are used on one diagram and thick signal lines for the same path on another diagram. Bob said pads might have the own labels and might not be given as pin names. Mike L noted that one to many connections of pins to pads would then be allowable. Bob said we might have to address several interconnect models being used together. Also buffer rails might be separate nodes, but this is not yet addressed. Walter agreed to having both bus label and signal_name but disagreed with having the pad_name column. Bob asked about replacing pad_name with bus label. Walter said pad_name is needed where we have 10 VDD pins and 20 VDD pads. Bus labels are not useful in that case. Walter asked if it makes sense to discuss buffers as "shorted together", suggesting people with more silicon experience might help address that. Bob agreed with Walter's assertion about bus labels. Walter requested a group decision on which proposal to proceed with. Arpad asked for Walter's email to be sent as a PDF. Walter said he would add some examples. AR: Bob send his proposal to Mike for posting. AR: Walter send his proposal to Mike for posting.