Hi Scott, Very detailed and long Email indeed. I will briefly make two short comments: >.. It remains to be seen if vendors can provide AMS models of their > devices which have good correlation to measurements.... We will show HSPICE, Lab Measurements, AMS(IBISv4.1) correlations for a 3.125Gbps SerDes Channel with benchmarking results at the Mentor Users Group Seminar on Apr27th (www.mentor.com). It will be quite exciting for any current and future IBIS users who have a little doubt about what capabilities IBISv4.1 can have with *AMS support. >..that the implied assumption that AMS modeling will somehow solve >all of our IBIS modeling problems is sorely mistaken. I am not sure who is making this implied assumption. But the capabilities we have already experienced with IBISv4.1(*AMS)is exciting enough for us to try this new scheme in many correlation exercises we are currently defining. More to be shared with the IBIS community in time. IBISv4.1(*AMS), BIRD95, BIRD97 etc are all pointing in the right direction to solve all the complex issues we face today. - Syed Cisco Systems, Inc On Sat, 2005-04-02 at 13:38, Scott McMorrow wrote: > Syed > > I have a number of comments, which I am copying to the IBIS community, > because I think they have general applicability to all IBIS futures > discussions. > > Syed Huq wrote: > > Matlab cannot do a post layout simulation but there are EDA tools with > > AMS support that can. > > > You are mixing capabilities. Neither can AMS do a post layout > simulation. However, tools have chosen to loosely integrate AMS into > their post-layout board flow. At the same time, there is at least one > EDA vendor that I know of which is also looking at integrating Matlab > into their post-layout flow as well. Why? Because there are a number > of SERDES vendors who have endorsed Matlab as the standard simulation > vehicle for their devices. Matlab has proved to provide simulation > support for stochastic processes, which is essential for verification > of the extremely low BER channels that are being designed today. It > is a reasonable alternative to other proprietary communication system > simulation environments, including Ansoft Designer, Agilent ADS and > Cadence MGH (I believe that is what it's called), especially when it > is supported by some major silicon vendors and their validated > models.. > > Encrypted HSPICE on a post layout simulation is not practical > > considering the same with AMS can run 275X faster ! > > > You are correct in saying that AMS can sometimes run significantly > faster than HSPICE encrypted models. (See other discussions of this > below.) The question becomes, is that a true determining factor given > the significant approximations and model reduction that must be done > to accomplish a full board post-layout simulation? AMS certainly has > the capability of providing simulation support for pretty much > anything. There's no doubt about that. But, as I see it, there are > several complementary issues that first must be looked at: > 1. Do the capabilities of device modeling necessarily translate > into a better, or more accurate, simulation? > * Certainly the potential is there. But all modeling is > an approximation. It remains to be seen if vendors > can provide AMS models of their devices which have > good correlation to measurements. Mentor's experience > with Altera Stratix is a good start. However, as we > all know, even in the IBIS 3.2 world there are some > very good models out there with extremely high > correlation to measurement, and some extremely bad > models that have absolutely no relationship to a real > device. However, I do agree that the potential is > there. > 2. Can the board level tools accurately simulate a system with > advanced AMS models and provide accurate results? > * Lets start with HSPICE as the baseline. Certainly > SiSoft, Sigrity, Mentor and Cadence, among others, can > simulate nets extracted from full board layouts. So, > it safe to say that if an AMS version of the same > model is available, at no accuracy loss from the > original, then the AMS simulation has the potential of > the same accuracy at higher simulation throughput. On > the surface this seems to be a good thing. > * However, when one looks at the class of models that a > designer would like to simulate with HSPICE (or > Matlab) instead of IBIS, there are several very clear > classes of simulation problems that can be observed: > * Advanced SERDES devices with driver and > receiver equalization, including preemphasis, > deemphasis, multi-tap FIR filtering at both > the driver and receiver, along with DFE and > adaptive closed loop out-of-band control. > * Drivers with on-chip PVT compensation, of both > the analog and digital varieties. > * Multi-driver/multi-receiver SSO and SSI > simulations ... including driver and receiver > noise and slew rate push out. > * Others that my feeble mind cannot think of at > the moment ...? > > * Let's look at these in reverse order: > * SSO/SSI ... including driver and receiver > noise and skew rate push out > * For accurate SSO/SSI simulations a > simulator must be able to accurately > model the driver and receiver > electronics, the predriver circuitry, > the I/O delivery system from the PCB > back through the package to the > silicon, vias stacks, antipads, balls, > capacitors, and all subsequent trace > modeling. > * These models must include the full > partial inductance loop and not reduce > them into a transmission line > equivalent loop inductance. This > means that the simulator must be > capable of modeling interconnect with > only one connection to an absolute > voltage reference node (SPICE node 0) > in the circuit, not multiple > connections like many board level > model extractors do. > * There is no reason why an AMS device > model cannot be used in this type of > simulation. However, the only > board/package level time domain signal > integrity tool that comes even close > to modeling an SSO/SSI problem > correctly is Sigrity Speed 2000. > Other board level SI tools that I know > of will currently incorrectly model > the extremely critical signal and > power return paths. > * However, if I had a highly accurate > AMS model that replicated the full > HSPICE driver/receiver behavior as > outlined above, I would then wonder > what it's performance w.r.t. the > original model would be? Probably not > 275X. No one that I know of has yet > benchmarked an AMS model with such > complexity and correlated it to either > measurements or the original SPICE. > SPICE simulation time is generally > proportional to the complexity of the > things being modeled. There is > nothing inherently faster about the > computational numerics of an AMS > language. In fact, I would suspect > that for the equivalent behavioral > modeling block, AMS is actually slower > than other approaches, because it is a > general language and is not optimized > for specific elements as something > like SPICE is. (For example, a > B-element in HSPICE should be > significantly faster then a B-element > created out of AMS primitives.) The > appeal of AMS is it's generality. > However, once an apples-to-apples > comparison of a complete I/O driver > cell including: core power, predriver > behavior, I/O cell behavior, I/O power > and full return path modeling is > available, I will be interested in > seeing it compared to the original > SPICE model for accuracy and > simulation throughput. The question > in my mind is not whether an AMS > language can provide full modeling of > the SSO/SSI problem, it is rather > whether the problem can be abstracted > to a model order reduced level where > an AMS simulation has a performance > advantage over SPICE, with > near-equivalent accuracy. This is a > point that I would consider a good > topic for some serious academic > research. > * PVT compensation > * Here's a place where AMS could > potentially shine. In SPICE, digital > PVT compensation circuits run > extremely slow, because they are state > machines. They are not particularly > difficult to implement behaviorally > with a digital-analog event-driven > simulator. But, they are often > closely guarded IP. As such, it will > be important for silicon vendors to be > able to protect the IP in some way. I > take it as an article of faith that > the AMS model of a basic PVT > compensated buffer will always be > faster then the SPICE equivalent. > However, I do not take it as a given > that when the same buffer is fully > modeled for all power, ground, control > and signal paths that it will > necessarily be faster than the > original SPICE model. I'm not from > Missouri, but Show-me anyway. > * Advanced SERDES and communication links > * Equalization circuits of all sorts > lend themselves to an AMS language > naturally. I'll take that as a > statement of fact. Matlab has such a > current lead here, because it can > approach the problem from both the > time domain with an algebraic language > and from the frequency domain with a > matrix language, FFT, iFFT and > convolution techniques. Additionally, > a bit of stochastic process work can > be thrown into the mix for jitter and > BER analysis. > * On the other hand, there is no reason > why AMS cannot be used similarly. It > has apparently made some inroads in > the academic community in the modeling > of wireless communication channels and > compares favorably with ADS > simulations. The great hope is that > we might have seamless integration of > AMS into a board level signal > integrity tool and obtain the holy > grail: A turnkey high performance > differential > time-domain/frequency-domain baseband > communication system simulator that > works from multiple extracted board > databases, and seamlessly integrates > all of the disparate pieces from > multiple modeling environments. > * However, there are some current issues > with today's board level signal > integrity tools: > * Trace parametric extraction is > mediocre at best. For > accurate simulation of > differential communication > channels, the frequency > dependent behavior of traces > is extremely important. > Especially important in Sonet > architectures are the > amplitude and phase delay > characteristics w.r.t. > frequency across an extremely > wide bandwidth (80:1). Trace > parametric modeling for all of > the current tools utilize BEM > or MOM solvers which > inaccurately extract the > necessary broadband parameters > and feed them to one of > several variants of the > w-element algorithm or other > rational approximation, where > they are additionally > distorted, unless specific > means are taken in the > algorithm to provide causality > and passivity correction. > * Measurement-based methods of > entering trace parameters > through s-parameters or other > lossy modeling methods suffer > from the inability to model > worst-case parametric corners, > and to easily sweep the > results across various channel > lengths. > * Padstack and viastack > extraction is abominable. > Current approaches in all of > the board level SI tools are > either absolutely incorrect, > inadequate, or limited by the > spatial complexity of the > problem, using crude lumped > element approximations, > infinite return path > approximations for the > frequency dependent behavior > of vias, other incorrect > return path assumptions, no > consideration of the fullwave > behavior of a via or pad > in-system at all, or even a > simple lumped capacitor > approximation. Many of the > current SI tool approachs for > via and pad modeling are dead > wrong and have limited > applicability to signaling > above 1 GHz. > * Simulations of the boundary > areas between the PCBs, > connectors and packages fail > to take into account the > electromagnetic interactions > between each structure. A > clear cut boundary is drawn > between each element, which is > not as clear cut as it might > at first pass seem, and > significantly effects the > final broadband result. This > is not a simple problem and is > currently one that is only > solved by true 3D solvers, > like Ansoft HFSS and CST MWS. > * Poor SSO/SSI modeling as > indicated in the section > above. > * Most mis correlations between > simulation and measurement > fall into one of these four > areas. As such, even a faster > AMS model in a board level SI > tool may only give the wrong > result faster. (The same > comments apply to HSPICE > simulations which have the > same passive modeling > defects.) > > > > > > We use both Matlab and Encr-HSPICE and would opt for AMS anyday. > > > I suspect you mean that you would use AMS any day over Matlab and > HSPICE if the results you achieved were comparable and correlated to > measurement, if the simulation performance was better, and if the > integration into your tool environment was equivalent to or better > than other alternatives. Otherwise, there would be no reason to > switch. > > I am not adverse to gloriously supporting VHDL-AMS or Verilog-AMS as > the language of choice for future IBIS modeling of super nifty > advanced silicon. (We probably do need to hitch our wagon to one or > the other, to avoid dilution of modeling effort.) I do, however, want > to state on the record, that the implied assumption that AMS modeling > will somehow solve all of our IBIS modeling problems is sorely > mistaken. Interaction between the silicon and that pesky passive > interconnect must be dealt with simultaneously, if we are to believe > that our simulation results have true high-fidelity to measured > results. > > The good news for me, is that at Teraspeed® Consulting, we've solved > the problems of accurate interconnect modeling and subsequent > correlation to measurement in both the time and frequency domain from > DC to 40 GHz. If we had VHDL-AMS models of the silicon, and an > appropriate simulation environment, we could significantly enhance our > capabilities and start verifying those 40 Gbps designs of the near > future. Or we could just wait for those HSPICE simulation runs to > complete. > > > best regards, > > scott > > -- > Scott McMorrow > Grand Poobah > Teraspeed Consulting Group LLC > 121 North River Drive > Narragansett, RI 02882 > (401) 284-1827 Business > (401) 284-1840 Fax > > http://www.teraspeed.com > > Teraspeed® is the registered service mark of > Teraspeed Consulting Group LLC ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or email a request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993Received on Sun Apr 3 16:11:53 2005
This archive was generated by hypermail 2.1.8 : Sun Apr 03 2005 - 16:14:43 PDT