I am so excited about this amazing effort to develop this wonderful tool .I have only ran some examples …And i have so many ideas. I work with SDR and DSP systems …I wonder if it could be possible to connect through the C++ interface to real hardware ( via other dlls ) to USB and other ports ,and send test signals to real hardware for example ?
That would be very cool! I don’t know what’s required to interface to the outside world, but send us an email (qspice@qorvo.com) if you have any ideas about how to implement it.
Jeff
Thanks for your quick reply … I will do some tests …An see how can be done using the USB port . I have several C++ libs for FTDI chips , I will see how to talk to the driver first …and changing pins levels on the FTDI chi .If this can be done the sky is the limit …Because you could drive real DACs and ADCs,
In Proteus this can be done for example.Also running Matlab functions from the Matlab engine should also be possible …This is big !
Regards
That last part about running Matlab functions is particularly interesting even if you don’t want to interface to hardware. Please see the other thread about parsing WAV files, as Mike just added the ability to pass a string to the QSPICE .DLL; maybe that is helpful.
hi Jeff .Yes i saw that wav project and got the files. I put together already a visual studio dll .to test the usb interface … And i also started to get documentation on Matlab engine calls … from a c dll. as soon as i have the time i will test.
In 2005 I published a paper on “lntegrating Hardware and Embedded Software into a Virtual
Prototype of an Electronic Throttle” at the SAE World Congress in Detroit (Refer to Offer Number 06AC-50). The underlying concept was to link an instruction set microprocessor simulation (ISS) to a circuit/system simulator to perform HW/SW cosimulation of embedded software with clock cycle timing precision. At the time, I accomplished this by writing the ISS in VHDL-AMS and executing it as a model with Mentor Graphics’ SystemVision simulator. The paper demonstrated the feasability of the concept. I had modeled the HC12 micro and used the model to exe cute C code that I had compiled with the same compiler that might be used in the field. MY PROCESSOR RAN THE MACHINE CODE DURING THE SIMULATION!
The only flaw in my concept was the need to program the entire HC12 jnstruction set manually accounting for every memory access.mechanism provided for ech instruction, a tedious task requiring months of effort. To populate a usable library of proccessor models would probably have taken the rest of my life.
BUT NOW IT LOOKS LIKE Qspice HAS THE ANSWER! Every processor on the market comes with an instruction set simulator for debugging the software. Shouldn’t it be possible to link the existing ISS machine to Qspice and cosimulate hardware and software? If so, my vision of HW/SW codesign should become a reality. Throw in a little automatic code generation and, Voila! Nes pas?
Hi Nje
Yes the same idea came to me …using simulators .there are some videos on youtube ,on how to write them in c++ …But as you said it will take a lot of effort and time .Another option is to go to opencores and use verilog models .They have quite a few of commun ones .This days i am short in time .but i will keep thinking in this.Also if the core is in VHDL …no problem as if is synthesisable I can migrate it to Verilog
Also here v2c - A Verilog to C translator tool there is a Verilog to c converter . SO you could convert a RTL processor project to C .
I am not an authority on this subject (not even close), but given the amount of information readily available on RISC-V, is it a reasonable target for this project?
It is better to start with small micros …Like the MSP430 …i downloaded this core from Opencores.org. Most of this cores are written using multiple files that reflect the different modules .so i need to test how Verilator deals with this …
1 Like
Interfacing to hardware or simulators would, indeed, be cool. Thinking about it brings me to one of my concerns: The Digital Mars compiler.
As best I can tell, it’s a bit dated. In fact, I’ve not yet even found what version of C++ it supports. Also, it doesn’t seem to interface with tools like VS Code to auto-configure, debug, etc. I’ve tried getting VSC & MinGW to generate QSpice component DLLs directly but haven’t found the proper incantation and QSpice errs out loading the DLLs. That ate up a couple of days so, I set it aside for the moment.
Anyway, if there was existing simulator code, DMC might not play nicely with it. Lots of rework might be required. How to solve that has been on my mind.
Absent resolving the DLL linking/loading mysteries, I’ve thought about using the DMC bit minimally and have it connect to non-DMC code client/server fashion – a separate DLL dynamically loaded/linked or some more elegant inter-process communication technique.
Just food for thought.
–robert
I use MSVC for generating the DLLs. Important: You have to use the 32-bit compiler, because the DLL has to be 32 bit, not 64 bit.
Well, I tried every toolset I have except MSVC. I was aware of the 32-bit requirement. Will check it out.
Thanks.
–robert
@Jope, would you mind sharing your MSVC configuration/base code that works for you? I’ve not used it in a while but not having luck getting Visual Studio to generate a DLL that QSpice will load. Thanks.
I don’t use Visual Studio. I use the compiler on the command line (using make).
On the command line, you have to first call the “vcvars32.bat” batch file for setting up the environment for the 32-bit compiler. In my case the complete path is “C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars32.bat”.
Then the minimal command for compiling the DLL is:
cl /EHsc /LD my_qspice_dll.cpp /link /out:my_qspice.dll
Thanks, Jope. That works.
Can someone give me an example for what this would be useful?
Well there are situations where you have digital and analog components side by side …An you need the digital mode to interact with the analog section… SDR (software Defined Radio) is a good example .Also power conversion .where Mosfets are driven by a digital circuit .And you need to test the complete system interacting both sections with each other .Motor control is the same .A medical device is another …A heart ( you won’t find a SPICE model for it) …So you need this capability to create your own description of the device ,as they are not available. And in the ultimate case would be to interact with the real device and couple the simulation model of the system to it …Where changing the fine tuning the value of a cap can be done in software …This is called simulation in the loop … Where some sections are implemented as SPICE models and digital models .Dealing somehow with real hardware … A real FPGA lends itself pretty good for this …The comoplete digital and real control is outside the computer interacting with real power and monstruos power ,being simulated by Qspice …This is real engineering !.
During the pendemia .People tried to design respirators ,as they were scarce. But to design such a system you need breathing models to couple them to analog control models …There are lots of high end sotware capable of deignin such models ,like Matlab,Altair embedded .They can generate the model in c++ .So if we can integrate such a model with Qspice …Wow now we have a great tool .Which is already
1 Like
I just use the Digital Mars Compiler that installs with QSPICE. If I have a few hundred pages of C++ code, I tried the MS Visual Studio IDE with the Intel compiler installed. It takes much longer to compile but can profile as faster, not that in the scheme of the QSPICE simulation the impact of evaluating that much C++ code more than a few percent impact on the overall speed of the simulation.
I still cannot imaging how this would work. One side being something working in real time and the other side working in non deterministic simulation time.
Hi there is nothing to imagine …it works already !
1 Like