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: o 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. o Drivers with on-chip PVT compensation, of both the analog and digital varieties. o Multi-driver/multi-receiver SSO and SSI simulations ... including driver and receiver noise and slew rate push out. o Others that my feeble mind cannot think of at the moment ...? * Let's look at these in reverse order: o *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. o *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. o *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 Sat Apr 2 13:38:22 2005
This archive was generated by hypermail 2.1.8 : Sat Apr 02 2005 - 13:40:53 PST