Chris, one of the things I admire about you is you don't bite your tongue. Unfortunately, after seeing these old problems for years with the same potential solutions, I just don't think the political will is ever going to form to do as you recommend. So I keep trying to come up with alternatives that might move forward, as imperfect as they may be. Maybe the solution is for these silicon vendors to develop only very well defined design rules, and tell any customer who wants to deviate that they will have to go to a consulting house with which the silicon vendor has a tight NDA and has opened the kimono. Hey, I am starting to like that idea!!! But for now we are in a gray zone where we have models that provide limited and/or erroneous information, and design guidelines that are insufficient to let an RTL jockey succeed. While I take issues with a lot of the misinformation that makes it into books, I still hold a high regard for anyone who takes the time to write one. The royalties rarely pay for the time required, and right, wrong, or indifferent, they provide a reference whether to support or criticize. I hope that readers understand that just because something makes it into a book, doesn't mean that it is correct. Best Regards, Steve. At 06:38 PM 12/28/2004 -0800, Chris Cheng wrote: >Steve, >The funny thing is I have sat on both sides of customer and vendor table. >And I can tell you it is a myth that Si house won't give out SPICE model. >Yes, it is a Kimono, but it has nothing to do with proprietary information, >it has everything to do with the app or support engineer inability to know >how to generate the right model so they settle for the lowest denominator >which is IBIS. I have faced every single customers and explained to them >what my reference model does and went through up to two days of detail >grilling on each and every capacitance and inductance of the model and why >we put it in there. My team logged the longest simulation hours in the >server farm in a 1000 people division. Enough to have the IT and CAD manager >came down and ask what exactly are we doing. At the end I think I know more >than anyone of my customers can imagine in any of their configurations. > >Let's be serious here, is there anyone in SI-list can tell me he actually >ran some mickey mouse IBIS model their vendor provided them and discover in >his horror that there is too much SSO in a package and therefore avoid a >potential disaster ? All you hear is some babies crying after the fact >pointing fingers at their vendors saying "those chip guys screwed me, they >give me a package that has SSO problem". Well, what do you expect ? > >I am not chill up to my spine when you say people just route to rules. In >fact I think that's the right thing to do. If you are not ready to run like >the big boys, don't try to be cute and go off the beaten path. > >What I think the industry (system designers, chip house, CAD companies) >really need to do is seriously sit down and agree on a common form of >encryption where by the silicon people feel save enough to encrypt their IO >and package models and hand them out. And the EDA companies sit down to >agree to use the same encrypt/decrypt engine so that a SPICE model extracted >from XXX schematic tools can be run on a YYY spice engine. And finally the >system designers to snap out of this false sense of security of mickey mouse >IBIS models and demand and expect nothing less than a circuit description of >the IO and package models if you want to go off the design rules. Otherwise, >keep your mouth shut and stick to the rules. Will this ever happen ? I doubt >it, people like to settle in their own comfort zone, if IBIS is the only >thing they know, that's just the way it will be. > >Until then, the same engineer who thinks he knows everything by running some >mikey mouse models will be the same engineer who whine about how bad his >chip vendor package is. And they can probably write a lot of books about it >too. > > >-----Original Message----- >From: steve weir >To: Chris.Cheng@xxxxxxxxxxxx >Cc: ''si-list@xxxxxxxxxxxxx ' ' >Sent: 12/28/2004 4:35 PM >Subject: Re: [SI-LIST] Re: Article discussion on bad packages > >Chris, that is an interesting story. Well at the end of the day if we >really want to see all of the effects in detail, SPICE with ACCURATE >MODELS >still seems the best albeit slow way to get all the information. But we > >know the objections, including mostly the open Kimono. I just don't see > >people handing out detailed SPICE models to the general design >community. So as the man in black said to Fezzini: "If there can be no > >negotiation, then we are at an impasse." > >As convoluted and technically suboptimal as alternatives may be, unless >the >attitudes on providing detailed SPICE models change, I think we have to >continue down this road. One idea that strikes me is for vendors to >convert the actual I/O models from SPICE to IBIS and then back to effect > >the abstraction. > >The other points that may send a chill up your spine is that the >majority >of the design community is going to want to run on design rules, and not > >detailed and complete analysis that is your custom. For them, 24 hour >H-SPICE runs are not going to be palatable. Piecing out aspects of the >models into different forms that can be individually run at much higher >speeds, I feel does serve a very useful purpose. > >Regards, > > >Steve. > >At 10:24 AM 12/28/2004 -0800, Chris Cheng wrote: > >Steve, > >Believe it or not, I actually have two of the largest SI EDA tool >vendors > >sending me people to investigate what you descript below (on top of >neat > >things like behavioral receiver modeling). They spent nearly a man year >each > >to get to what I think is close enough (10% of SPICE accuracy). At >the > >end of the day with all those additional modeling, the run speed of the > >simulator is slow enough that the so call orders of magnitude faster >than > >SPICE advantage is gone, in some cases it is slower. The time wasted to > >extract the additional parameters needed and the actually fitting of >the > >models to a behavioral engine is longer than simply running the native >SPICE > >model and go home and have fun. It's like the rice rockets kids in my > >neighborhood have. You can put more money and time and effort to make a > >Civic run fast, but I'll take a Corvette or Viper any day. I don't >shoot > >from the hip, I've actually done it before I draw my own conclusion. >And I > >have my customer's negative feedbacks on IBIS to back it up. > >You mind as well put in the requirement to model the modulation of the > >predriver voltage under SSO condition. Case where the pre-driver ground >is > >isolated from the IO ground will be very different from when they are > >common. And I still want someone to give me a correct IBIS model on >Bill > >Gunning's circa 89 GTL driver model with SSO effects. Let's see how you > >model the active feed back from the drain back to the gate while the >pass > >gate is under SSO modulation in a behavioral model. > > > >-----Original Message----- > >From: steve weir > >To: Chris.Cheng@xxxxxxxxxxxx > >Cc: 'si-list@xxxxxxxxxxxxx ' > >Sent: 12/28/2004 1:59 AM > >Subject: Re: [SI-LIST] Re: Article discussion on bad packages > > > >Chris, I think that there are multiple issues, some of which can be > >addressed more easily than others, but ultimately I do see some serious > >problems with IBIS. If we specified the following, I think we would be > >way > >better off than we are today: > > > >1) Signal return references. Easy to specify. If the package guy does > >his > >homework all he needs to do is tell the integrator: > >a. The signal reference plane > >b. S parameters as seen looking into an ideal launch at the package / > >PCB > >interface. > > > >2) Signal crosstalk due to coupled lines. I like the idea of >mixed-mode > >S > >parameters here as well for the closest neighbor or two on each side. > >The > >idea is to avoid having to build up a big matrix of W elements. > > > >3) Signal crosstalk due to common power / ground impedance. This one >is > > > >where I think things are tricky for IBIS. I don't see a good way >around > >an > >equivalent circuit for the common impedance. I think from a practical > >standpoint this is going to require bolting the inductance/capacitance > >matrix onto the front of IBIS models converted to SPICE and dropping > >IBIS. In essence all IBIS is going to get us is a simplified SPICE > >model > >for the drivers. > > > >4) Current profile vs. frequency for core, and I/O. It would be up to > >the > >IC supplier to identify subgroups where each subgroup would be > >considered a > >lumped current source. > > > >5) Some means of feeding back noise voltage versus frequency at the > >package > >/ PCB interface resulting from 4) into 3). If we go the route of a > >SPICE > >model, this is straightforward, if a bit slow. In this case we bolt a > >SPICE model of the PCB attachment planes bypass caps at 3) > > > >I think this is enough to get us pretty close. Unless I have missed > >something ( comments welcome!!! ) we would be able to see: > > > >a) Most multiline crosstalk. > >b) Most common power impedance crosstalk / SSO, including analog if > >specified > >c) A good representation of power as measured at the device / PCB > >boundary > >d) Limited visibility of power at the internal distribution nodes ( > >depends > >on the detail of models provided at 3) ) > > > >What this proposal lacks is an evaluation of absolute voltages inside > >the > >package. My thinking is that the IC vendor could specify one of two > >ways: > > > >a) Absolute voltages at internal nodes where the matrix has been > >provided > >in 3) This is the most accurate, and ultimately I think preferred. > >b) Absolute voltages at the package / PCB interface. With software > >driven > >and/or programmable hardware, I don't think this has very good legs to > >it. > > > > > >I am interested in what stones folks can toss at this proposal. > > > >Regards, > > > > > >Steve. > > > > > >At 02:00 PM 12/27/2004 -0800, Chris Cheng wrote: > > >I am sorry but IBIS for SSO analysis is an oxymoron term for me. Can > >you > > >explain more ? > > > > > >Power and SSO analysis has been done on systems since the 70's. There > >was no > > >commmitte or industrial standard then and people who knows how to do >it > >ask > > >the right question and get the right results. And every package I >have > > >designed is unique and to say there is a generic or standard way to > >model it > > >is beyond my experience. But then again, what do I know ? > > > > > >-----Original Message----- > > >From: Istvan NOVAK > > >To: cgrassosprint1@xxxxxxxxxxxxx; Chris.Cheng@xxxxxxxxxxxx > > >Cc: si-list@xxxxxxxxxxxxx > > >Sent: 12/27/2004 7:50 AM > > >Subject: Re: [SI-LIST] Re: Article discussion on bad packages > > > > > > > > > > > >After the 2004 DesignCon panel discussion on PDN simulations, > > >this kind of standardization started in two independent tracks: > > >one of the IBIS committees and the IEEE TC-12 have been working > > >on proposals to address these issues. If anyone is interested in > > >contributing comments and proposals, please contact me offline > > >so that your effort can be channeled into these ongoing projects. > > > > > >HAPYY HOLIDAYS to everyone. > > > > > >Istvan Novak > > >SUN Microsystems > >------------------------------------------------------------------ > >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: > >http://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: > > http://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: >http://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: > http://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: http://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: http://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