Ray and Vadim, This seems to remain a good discussion so let's continue. I open my mouth in this thread by starting on my own curiosity on how real designers, not tool vendors or Si app people think on how to do analyze SSO in actual system now. I have yet to hear a single designer in this board standing up and say he/she is doing SSO analysis TODAY with a tool other than SPICE. If I am incorrect, please come forth and correct me. Sure I hear promises of a magic spec that can do it in the future and great tools that will speed things up a 1000 times faster. Has anyone actually done it yet ? Well, I know one, me. While my own experience could be obsolete or dated, that's how I have to draw my own conclusion. Like I say many times before, I don't shoot from my hip, I have to do it and get my own experience before I say anything about it. If you have your own experience and contradict mine, great ! I love to hear it and please share with me. I want to learn from your experience and elighten mine. What I can't accept is statements like "I think this will be better blah blah blah" but you have zero experience and data to back it up. And my experiences included the following : a behavioral model that can model real SSO noise that can correlate with both SPICE and lab measurement, a behavioral model that can model a unique receiver that I believe will be even more important for >2G I/O since there will be substantial equalization at the receiver level (i.e. the eye will fail at pin but will be properly received after equalization inside the Si). Lot's of very smart people and big name EDA tool vendors helped me out and at the end of the day, both objectives has been achieved. However, when I sat back and looked at the experience I had to ask myself "was it worth it ?" When it was all said and done, in order to achieve the criteria I set up (not some hypothetical benchmark by some standard committees but actual correlation with real Si measurement in lab), the effort to extract the correct model and the speed up (or slow down in some cases vs. SPICE simulation) just make it not that attractive. Especially the behavioral abstraction of receiver part where a simple SPICE circuit out perform the behavioral model hands down. YMMV but that's my own experiences, not some promises from tool vendors or standard committee. And that was more than 7 years ago. What takes the rest of the industry so long to even attempt to model SSO beyond SPICE sadden me. What takes you guys so long ? I have heard of many horror stories about SSO noise for the pass seven years. What did people do to predict these problems other than using SPICE ? I really want to know. You may not agree with my opinions. But at least I deserved the credit for trying to work my problem out from the other side. I actually tried to handle my analysis using behavioral models. Have you even tried beyond making some hypothetical spec ? Do you have any real design data TODAY to back up your claims ? I would like to end once again with a polite request for the answers to any Si vendors and Michael in particular : a) Does your company believe these so call secondary effects like package parasitics and SSO will impact your I/O performance ? b) Does your company feels it is necessary to provide a model that can model and analyze these effect correctly ? c) What model is provided TODAY to address those analysis needs ? d) What CAD tool is currently supporting those models so that your customers can analyze the problem accurately ? -----Original Message----- From: Ray Anderson To: si-list@xxxxxxxxxxxxx Sent: 3/12/2005 8:59 AM Subject: [SI-LIST] Re: package SSN model accuracy requirements This conversation regarding what are the kinds of models and/or simulators required to do effective SSN simulations along with the obligatory Spice vs IBIS discussion has been most interesting and informative. This is a issue just about all concerned with SI issues (model users, model providers and EDA tool vendors) have a vested interest in seeing resolved with a workable solution. I have to agree with Chris and Vadim (and possible others) who mentioned that we need a workable solution now (today) that is supported by the tools that the majority of the SI community is using. I think we can all acknowledge that none of the solutions available today are what we could call optimal solutions (they are either too slow, too inaccurate, too complex, too simplistic, require tools that very few have access to, or suffer from some other perceived flaw). However the reality is that there are designs on the drawing board that need to be simulated today (not next quarter or next year or whenever) to verify that they are going to work correctly. Marketing has very little sympathy for a missed window of opportunity because the designers needed an extra year or so for some, as of yet, unidentified development in modeling so that they can get an extra 10% accuracy in the SSN simulations. The long term solutions that are being discussed (new simulators, behavioral modeling advancements, languages standards and so forth) are necessary and ultimately will lead to a better (whatever that means) solution sometime in the future. These ongoing developments are necessary to get to where we need to go, but unfortunately they don't have a great impact on the need to have usable simulations today. So it seems that the problem can be divided into a tactical component (a "good enough" or adequate solution) for today's designs, and a long-term strategic solution that might take a long time to eventually become available but will be technically more elegant, accurate and faster. How good "good enough" is is debatable and it depends on the user's requirements. If you use a 'legacy' 3.2 style IBIS model and are able to get an answer within 25% of the true answer in 5 minutes is that preferable to using an encrypted Hspice model that could provide an answer with 5% accuracy after a 20 hour simulation run? I think the answer is that it depends on what you need from the answer. Most of the above discussion has focused on the format of the buffer model and havn' addressed the packaging parasitic part of the issue. In that arena we have the choice of lumped, distributed, coupled, uncoupled, n-port s-parameter and probably other formats as well. Depending on the use (timing and crosstalk simulations vs SSN simulations vs eye-diagram sims) the optimum format may differ. (is anyone supplying s-parameter based n-port models for SSN simulations today??)(and if they are, do the majority of the users know how to use them?) With the above in mind, perhaps we can discuss what silicon vendors can provide to customers today for today's problems. Some companies provide Hspice models, some IBIS models and some provide both of the above to allow the customer to make the ultimate decision as to which model makes sense for their situation. With the current state of the simulation landscape that exists today with respect to SSN simulations it seems to me that providing models in both formats and letting the customer do the tradeoff decision (accuracy vs speed vs whatever) is one workable solution. I'm sure others have other opinions. Chris seems to favor Hspice models for doing SSN simulations (certainly an option), Gary is a proponent of Eldo, AMS and n-port package models does anyone else have opinions on what other solutions for SSN simulations (or what works for them) are out there that can be utilized today (are IBIS 3.2 models "good enough" for SSN today??) ? Regards, -Ray Senior Signal Integrity Staff Engineer Advanced Package Development R&D Xilinx Inc. ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List FAQ wiki page is located at: http://si-list.org/wiki/wiki.pl?Si-List_FAQ List technical documents are available at: http://www.si-list.org List archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List FAQ wiki page is located at: http://si-list.org/wiki/wiki.pl?Si-List_FAQ List technical documents are available at: http://www.si-list.org List archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu