I have been running Qspice successfully on my Macbook pro (M2 ARM processor), until I started writing my own verilog code. When compiling the verilog to C++, I get an error message of “Unknown problem launching Verilator.exe”. I tried compiling the included VerilogCounter.v, and same error message. The simulation of VerilogCounter.exe works, as the C++ file was there from the installation.
I tried it on my other computer, a Core I9 desktop, and no issues with compiling verilog. So this is not a show stopper issue for me, but it would be nice if there is a fix. I am guessing it is an issue with the ARM version of windows 11.
This probably isn’t your problem but I’ll offer up that you can’t compile the examples that use .DDLs without first putting all the files to some directory where you have write permission. That is, the Files==>Demo can be run and inspected, but not compiled because they are in the Program Files directory. Start by copying the entire C:\Program Files\QSPICE\Examples directory to someplace like your desktop, and try it there.
While I have in the past became a Mac person so I could write large graphic Apple OSX applications with complete native integration in Apple ecosystem, right now I don’t want to dilute my time with any effort in the Mac.
Funny thing about my MAC experience, an intern I was working with was using the MAC version of LTspice, looking at a circuit. We had the idea of seeing how fast my Dell XPS 15 core I9 would compare against his MAC M1 running the same circuit in LTspice. To my surprise, the M1 Mac beat the Dell with a comfortable margin. And the MAC did not even get noticeably warm, while the Dell was hot and sounded like a miniature Vacuum cleaner. Once the Dell failed, it was replaced with a Macbook pro M2.
I am sure that writing MAC version would be a huge effort. Since most engineers on mac are using parallels running Windows 11 pro for ARM, it is likely compiling a dual binary code might solve the problem. But of course I have access to a Intel windows machine, so I have a work around, and do not want to distract from your progress.
Keep up the good work
summary “compared an older x86 chip against a newer ARM chip that has integrated main memory”
As a rule of thumb, I’d expect an Intel CPU to do more per clock cycle than AMD or ARM. Plus Intel has the highest clock rates. They can actually multiply two double precision floating point numbers in three latent clock cycles at the end of the pipeline, i.e., in 500ps.
For a quick benchmark of your machine, try the BodePlot.qsch from top level menu command Files=>Open Demo… I run it in less than 24 seconds. There’s a photo of the machine I use in the help file.
First I tried running using 2 cpu cores dedicated to Windows. I gave up. Tried again with 4 cores, task manager showing 76% of the CPU used by Qspice. 436 seconds. I am guessing that it is not a dual binary, and the arm is translating code to get such a large runtime. The Macbook does not warm or run any cooling fans during the test.
Tried running under 64 bit WINE (crossover for mac), but the installer did not like it.
My Core I9 desktop did it in 52 seconds, with the fans kicking into high gear, and 100% cpu utilization. This is a bit odd. When I simulated my sigma delta ADC, the core i9 was only about 2.2 times faster.
I ordered a Framework Core I7 1360p laptop for Qspice, and for in circuit microcontroller + FPGA programmers, all of which seem to have limitations with windows 11 for ARM. Not the fastest machine, but it fits in my backpack and should do what I need to do.
It would be interesting to see how some of the top-end processors compete against each other running some of the harder QSPICE benchmarks.
x86 processor benchmark charts (2023):
Recent x86 processor families (July 2023):
" It would be interesting to see how some of the top-end processors compete against each other running some of the harder QSPICE benchmarks.
** https://forum.qorvo.com/uploads/default/original/2X/2/260feb7ad8abad733f8c85b65afc5ad03434f841.jpeg "*
Your first link is NOT about testing of different CPU under QSPICE.
This is about testing of different SPICE simulation software.
You are welcome Mr. Bean.
I have been using Qspice on a framework laptop running windows 11 on a Core i7 1360p without any issues, but today after updating Qspice, I started getting the same “unknown problem running ventilator.exe”. Not sure if it was an update that broke it, but trying an older file that has write access gives the same result, so it has nothing to do with the verilog code.
That could happen if Verilator.exe either doesn’t have execute permission or returns an error code, but issued no error message, which I suppose could happen if Verilator.exe crashes. The exact message would be “Unknown problem launching Verilator.exe.” If that is the message, then Verilator.exe was found by QUX.exe, but running it returned an unknown error but nothing was printed on its console.
I’ve tested the release and verified it should work. There was just another update, in the interest of an unrelated performance improvement, and just performed the same verification just now again.
If you wish, please send the the .v file that Verilator.exe choked on and I’ll check it out. Use the e-mail address on the Help=>About or either of those in the Help file.
The ventilator appears to be still broken, it was working great on a version about 6 weeks ago, but somewhere in the update process it broke. Is it possible to get older versions of the Qspice? One of my co-workers downloaded Qspice and also is getting the “unknown problem running ventilator.exe”
I strongly doubt an older version of QSPICE will be different. I have not changed anything regarding Verilator. Also, I just confirmed it’s all still working in todays’ build.
But, to answer the specific question, no older version of QSPICE are not available.
Well, I just fixed the verilator on my real intel laptop. I needed to install the MSVC redistributable, and now it runs there fine. Same thing does not work on a parallels virtual machine on an ARM Mac, and also does not work on windows 10 running within Linux (virtual box) on an AMD, both problems that I guess I can live with. In hind sight, it is possible the intel laptop never verilated successfully until today, since it is working within the same folders as my desktop that never had an issue with the verilator.
Glad you got a partial signal out of it.
Every library Verilator needs is supposed to be simply part of the OS and not require installation of an MSVC redistributable.
I just pushed a release that’s now basically statically linking to crt0.o, so if you do an update, it should all work now on both platforms.
Everything is working great now!!!