I have a model file that uses LTspice A type models like OR, AND, and other logic gates. It seems like these may not be currently supported by Qspice. Is there a plan to support these in the future? As an alternative approach I attempted to substitute A type models with Qspice behaviorial components but got a similar error. Can anyone provide insight into the best way to handle this issue I am having?
Thanks
Ravi
I wrote the LTspice A-devices over 25 years ago over a three day week end. It was one of my first mixed-mode simulators. I’ve moved on from that method and QSPICE is free of that method. My guess is that the LTspice A-devices will remain proprietary to LTspice.
–Mike
Mike,
I agree with not wanting to go back to the past. As an alternative I attempted to modify the model file and replace the LTspice logic gates with the Qspice equivalent. Below is an example of how i tried to translate the XOR gate. The below statements are my version of templates to map the right ports. There are other logic gates in the full model but I am trying to take it step by step. These statements are inside of a subcircuit.
LTspice Template Netlist
*Axxx 0 XOR_IN1 0 XOR_IN2 0 XNOR_OUT XOR_OUT 0 XOR
Qspice Template Netlist
*¥6 VDD VSS XOR_OUT XNOR_OUT XOR_IN1 XOR_IN2 ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ XOR
When I try the utilize Qspice template i get the error
Fatal error: Unknown device type: â
Is this an approach I should be able to make work?
I can send you the whole model file if you would prefer that
That’s the right approach, I would guess.
To understand the error, you’d want to find a line in the netlist that uses the ‘â’ character.
QSPICE doesn’t use that character.
–Mike
CD4046Bg.txt (4.6 KB)
I attached the whole model file so you can see the context of the approach I took.
I only commented out the single line for Y6 for the XOR gate so this is the line that is creating the Fatal Error. I am just not sure why its complaining about this syntax
I copied and pasted that special character (Y) from the auto generated netlist from QSPICE when I ploped examples on a schematic page. Maybe this was a mistake. Let me know how this line might need to change to be syntax correct
When I open CD4046.txt in my text editor, I see
That is, it has the ‘Â’ character. In the error message, it was reported in lower case: ‘â’
So remove those characters and you should get farther along.
–Mike
Thanks Mike,
When I open the file in Notepad++ the default encoding is UTF-8. This encoding did not display the  character. In Notepad++ when I changed to Encoding->ANSI then that  special character is now visible. I removed all instances of that special character and the simulation compiles properly and shows me a waveform viewer
You can also open the file in QSPICE (QUX.exe) It includes an ASCII editor for the type of ASCII QSPICE reads.
–Mike
@Engelhardt Pls permit me to offer related feedback concerning the root of this kind of problems (referring to the last messages and not to the original question). Restricting Qspice to a codepage dependent 8 bit characters can IMO only be seen as a poor design choice that will forever produce confusions and problems.
For half a century codepage dependency was a well recognized problem all over the world. It was finally and forever solved with UTF-8 encoding which is exactly identical to 8bit ASCII except for special characters (those beyond 7 bit range). Before UTF8 was invented Windows adopted a 16 bit unicode variant (also used by LTspice) but that still is problematic and it doubles file size if only ASCII characters are used.
Meanwhile UTF8 has quickly become the world standard and it is the way to go for modern software.
Personally I find using Alt codes to type special characters unnecessarily unfriendly to use also.
Since many years I use WinCompose to type special characters. I type symbols like µ, Ω, ω, π,°C, α, β, ≥, ≠, etc… on a daily bases in all my documents, emails and Python code (yes: in variable names too), all using easy to remember keyboard shortcuts. Its much more efficient than the built-in windows method (which I don’t even remember anymore).
Using the correct symbols improves readability as wel, which is important, and it makes expressions shorter.
Would it not be a good idea to enable UTF8 and use for example α,β,… instead of (or maybe as alternative to) those weird Ã, ¥,…?
Here is a comment from Mike Engelhardt can be your reference. It seems also a lot of people insist ASCII netlist. Qspice supports comments on schematic with UTF-8.
Can “Text/Comment” support Chinese/UTF8? - QSPICE - Qorvo Tech Forum
Thanks for pointing this out.
I don’t know what the original arguments were but it is not surprising that some users would have objected to 16bit encoding as was done in LTspice (I did not complain but I too did not like it, it was messy and I had to change my scripts). But UTF8 does not have those problems, it is still 8bit if you use ASCII characters, and all modern software supports it correctly. By design it solves encoding confusion and file translation problems (such as garbage by copy-paste) so it really seems the right way forward.