Open in3otd opened 9 years ago
This Forum question is bit related.
Have also a look a the POLY sources, I think not all sources are implemented.
FWIW, SPICE3F5 syntax dictated that lines beginning with space were comments.
Many other SPICE derivatives let netlists be more freeform, with leading spaces being acceptable on regular netlist lines. But the original syntax was pretty rigid.
We encounter this issue with Xyce from time to time, as we had made our parser 3F5 compatible (so spaces at the beginning of any line make that line into a comment). Users of other simulators sometimes get an unpleasant surprise when they try to import a netlist from a simulator that doesn't have this "feature."
thanks @tvrusso , I didn't find the time to check the original SPICE docs yet...
The qucsconv
parser also ignores lines starting with spaces currently, but since also TI distributes SPICE models with regular netlist lines starting with spaces we should probably just ignore the leading whitespaces...
Perhaps it would be good to introduce some sort of option that follows 3F5 convention if you're going to use a more modern SPICE syntax as the default (where leading whitespace is decoration rather than meaningful). There could potentially be old spice netlists that actually take advantage the "space means comment" nonsense. Maybe "-if legacy-spice" or "-if spice3f5"?
The old SPICE parser looked only at the first character of each line to determine what that line was ("." for a directive, [a-z] for a device instance, "*" for comment, "+" for continuation, and of course this " " for comment thing). A legacy of its Fortran and punch card heritage.
I noticed that
qucsconv
ignores input lines starting with spaces for spice netlists: I saw this trying to use the spice model for the LM358 on the TI website , which has leading spaces in the subcircuit definition lines. Runningqucsconv
on itthese lines are ignored. Removing the leading spaces the conversion is fine. I am not really sure if this is allowed in the original spice syntax, but seems a good thing to just ignore the leading whitespace, maybe emitting a warning at most.