====================================================================== 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 February 10 Meeting (* means attended at least using audio) 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* SAE ITC Maureen Lemankiewicz, Logen Johnson Signal Integrity Software Walter Katz*, Mike LaBonte* Teraspeed Labs Bob Ross* University of Aveiro in Portugal Wael Dghais Michael Mirmak convened the meeting. No patents were declared. Mike LaBonte moved to approve the minutes. Arpad Muranyi seconded the motion. The minutes were approved without objections. The team discussed recent offline messages regarding Pin Mapping treatments. On Pin Mapping, Walter Katz suggested we needed to add words or terms for terminals to the BIRD proposal; Bob Ross and Walter are in agreement. We can also integrate signal_name and databook name issue (that they should be identical) into the existing text. Bob observed that this will be a big section, changing [Pin], [Pin Mapping], and whever is decided on Bus Supply Labels. Arpad noted that we should decide whether these should be separate based on whether, for example, some changes are needed even if the Interconnect BIRD is not approved. Bob replied that he was personally neutral. Breaking the changes up into two BIRDs makes management easier. The team would still have to strip out interdependencies. Arpad suggested that the Interconnect BIRD doesn’t make sense without Pin and Pin Mapping changes; we should keep them together, though we will work on them separately. The team reviewed Draft 29 of the IBIS Interconnect proposal. Bob suggested that interconnect model name is case sensitive, but the actual filename shall be lower case. Regarding whether using “*.ibs” as the format for inline interconnect data: Arpad suggested this was likely the better approach. Bob stated he could go either way with this or with “full_filename.ibs”. The team decided without objection to stay with “*.ibs.” On hierarchy in the document, Bob stated that Die Supply Pads should be grouped with Pin Mapping (which should be in this Chapter); no “[End Die Supply Pads]” keyword is needed. [End Interconnect Model Selector] is consistent with the other Selector keyword. Bob suggests Bus Labels should be in this section; raised the question again of whether we need Bus Labels. We can also assign them indirectly with Pin Mapping, etc., though he has not yet sorted out all the possible indirect connections. Walter stated that, if you want to partition buffers into bus label groups, there’s no way to assign a signal name to that bus label, so there you need the Bus Label keyword. At the pins, in reality, VDD is connected at the pins of the component, but on the die if it’s split or you want to split it, there’s no way to do this without Bus Labels. Bob replied that the issue is that one die pad can be split between two different buffers. Walter observed that, if you put the labels on pins, you imply that the same pin can be connected two different ways. Die Supply Pads can be a partial list; the complete listing rule has been removed. Bob expressed concern about not filling out columns for bus labels, even where signal name is repeated; the specification needs to reinforce bus labels. Walter replied that bus labels are not used in the industry, but no overhead is needed to support them here. Michael asked whether the team should make a rule explicit to cross check label consistency vs. Pin Mapping. Will we ever use additional columns in this keyword? Walter replied that there is a rule in Pin Mapping added by Walter referring to die supply pads and bus labels. Bob added that there is also a rule that declared bus labels shall be used in Pin Mapping. Walter disagreed; bus label divides signals into groups. Bus label could just be under Die Supply Pins. Bob clarified that he was just talking about I/O pins vs. supply pins. I/O pins must have a bus label connection somewhere, or else there is a missing I/O. Walter agreed – every bus label must be associated with a signal name, either with a pin in Pin Mapping, or Die Supply Pads, or through bus labels. Bob noted that the document needs additional rules for either repeating the data book name/signal name OR the bus label. Walter disagreed. Michael suggested taking the discussion offline to develop additional rules. Walter noted an interesting [Pin] name lack of rules – the same pin name can be reused according to the literal specification rules. Bob replied that the parser will likely catch this. Arpad added that, when working on his own package proposal, he tried to use this for pad-multiple splitting. Walter noted that a “duplicate pin” error is indeed generated by parser if duplicate [Pin] names are used. Michael asked whether the team should include a new rule that states each pin name shall be unique. Mike replied it would need to be a BIRD, and that he will write it. On Touchstone terminals and ports, Bob stated that, in a TS file, he defines a line as a node of a port, for example; a two-port arrangement has four lines. “Lines” might be the appropriate verbiage. Walter disagreed, noting that the distinction is clear between ports and nodes. A connection to an S-element is by nodes or terminals; connection to Touchstone is by ports. Number of terminals in number of ports+1. Bob agreed; terminal is the correct verbiage. The team will discuss terminal/reference in the next meeting, along with the remainder of Draft 29. Randy moved to adjourn the meeting. Mike seconded. The meeting adjourned.