I'm sure there are many more examples, but check out the following two URL's to see how some people are fusing Matlab and AMS together: http://www.ece.ul.ie/homepage/ian_grout/utilities.htm (Matlab to AMS conversion utilities) http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=4860&objectType=file (VHDL-AMS simulator written in Matlab) -Ray Muranyi, Arpad wrote: > 1) I wonder how Mathworks would feel if someone rewrote > all their functions and toolboxes for AMS? I think their > reaction would be similar to Synopsys' if we adopted the > EFGH elements in IBIS. > > 2) What would happen if we added another language to IBIS, > Matlab? We can't do it for the same reason we couldn't add > HSPICE. It is a single vendor solution. > > 3) How about Octave? It is a free copycat of Matlab as far > as I understand. > > Arpad > ============================================================ > > ------------------------------------------------------------------------ > *From:* owner-ibis@eda.org [mailto:owner-ibis@eda.org] *On Behalf Of > *Abdulrahman Rafiq > *Sent:* Monday, April 04, 2005 3:33 PM > *To:* ibis@eda.org > *Subject:* Re: [IBIS] *-AMS modeling and hurting companies? > > Indeed Matlab and Simulink are extreemly powerful tools. I don't think > there is anything matlab couldn't simulate.It has been used in far of > fields such as graphics and animation. So I wonder why not further > develop the matlab toolboxes for AMS? > > -Abdulrahman Rafiq > Cisco Systems, Inc > > Muranyi, Arpad wrote: > >> Scott, >> >> Excellent summary. Just wanted to mention that one thing I envy >> about Matlab is the vast amount of functions that they have in >> their various libraries (toolboxes). I think AMS needs to go a >> long way to get there. If we had (or am I just not aware?) such >> libraries, I think the life of a model write would be a lot easier... >> >> I wonder whether this imposes a threat to AMS? Matlab and Simulink >> are quite popular in some high speed circles... >> >> Arpad >> ================================================================== >> >> ------------------------------------------------------------------------ >> *From:* Scott McMorrow [mailto:scott@teraspeed.com] >> *Sent:* Saturday, April 02, 2005 1:38 PM >> *To:* Syed Huq >> *Cc:* Muranyi, Arpad; ibis@eda.org; milabont@cisco.com; >> lgreen22@mindspring.com; steve@teraspeed.com; tom@teraspeed.com; >> al@teraspeed.com; bob@teraspeed.com >> *Subject:* Re: [IBIS] *-AMS modeling and hurting companies? >> >> 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 >> >> > >-- >--------------------------------------------------------------------------- > | | Abdulrahman Rafiq > :|: :|: Hardware/IO-Interconnect Modeling Engineer > :|||: :|||: DSW-Interconnect and Packaging > .:|||||||:...:|||||||:. Direct: (408) 527-5540 > C i s c o S y s t e m s Fax : (408) 526-6603 > www.cisco.com email : arafiq@cisco.com > 800-250-4800 epage : [out of order] > URL1 : http://wwwin-sipd.cisco.com > URL2 : http://wwwin-people.cisco.com/~arafiq > URL3 : http://www.eigroup.org/ibis/ >----------------------------------------------------------------------------- > > > > ----------------------------------------------------------------- |For > help or to subscribe/unsubscribe, email majordomo@eda.org |with the > appropriate command message(s) in the body: | | help | subscribe ibis > | subscribe ibis-users | unsubscribe ibis | unsubscribe ibis-users | > |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 1993 -- Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Dept. Package Engineering Group Xilinx Inc. ----------------------------------------------------------------- |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 Mon Apr 4 15:58:02 2005
This archive was generated by hypermail 2.1.8 : Mon Apr 04 2005 - 15:58:19 PDT