 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsElectronicsBasicsRepairDesignCADComponentsEquipmentElectrical Engineering ElectronicsKB.com Contact UsLink To UsSearch & Site Map |
Electronics Forum / CAD / January 2006Spice Accelerator Hardware?
Dear Friends, I'm very new in using Spice. Is there any accelerator hardware that speeds up the simulation of circuits? Best Regards! > Dear Friends, > I'm very new in using Spice. Is there any accelerator hardware that > speeds up the simulation of circuits? > > Best Regards! These people claim they've licked the partitioning of a Spice Simulation up into multiple processors running multiple copies of your own Spice Simulators. They claim a nearly linear increase in speed by adding more processors. http://www.xoomsys.com/ Wouldn't know. Robert Many years ago, Inmos speeded up their SPICE simulations (they were using a VAX) by porting SPICE to a transputer array. You might be able to use a high-end graphics card as an accelerator. It would be a lot of work, though. Leon Hi Leon, Your idea of using a graphics card seems to be interesting. Maybe it could be a nice theme for a graduating project or even a PhD thesis... Thanks a lot! >Dear Friends, > I'm very new in using Spice. Is there any accelerator hardware that >speeds up the simulation of circuits? Chances are you are best off with: Buy a very fast PC with a large amount of RAM. Ideally it should have the 64 bit CPU. Install SuSE 10 for 64 bit, wine and LTSpice. I've run LTSpice on 4 OSes and it appears that the speed is: Win-XP Slowest \ Call it a tie because I'm not Win-98 Slowest / sure which was faster Suse-9.2 32 bit Suse-9.3 64 bit Fastest If you are using XP make sure that the spice is not running in "98 compatible mode". That mode slows things down a lot. There are a bunch of other things you can do to speed things up under XP. Tell your IT guy what you need. He should be able to speed things up a bit (given perhaps a week).  Signature-- kensmith@rahul.net forging knowledge >>Dear Friends, >> I'm very new in using Spice. Is there any accelerator hardware that [quoted text clipped - 19 lines] > what you need. He should be able to speed things up a bit (given perhaps > a week). And then there's always the Intel vs. AMD difference. They benchmarked PSpice back where I worked a number of years ago and found a significant speedup with the AMD CPU. But that was quite a while ago. Don't know if it holds nowadays. Robert [snip] >And then there's always the Intel vs. AMD difference. They benchmarked >PSpice back where I worked a number of years ago and found a significant >speedup with the AMD CPU. But that was quite a while ago. Don't know if it >holds nowadays. > >Robert You are correct. P3 -> P4 = Slower PSpice by more than 1/2 AMD is now roughly 8-9X faster than an equivalent speed P4, when running PSpice. Also an observation, don't know if it's real or happenstance, Win2K is MUCH more stable on my AMD machine than on my P4 machine. ...Jim Thompson | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | | http://www.analog-innovations.com | 1962 | "Winners never quit, quitters never win", Jack Bradley Budnik ~1956 > [snip] >> [quoted text clipped - 16 lines] > > ...Jim Thompson I'd assume PSpice uses a lot of floating point calculations. Intel's always favored Integer and general CPU operations over floating point given their target markets so their floating point performance always sucked compared to the competition. And it's gotten worse with the P3 -> P4 transition. Relatively speaking. Then again, they fell down when AMD brought the Memory controller on-chip for increased performance. Intel seemed to not develop the x86 architecture in favor of their Itanium, i860, and other attempts. Robert [snip] >> P3 -> P4 = Slower PSpice by more than 1/2 >> [quoted text clipped - 7 lines] > >I'd assume PSpice uses a lot of floating point calculations. Yep. Back in the early x86 days you had to buy a separate math co-processor chip. >Intel's always >favored Integer and general CPU operations over floating point given their [quoted text clipped - 8 lines] > >Robert Intel apparently has decided their mass market is the gaming/graphics crowd. Heaven help us home-brew engineers if AMD turns that direction :-( ...Jim Thompson | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | | http://www.analog-innovations.com | 1962 | "Winners never quit, quitters never win", Jack Bradley Budnik ~1956 > [snip] >>> [quoted text clipped - 34 lines] > > ...Jim Thompson Huh? The Gaming/Graphics crowd likes a lot of the stuff the Engineering crowd does. Though the Hardware tends to be dedicated. Intel seems to have decided that the Business crowd was the main Market. General Word Processing, limited Spreadsheets, Power Point, Email and such. Then the other major market being the home user with some of the above. Given the Markets the way they have been I can't say they were/are wrong. Engineering and other math intensive stuff has always been a minority part of the Markets. The major math intensive stuff, graphics, moved off into dedicated cards long ago that today rival the CPU for number of transistors. Similarly for Audio. Intel has always had ambitions to move that function into the CPU, or at least the Chip Sets they make. And the hardware's gotten powerful enough to do that with the low up to medium end. Maybe that trend will continue with the newer multiple processor cores. Robert >Intel apparently has decided their mass market is the gaming/graphics >crowd. > >Heaven help us home-brew engineers if AMD turns that direction :-( > > ...Jim Thompson The few serious gaming folks I knew (2 years ago) went for the AMD processors. AMD has been the favorite by the high-end gamers back a few years. BTW Jim, I only see a 2:1 difference per GHz in AMD vs. P4 with things like PSpice. The newer P4 processors are a bit more efficient than the old P4s, but not really significant. AMD 64-bit processors have much better memory management than the old AMD 32-bit and Intel processors. The AMD 64-bit processors under Win 2k have the same processing efficiency as the old 32-bit units, but much better memory interface. Unfortunately, PSpice doesn't seem to be affected much by memory performance. FPGA floor planners are given a major boost by AMD's 64-bit memory controller scheme over the old AMD 32-bit processors. The old AMD 32-bit CPUs have an abysmal memory controller scheme by any standard! --- Mark > I'd assume PSpice uses a lot of floating point calculations. Intel's always > favored Integer and general CPU operations over floating point given their > target markets so their floating point performance always sucked compared to > the competition. You are joking right? Until K7 there was only intel in that space. I'm not an intel fanatic but come on. XTC >Until K7 there was only intel in that space. A few years ago, I made benchmarking for Intel (Windows), Sparc (Solaris) and PowerPC (Mac OS X) with Lapack (solution of a system of linear equations). It happened that Intel needed a doubled processor clock to reach the same performance, that is, 800 MHz Intel was about the same as 400 MHz Sparc or PowerPC. I guess, the reason was a smaller L2 cache on Intel processors and, as such, much less efficient BLAS. The processor clock is not everything. I highly recommend you to browse BLAS (especially BLAS level 3): http://www.netlib.org/blas/ Without tuned BLAS libraries, you cannot have a good performance in linear algebra applications. Best wishes, Evgenii -- http://Evgenii.Rudnyi.Ru/ http://www.imtek.uni-freiburg.de/simulation/mor4ansys/ I'm a bit surprised about your results with WinE/SuSE, since WinE is an emulator that adds a processing layer, when compared to the Windows experiment. "Even in my wildest dreams" I could think that WinE would be faster than WinXP itself ! Thanks for your suggestion, it will certainly help to guide me when I upgrade my PC. Regards! >I'm a bit surprised about your results with WinE/SuSE, since WinE is an Go take a look at the wine site. Wine stands for (W)ine (I)s (N)ot (E)mulator. Wine is an implementation of the windows API under linux. This means that it is code that does the same functions for the same calls as windows does but it doesn't use Microsoft(tm) code to do it. When you run a program under XP, the body of the code runs in the 8086. When it comes to a windows API call, XP has to switch to 16 bit mode to call the WinME code, the WinME code then calls the Win98 code, which calls the DOS-6.0 code, which was written in MS-Basic. This is why XP is so slow. :> BTW: At work I showed an XP user that my "network neighborhood" still worked ok now that there are XP machines on the network. He was stunned at how fast the display came up. I thought my SuSE was going a little slow. At least on this one function SuSE seems to be much faster. Signature-- kensmith@rahul.net forging knowledge > When you run a program under XP, the body of the code runs in the 8086. This is only true if it's a 16 bit program, which -- even though Cadence has not been particularly kind to PSpice in the past few years -- I can't imagine PSpice is. It's a fair bet that any software written in the fast 3-5 years is a native 32 bit application. > When it comes to a windows API call, XP has to switch to 16 bit mode to > call the WinME code, the WinME code then calls the Win98 code, which calls > the DOS-6.0 code, which was written in MS-Basic. This is pure nonsense; DOS itself was written in assembly language. > BTW: At work I showed an XP user that my "network neighborhood" still > worked ok now that there are XP machines on the network. He was stunned > at how fast the display came up. I thought my SuSE was going a little > slow. At least on this one function SuSE seems to be much faster. That has nothing whatsoever do so with the core Windows vs. SuSE OSes, it has to do with how the 'desktops' go out and list the network neighborhood. XP tries to be 'smart' and queries each machines as it sees it to retrieve additional information about what resources it has, and this can be noticeably slow. OK, I suppose this is still 'part of Windows XP,' and I'd be the first to grant you that plenty of the included bits of XP are pretty lame, but then again, so are plenty of the included bits of any *NIX OS as well. At their cores, XP and *NIX are both decent OSes, and XP is arguably more sophisticated (hence part of the reason Microsoft's IIS has better performance than Apache on *NIX, Plug-N-Play -- while certainly not 100% trouble free -- tends to work better than on *NIX, etc.) ---Joel Kolstad >> When you run a program under XP, the body of the code runs in the 8086. > [quoted text clipped - 8 lines] > >This is pure nonsense; DOS itself was written in assembly language. Try engaging your sense of humor and re-reading what I wrote above. [...] >to do with how the 'desktops' go out and list the network neighborhood. XP >tries to be 'smart' and queries each machines as it sees it to retrieve >additional information about what resources it has, and this can be noticeably >slow. I don't think that this is right. When the SMB "master browser" was acting up, the XP machines couldn't see the same things as the Linux ones. I think XP still uses the NMB as its source of information. At least thats how it appears. Signature-- kensmith@rahul.net forging knowledge > Try engaging your sense of humor and re-reading what I wrote above. Oops. Sorry. :-) Some people really do thing that 'everything is still built on top of DOS' in XP though! >> Try engaging your sense of humor and re-reading what I wrote above. > >Oops. Sorry. :-) Some people really do thing that 'everything is still built >on top of DOS' in XP though! Yes the ignorance in amazing. Everyone knows it is all built on top of MS-Basic. Signature-- kensmith@rahul.net forging knowledge Hi Ken, Do you know why has LTSpice run faster over a 64 bit OS, even though it's a 32 bit application? Sorry if it's a stupid question... Regards! >Hi Ken, > Do you know why has LTSpice run faster over a 64 bit OS, even though >it's a 32 bit application? Sorry if it's a stupid question... I think there are two reasons: (1) The 64 bit OS gets involved in the graphics operations and draws the marching waveforms faster. (2) The spice engine writes a *.raw file. The 64 bit OS does the write faster. It could also be that some onrelated difference in the machines is the cause. I have not run the two OSs on the same machine. I hope this isn't a stupid answer Signature-- kensmith@rahul.net forging knowledge >>Hi Ken, >> Do you know why has LTSpice run faster over a 64 bit OS, even though [quoted text clipped - 14 lines] > >I hope this isn't a stupid answer If your using an AMD 64-bit processor, the memory transfer rate is !!way!! better than the old AMD Athlon CPUs and better than the newest variants of the P4. Memory handling can account for a very large difference in execution speed for some programs. If your comparing different machines, beware that memory speed (not the sticker speed, but actual measured memory transfer rates), size of RAM, sustained hard drive writing speed, and background tasks (like virus scanners) can have significant effects on program execution time. Even BIOS version will affect memory transfer rates as seen on my Tyan K8W motherboard. When comparing program execution times, you need to benchmark various things, and then find out which component(s) affect the execution time. It is not enough to say that the processor or OS made up for all the time difference. When comparing processors, you need to normalize the clock rate to some number, like 1 GHz. Then you can see the relative efficiency of the processes. AMD marketing came up with totally lame numbering system that was designed to mislead the public. Use the actual clock freq, not AMD's whacked out number scheme. Interesting things I have found out about running a moderately complex PSpice simulation on different machines: 1) AMD Athlon solved twice (assuming same CPU clock freq) as fast as the old P4s, about 1.7x faster than the newer P4s. The PIII ran about 1.3x faster than the old P4. 2) AMD Athlon and Opteron are very close in execution time on Windoze 2000. 3) Memory speed had very little effect on execution speed on the PSpice sim we were using. 4) Hard drive speed had a noticeable effect since a large data file is written out. My colleague benchmarked some Xilinx development tools and found that things ran almost twice as fast on the Opteron system than his old Athlon system, both using Win2k. This was mainly attributed to memory speed. The Athlon memory transfer rates were less than half the rated speed of the memory due to their really funky north bridge chip. --- Mark [...] >RAM, sustained hard drive writing speed, and background tasks (like >virus scanners) can have significant effects on program execution >time. I don't have any viruses to scan for but on a Windows machine I have seen virsus software slow disk IO way down. >When comparing processors, you need to normalize the clock rate to >some number, like 1 GHz. How about I normalize to 3.3GHz? Then I don't have to do any math to compare the 2 machines. [ observations on PSpice ..] >1) AMD Athlon solved twice (assuming same CPU clock freq) as fast as >the old P4s, about 1.7x faster than the newer P4s. The PIII ran about >1.3x faster than the old P4. Since spice tends to take a lot of floating point operations, it is the speed of that part that matters so these sound reasonable. >2) AMD Athlon and Opteron are very close in execution time on Windoze >2000. That surprises me a little. >3) Memory speed had very little effect on execution speed on the >PSpice sim we were using. If the floating point operations take multiple machine cycles this is reasonable. >4) Hard drive speed had a noticeable effect since a large data file is >written out. Yes and the type of disk structure also matters too I'll bet. Signature-- kensmith@rahul.net forging knowledge > Hi Ken, > Do you know why has LTSpice run faster over a 64 bit OS, even though > it's a 32 bit application? Sorry if it's a stupid question... > Regards! Hello Douglas, there may be only small differences in speed between all the OS. Nobody has given any number so far in this discussion. So please be aware that we talk here about a few percent difference. We have collected benchmark results of three smaller SPICE-circuits in the database of the LTspice-Yahoo-group. Here the result in a few sentences. 1. I can't see any advantage of any OS over the other from the results in this database. 2. The AMD processors are about 20% faster with the "normal" solver. So a 3800+ Athlon64 is about 20% faster as a 3800Mhz P4. A 3000+ Athlon-XP is equivalent to a 3200+ Athlon-64. The Intel-Centrino is also strong. Even in notebook, a 2GHz Centrino is equivalent to at least a 3.2GHz P4 desktop. The P4 can reach the same speed as the AMD, if the compiler is allowed to generate P4 optimized code. One time in the past there was such a version available for LTspice. I remember from Mike, that it's just too much effort to maintain two versions. I have heared that the P4 and P3 is stronger with the "alternate" solver compared to the AMD, but I haven't checked that. The benchmark results are in the section "Database" http://groups.yahoo.com/group/LTspice/ Back to the OS discussion. If you experience a great difference with a certain simulation, then the only reason for this can be the available cache memory for the programm code and the data during this simulation. Maybe this was the case when somebody thought it's faster under Linux. I can tell you it's impossible in general, because the processor runs exactly the same code, instruction by instruction, regardless of the operating system. Only the I/O is different between the OS, but this is only a small fraction of the simulation task. My statement: There is absolutely no speed advantage to use LTspice under WINE with Linux . I am conviced that a simulation can't be faster there, when we look over many circuits in average. The good thing is from what I see is that it's not slower. So you have the choice with the OS. Somebody in this group came up with the idea to use the processors on the graphics card for the calulations. This is useless, because you need 64bit floating point for SPICE. Otherwise a lot of circuits will not run, because of the high dynamic range and resolution required in the matrix solver. Best regards, Helmut > Somebody in this group came up with the idea to use the processors > on the graphics card for the calulations. This is useless, because > you need 64bit floating point for SPICE. Otherwise a lot of > circuits will not run, because of the high dynamic range > and resolution required in the matrix solver. Hi Helmut, -"...you need 64bit floating point for SPICE..." Is it true even for 32bit Spice versions? Are there 64bit Spice versions? -"...a lot of circuits will not run, because of the high dynamic range and resolution required in the matrix solver...." Since I don't know nothing about this subject, there's my question: so the processor on the graphics card does't have this required processing power? Only the PC's CPU has it? I'd really like to study and understand in depth the way Spice works, including to learn enough to be able to modify the source code of some of its modules. Could you please suggest me some material? It also could be some web links and/or key words for searching in Google. Thanks a lot! [....] > -"...you need 64bit floating point for SPICE..." > Is it true even for 32bit Spice versions? Are there 64bit Spice >versions? Beware that there are different meanings to the term "64 bit". Most modern CPUs have a "bus width" that is commonly being refered to when people say "16 bit", "32 bit" or "64 bit" when refering to a CPU chip. The "bus width" in the number of bits the CPU can transfer in one action. Basically, it is the number of wires going from point A to point B. Like it is posible to do multidigit math "long hand" on paper, a CPU can process numbers larger than the "bus width". You can do 64 bit math in a 8 bit processor this way. It won't be as fast but the results will be exactly the same when it is done. The x86 processors have a special section for dealing with the "floating point" numbers. This section looks like it has an internal "bus width" of 80 bits. It may not really be 80 bits, since internally it could do two 40 bit transfers to get 80 bits from here to there. While the numbers remain inside the "floating point unit" they remain in the 80 bit form. When they are stored, they are rounded off to 32 or 64 bits as required. > -"...a lot of circuits will not run, because of the high dynamic >range and resolution required in the matrix solver...." > Since I don't know nothing about this subject, there's my question: >so the processor on the graphics card does't have this required >processing power? Only the PC's CPU has it? You may have hit on something here. Just for purposes of discussion: Assume that the graphics card only does 16 bit operations. Also, lets assume that it does these operations at a 700GHz rate. Such a processor would be able to outpace a 3.3GHz Pentium when doing 64 bit math. Obviously, I just made up the 16bit at 700GHz values. > I'd really like to study and understand in depth the way Spice works, >including to learn enough to be able to modify the source code of some >of its modules. Could you please suggest me some material? You can find the source code for some of the older versions of spice on the web. The highly tweeked stuff that various companies provide is not available. I assume by "modify the source code" you mean "modify the source code in a useful way". To get to ths point the quickest, I suggest you pick one part of the processing such as ".op" and dig into it in detail. > It also >could be some web links and/or key words for searching in Google. Spice 3f4 source Signature-- kensmith@rahul.net forging knowledge : I'd really like to study and understand in depth the way Spice works, : including to learn enough to be able to modify the source code of some : of its modules. Could you please suggest me some material? It also : could be some web links and/or key words for searching in Google. Here's the premier open-source SPICE. Linux native, with Mac and Widows ports. Incorporates XSpice and Cider. Bugs which are present in older SPICEs floating around the web are absent in ngspice since it has been worked on continuously for several years. http://ngspice.sourceforge.net/ Happy hacking! Stuart : : I'd really like to study and understand in depth the way Spice works, : : including to learn enough to be able to modify the source code of some : : of its modules. Could you please suggest me some material? It also : : could be some web links and/or key words for searching in Google. : Here's the premier open-source SPICE. Linux native, with Mac and : Widows ports. Incorporates XSpice and Cider. Bugs which are present : in older SPICEs floating around the web are absent in ngspice since it : has been worked on continuously for several years. : http://ngspice.sourceforge.net/ Also, if you are interested in analog circuit simulation in general, you could take a look at Gnucap. Gnucap is a reasonably complete open-source analog simulator which is a little more sophistocated than SPICE. The code is also a lot cleaner, and so may be easier to understand. Again, it's open source, so you can see and explore the internals. Here's the URL: http://www.gnucap.org/ Rather than the 0.34 release, grab the latest snapshot available under "development releases". HTH, Stuart > > Somebody in this group came up with the idea to use the processors > > on the graphics card for the calulations. This is useless, because [quoted text clipped - 6 lines] > Is it true even for 32bit Spice versions? Are there 64bit Spice > versions? Hello Douglas, This 64bit floating point math has nothing to do with the operating system. It only menas that you use 64bits of memory for each variable or constant. The calculations have to be also accurate for 64bit of course. It's simply the type (double) in most programming languages. > -"...a lot of circuits will not run, because of the high dynamic > range and resolution required in the matrix solver...." [quoted text clipped - 7 lines] > could be some web links and/or key words for searching in Google. > Thanks a lot! I have never tried to do that. For me it's enough that Mike works in this area. :) Insiders will know of whom I speak. Best regards, Helmut |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.