====================================================================== 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 August 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*, Ming Yan 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. Review of ARs: Review of Minutes: Michael called for review of the minutes from the August 3 meeting. Mike moved to approve. Randy seconded. The minutes were approved without objection. Opens: Michael reviewed the two open questions from the last meeting. The first is how [Interconnect Model Set]s are scoped and whether they should be encapsulated or not. And the second is how to handle multiple overlapping sets. Mike raised an open about the terminal type association work that was done a few weeks back. He thought Walter had started a new version, but he could not find it to post. He will double check and will get it posted. Michael mentioned he will need to drop off the call at 8:30 Pacific Time, and this will likely be the case for future meetings as well. Randy mentioned he had a couple slides with an example of using the Interconnect BIRD to aid the discussion. Micron Package Model Example: Randy started on slide 2 which shows the ballout for a Graphics Memory device. It has both high speed and low speed signals with different package model types highlighted in different colors. Red is a high speed data bus. Note the symmetry in the four quadrants of the package, so one S-parameter model could be used for each quadrant of the data signals. Options for this S-parameter model could include just signals with VSS as the reference, or could also include signals and VDDQ in Touchstone 2.0 format with VSS as a reference. Also, you could have uncoupled S-parameter models for each data signal. Randy envisioned he might have a fully coupled spice subcircuit model for the lower speed Address/Command signals in the middle of the package. The signals he has highlighted in purple are very low speed JTAG signals which could be modeled with simple pin parasitics. You could also have a PDN model for VDDQ and VDD with VSS as the reference. A second option would be the complete fully coupled package model similar to what is in IBIS now. On slide 3, Randy listed some questions for discussion. There could be some reuse with different signal names with different instantiations. There is a question on the amount of reuse and this example might be the most reuse that Micron would do. He wondered what should be included within a single set, and what should be included in one set versus multiple sets. He also posed the question of what are overlapping [Interconnect Model]s useful for. Walter said that there is no advantage of scoping outside of the set. And, that a set does not necessarily need to contain all of the package pins. The sets should be more about how to organize the [Interconnect Model]s. Randy asked if the model has overlapping sets such as both coupled and uncoupled models, how does the EDA tool handle those cases. Walter said there are 4 sets of DQs in the package example. For example, the single ended model for DQ1 and DQ9 could have the same S-parameter model. In the set, each would have their own model. One could also create a model for each quadrant of the package. The question is if both models should be in the same set. Walter mentioned he doesn't think we should prohibit that, but you would have to rely on the EDA tool to set up the simulation correctly. The EDA tool would have to decide between the two types of models in the set. The tool could find the smallest model that contains all the signals of interest by the user. Putting in different sets means that the model maker is giving the decision to the user to choose between the sets. Randy asked if we need to include the other signals in each set. Walter commented that he prefers them in separate sets. But, you could include multiple combinations of signal and PDN sets. But he prefers separate sets. Bob commented that within each set, he would not have the same IO pin referenced, as it could create multiple paths. A set should be self contained. You would will still need to instantiate each set, as there are connections to each of pins and they need distinct sets for each signal. Walter said, back to the point about multiple models with same path, not all tools will support coupled models. Using the one quadrant with 10 DQ signals as an example, but lets say a tool can only do one victim with two aggressors. A user may want to look at different sets of DQs to look at cross talk. There is some burden on the EDA tool to make these decisions. Bob asked who determines whether a signal is a victim or aggressor. Walter answered that it is determined by the model maker, but there could be different sets with different victims. Bob replied that the model maker should not have to provide all combinations of aggressors, but that this is a separate issue. Bob went on to mention that the low speed signals would not need to use the [Interconnect Model] format and these should default to the [Pin] RLC values. There is no reason to bring in a spice model for low speed signals. He commented that there are a number of choices for package models. Randy clarified that Option 2 in his example is similar to the existing matrix style model and that Option 1 is PDN only. Bob commented that all pins of the package that are relevant should be included in the sets. You can have dedicated sets with coupling for cross talk simulations. Each of the IO [Interconnect Model]s would contain a reference. The question is should we bring in the PDN as a set or just use the fully coupled model. There can be trade-offs to the size of the file. Mike noted that both proposals can do the same things in terms of functionality. But the differences are mainly in convenience and risk. He asked Randy if the exercise of looking at this example helped point to one direction versus the other. Randy said that it comes down to what he needs to include and how many multiple combinations are useful to include. And, it is still not yet clear to him how many sets he needs to implement. Mike commented that there is no real advantage between either approach for the quadrant example. The only difference is a few lines in the IBIS file. Walter stated that reuse is interesting when you have say high speed signals, low speed signals, and PDN in various combinations. If you put the PDN model into a separate set, then you can use multiple sets. The PDN is the key type of model where you would want to have overlapping sets. But, the main difference between the two approaches is in the naming of the [Interconnect Model]s and the possibility of collisions. And this is a compelling reason to scope the models by [Interconnect Model Set]. Mike thought the size difference between the two approaches would be small in most cases that he envisions. Bob commented that we are making assumptions that multiple sets will be used. And, he noted that using the by reference approach could significantly reduce the file size. Walter commented that it is not necessary to have a set for each pin. Bob noted that different model makers might have different strategies for creating efficient files, and you don't have to combine things into single sets. Arpad asked about the decision to encapsulate and mentioned that he requested some opinions internally. He thought it would be helpful to have a more complete example implemented in each approach, so that Mentor Graphics could compare them side by side and see what it would take to write code to parse each one. Walter mentioned that his IMS.pdf presentation from last week has this type of example for his approach. And he agreed that it is key for the EDA companies to take a look at both approaches, since they will have to implement the one that is chosen. Arpad and Walter called on Bob to provide a similar example. Mike wondered what we can and should do to make the default [Interconnect Model Set] the most useful and how to descried what the use for each set is. Walter noted that package modeling is complicated, and the model maker needs to describe the sets in some sort of documentation. Walter moved to adjourn. Arpad seconded. The meeting adjourned without objection.