Eeep, it requires ":" as the separator? Strange. That is incredibly non-standard...

That period was a while ago, like 2005-ish.

It is likely easy to accept both

Maybe I'll just add an option to my tool.

Ah.

By the way, you asked much earlier about regression tests. The answer is YES, we have a large test suite. It is in a separate git repository. https://github.com/Xyce/Xyce_Regression

Regarding the expression parser, that is easy to modify with a new token. The older netlist parsing code is scattered over many files in the Xyce/src/IOInterfacePKG directory, and is much harder to digest. That code was NOT written using a parser generator and is does not have a compact grammar file. The individual functions aren’t so bad, but they aren’t all in a single compact place.

So, that is actually one reason for switching to XDM. It is written using Boost Spirit parser framework. So, the grammar should be easier to encapsulate.

Something else I would like to add about colons: There's a thread on the ngspice Sourceforge mailing list archives. Someone created a loop gain simulation with a

.loop

simulation card. To include differential loop gain, he created a balun element, but ran into the problem that we're out of letters for new elements. At the bottom of the thread, the suggested syntax for a new element (and thus, what could be a generalized means of expanding the spice instance syntax) is to indicate the balun with

:balun:<instance-name>

. If anyone has connections to the ngspice developers, it might be worth pointing out xyce's conflicting hierarchy separator syntax. ngspice .loop analysis thread

The old Xyce parser (which is still in place), was hand written and doesn’t have a clean grammar file. So, as we worked on that, the easiest way to support compatibility with other simulators was to basically support a “superset” of capabilities. We did that on a case-by-case basis. This was mostly fine, except that of course sometimes the syntax of one simulator conflicts with the syntax of another, and they cannot be made to co-exist.

For unresolvable netlist compatibility issues, we have a command line option that takes care of some of them. It is

Xyce -hspice-ext all netlist.cir <return>

This option forces Xyce to use the “Hspice” method of doing things when there is an unresolvable conflict with Xyce’s standard syntax. One example that is handled by this option is the “atto” unit suffix. In Hspice a number followed by “a” means “atto” which means 1e-18 multiplier. But in many other simulators “a” just means Amps unit. There isn’t an easy way to have the parser figure out which of these two things is intended.

Regarding the running out of letters fo new elements, we had that issue a long time ago on Xyce. The solution we came up with, many years ago, was to parse “y” devices differently. So, Y devices have extra fields which allow many different types of devices to be specified using that syntax. We’ve mostly used it for unorthodox device models that aren’t typically found in other simulators. Examples of this include neuron models, TCAD models, ROM models, reaction-network models, and any models specified via our python API.

Anyway, back to “:” vs “.” for separators. It will be possible to support this, but it may take a bit of work for various reasons. But either way, we’ll get it in there somehow.

Here is a small update on the colon separator. One of my colleagues did some digging. The choice of “:” for a separator dates back to Spice3, which is the code we were primarily using as a reference 20 years ago. If you run spice3 even now, its raw file outputs use a colon. So, we didn’t just make it up, but we never reconsidered it after that, and most codes that are forks of spice3 switched from the colon to the period at some point. That (obviously) includes ngspice, but also includes commercial tools like Pspice. Using colons has made some things more difficult for us, so we should probably just switch to using a period like everyone else. In particular, parsing the ternary operator in expressions gets tricky when the variable names are allowed to include colons, so it would be nice for that issue to go away. Anyway, I am kind of surprised that nobody has complained about this issue before now, but there we are.