[SI-LIST] Re: package SSN model accuracy requirements

  • From: Mark McKee <mmckee@xxxxxxxxx>
  • To: Chris.Cheng@xxxxxxxxxxxx
  • Date: Wed, 09 Mar 2005 19:56:48 -0800

Chris,
Off the subject of models, but pertinent nevertheless. I have "a little" 
experience in this area so I'd like to toss my 2 cents into the ring.

First,  please don't think that SSN issues and concerns are only with 
respect to FPGA vendors.  I have some very bad experience with very high 
performance memory vendors and other off the shelf parts.  Seems that 
most of the industry vendors think that if there packaging solution that 
worked at 125 MHz with the silicon technology that it took to make that 
work, that they can go to 250 MHz and beyond - to SERDES etc. and it'll 
still work.  Some packages I've looked at are incredibly scary!

Second,  to answer your question, what we've been forced to do because 
of these problems, and problems with FPGA's, is

a) Request the MCM files or at a minimum a review of them - stackup and 
layout for signals and vias from the balls to the silicon - we 
eliminated at least 1 FPGA vender just on the review of their stack up 
and how the power and ground pins made it from the balls to the silicon 
at least for 1 design - beware, what looks good for pinouts (a the 
balls) is often very bad from an overall good (SI and SSO) design. 
 Guaranteed - if you don't treat this like a PCB, you will be burned 
badly in the very near future.

b) If you can, then use a tool like Sigrity to extract a portion of the 
package (or whole thing if you have the CPU horsepower to simulate it) 
convert it to SPICE and simulate it.  I believe several authorities on 
this alias would agree, since the packages are getting bigger, they are 
now the dominating factor in overall board and system performance and 
therefore, it should be considered in the same fashion as any other part 
of the overall packaging solution.

Third, at least 1 FPGA vender has done an excellent job on the design 
and analysis of a new package from taking these things into 
consideration - I won't mention vendors on a large alias like this but 
ask the basic questions, consider the package as a very big part of your 
overall solution and you'll figure out who's got it right.  I'm not 
trying hide anything but feel inclined to let the (current) obvious come 
out on it's own, and the vendors often have a time leap frogging each 
other so we just have to teach them that they must share, what is 
important to us or we'll go somewhere else.  All part of helping them 
grow to meet our needs I guess.

Happy hunting,

Mark
Chris Cheng wrote:

>Ray,
>That's a good point. 
>
>Once again, I am a true n00b on FPGA's so please tell me how a typical SSO
>analysis a vendor provide to the customer then ?
>
>Is is an IBIS package model combine with SPICE model of the driver receiver
>?
>Or is it just a set of IBIS package with IBIS I/O model and some "best
>wishes, I think it will work" ?
>
>I keep hearing in the recent threads about SSO noise in FPGA packages but I
>have yet to hear customers of FPGA came out and say "we've done the SSO
>analysis, this package will work" or "we've done the SSO analysis, this
>package will not work and we avoided a disater". 
>
>Can someone share with me how exactly a customer of FPGA is expected to do
>SSO analysis ? 
>
>If you tell me you don't since "I've done it for ten years and it worked so
>it will work in the future". That's fine with me too.
>
>But it will not be fair to say, "my vendor screw me and I have a noisy SSO
>package" but yet you have done nothing to simulate the noise ahead of time.
>
>I have to admit I am an ASIC kinda guy with my own I/O and package design.
>Lately I am feeling the heat to look into more generic solutions like FPGA
>so I am personally curious about how people really do it.
>
>-----Original Message-----
>From: Ray Anderson [mailto:ray.anderson@xxxxxxxxxx]
>Sent: Wednesday, March 09, 2005 8:48 AM
>To: si-list@xxxxxxxxxxxxx
>Subject: [SI-LIST] Re: package SSN model accuracy requirements
>
>
>Chris-
>
>I think you may be misinterpreting what Lynne and the other posters in 
>this thread have been discussing so far.
>
>No one seems to be saying that SSO simulations should be done with IBIS 
>(as it stands today).
>
>The discussion is centered around the various package models. An IBIS 
>model consists of the silicon model portion and the package model 
>portion. One can take the package model portion (that is described in 
>IBIS syntax) and rewrite it in Spice syntax if you so desire. So while 
>some of the statements earlier in the thread may have referenced "IBIS 
>lumped models" and "IBIS ICM" models, the crux of the discussion is 
>related to model topologies, model complexity, model bandwidth, and 
>model size where the "model" in question is the package model. All of 
>these model attributes are relevant to SSO simulations regardless of 
>what you choose as the silicon driver model.
>
>-Ray
>
>
>
>Chris Cheng wrote:
>
>  
>
>>You can say what you want with IBIS, at the end of the day (today, not
>>tomorrow or some future spec), can you do an SSO analysis based on a pure
>>IBIS model ?
>>
>>I am a complete N00b on FPGA so I am curious how many people really do SSO
>>analysis with just a standard IBIS description of a chip. I can't, so
>>    
>>
>please
>  
>
>>tell me how you did it.
>>
>>Those who know me and my previous life somewhere should remember some of
>>those reference SPICE SSO models I generated, there is only a small number
>>of SPICE drivers, interconnect and receivers set that need to be included
>>    
>>
>to
>  
>
>>accurately model SSO, x-talk, package/interconnect loss. Remember, m=x is a
>>very powerful macro that doesn't even need to be an integer.
>>
>>Another interesting side note, some of the so call speedy "IBIS engines"
>>    
>>
>end
>  
>
>>up barely faster or even slower in some cases when the same interconnect
>>complexity is added to get the accuracy close to acceptable level. 
>>
>>All of the above SSO modelling methodolgies are well documented and
>>correlated with actual characterization numbers. I am not talking about
>>vaporware analysis here.
>> 
>>
>>    
>>
>
>
>  
>



------------------------------------------------------------------
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
  

Other related posts: