================================================================================ 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 9, 2018 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. Randy Wolff took minutes. Review of Minutes: - Michael called for review of the minutes from the February 7 meeting. Randy moved to approve the minutes. Mike seconded. The minutes were approved without objection. Review of ARs: - Arpad to draw up a diagram to illustrate the potential issue with the Micron decoupling model - Arpad reported this is not done. He may complete it before the end of the meeting for discussion. Opens: Michael asked Mike if the latest document has been sent to the reflector. Mike noted the latest draft is BIRD189.5_draft17_v1 and was sent out. Michael asked if any additional comments have been sent out to the reflector. Bob replied that he thinks all the comments are in the draft document. BIRD189.5_draft17_v1 review: Mike asked the difference between marking comments resolved versus deleting them. He has been deleting them. Michael clarified he was asking if mark ups just need to be accepted. Mike noted he has been keeping mark ups and we could post a document showing all the changes from draft 4 to draft 5. Michael noted the first comment from Bob is about insufficient rules on Aggressor_Only. Bob noted rules by themselves would not capture the fact that if you marked Agggessor_Only on just the die pad side of two models, wiht one model linking buffer to pad and the other linking pad to pin, the case isn't covered. Two models can connect together without aggressors marked in both models. Mike asked Bob to come up with two extra bullets to capture the case he is describing [AR]. Bob noted if we have a missing segment there is additional ambiguity. This could get bogged down. Bob noted he advocated for, but it was voted down, to separate different simulation conditions into different groups. Bob noted additional bullets might be needed. Walter asked for an explanation in words. Bob noted he sent out an email explaining it. For example, interconnect model A going from buffer to pad has Aggressor_Only on it for pin 1, but interconnect model B from pin to pad does not have an aggressor on it, but they are supposed to be connected because we don't specify through paths for models. We have models C and D with the opposite case. He has complied with the highlighted rules, one buffer with aggressor only and one pin with aggressor only, but there are two interconnect model paths with two pin 1 connections. Bob implied connection to pad_name is the same but there is one model with Aggressor_Only at both pin and pad but the other doesn't at have that label for pad to buffer. Arpad noted the implication is that the regarding fate of two bullets deleted last time, if those rules are still in effect you can't have more than one victim of a pin but can have more than one aggressor. Michael asked if we need to have a parse-able rule. If we have 3 lines in model A from buffer to pad and 2 lines in model B from pad to pin, do we have to parse through it if any pads are shared and prohibit it? Bob noted he is not sure about the 2 and 3 line part. The omission of the Aggressor_Only part of it complicates the connection. The main point is different vendors in the extreme can create the two separate models as described. Walter commented the case Bob is talking about would violate another rule. A pin would be a victim in two different models. Arpad thought the complication is if we had rules in place we deleted last time about a pin only being one victim but can have multiple aggressors, package and on-die interconnect models can get out of sync. Walter noted he didn't think we deleted the rule about a victim can't appear in more than one model. Walter asked to see the exact example to discuss the issue. Bob noted a February 6 email from him described the example. Michael noted there are many comments related to deleted text. Arpad stated he wasn't sure if all the text should be deleted. Mike recalled we spent more than one meeting talking about the bullets in questions. Randy noted we voted on removing this text, so we should ignore the comments since the text is deleted. Michael asked about a comment on the word "single". It was agreed to remove the word. Michael noted a comment of "Awkward English". He suggested changing "the" to "that" and remove "in order for the rules to be satisfied". Mike noted the set is created to deliver groups of interconnect models. Once they are used, the participation in the set hardly matters, it just matters interconnect models end up in a group. Walter commented the whole point is that if a rule is satisfied in a group it has to be satisfied in individual sets. Bob asked if we deleted the whole note, would we lose anything. Walter replied no. Mike noted it kind of points out a mathematical corollary that isn't needed. Mike added unless we can think of an example that can violate it, then it isn't needed. Bob stated we can have two sets where each set doesn't comply with group rules, but taken together they do comply with group rules. Bob thought of adding a clause to the first sentence and delete the second sentence. Michael added the phrase ", regardless of which Interconnect Model Sets contain the Interconnect Models." Arpad showed his figure. Can we have an interconnect model that describes the package and another interconnect model that describes on-die decoupling, and they can connect to the same terminals? The figure shows decoupling between VDD and VSS on die. Arpad thought there was a rule disallowing multiple models connecting to the same terminals. Walter said this is a pin/buffer rule. Bob thought we don't have to have the rule for supplies, since we can have multiple ideal interconnect terminals for rails. Randy described the example as having a package model connecting power and ground from pin to buffer rails. Then, there is a simple on-die decoupling capacitor connecting between the two buffer power and ground rail terminals. Walter took an AR to sketch out the proposed solution to modeling this example. Next Meeting: The next meeting will be February 14. Mike moved to adjourn. Bob seconded. The meeting adjourned without objection. Task List BIRD189.5 editorial additions/changes to be completed: