Hello All,
As we discussed in the last mumble session, here is some status on the analog toolchain I intend to use for the 555. First, some note on the general approach: Many of the tools here are typical Unix-style (invoked in terminal, file goes in, file comes out). This is good from an integration and modularity perspective, and it is a tempting thought to strip all "unnecessary" intermediate steps (gnetlist, gspiceui) and write the SPICE deck and invoke tools manually (as suggested). However, I think this shall be a last resort in case when everything else goes FUBAR, because of two things: first, manual processing is error-prone and we need to really firm regarding what we layout is what we simulate (it is easy to just forget or mistype something and then overlook it) and second, if someone sees in the repo that doing a single .OP requires 6-10 hand-crafted terminal commands (not to mention parameter sweeps or monte carlo), it may be a huge deterrent in adoption (engineers are humans too, and humans in general love the convenience of a big green button).
The tools so far (RFC if you think there's a better option):
gschem 1.8.2 (schematic capture)
ngspice 26 (simulator)
gaw (waveform viewer)
Problems discovered so far:
2. gnetlist makes use of the gschemrc configuration to establish mapping between symbols and sub-schematics (subsch is not recorded in the schematic, but in the symbol file). However, gspiceui invokes gnetlist not in the current working directory, but where the schematic is loaded from, so local gschemrc is not parsed. Possible solutions:
- Adapt a flat directory structure (no sources, tbench, ...). Ugly but works.
- Place a link to the local gschemrc everywhere
- Set libraries in the global gschemrc (not good because necessary config no longer contained in the project dir)
- Patch gspiceui (PrcGNetList.cpp 396)
- Invoke gnetlist manually outside gspiceui and import complete netlist
3. In case of hierarchical designs flattened into a single circuit, gnetlist places '/' into net names and component names ("X1/R1 11 7 100k"). This breaks ngspice (interpreted like "X1 R1 11 7 100k"). Blind replacement does not help, as if we use parametric models, we may need expressions containing division.
4. Nets in lower levels and nets at higher levels connected to them are treated as separate entities and not connected, for example:
MX1/M26 X1/OUTPUT 18 X1/GND X1/GND nmos4 l=0.5u w=20u
R3 1 5 100 (shall be R3 1 X1/OUTPUT 100)
Maybe the wrong port symbol is used in the lower level, this needs to be checked first.
5. When flattening hierarchical designs, component designators sometimes have wrong first letter (first letter denotes component type). Particularly, MOS works but resistors are not:
MX1/M11 X1/GND 13 13 X1/GND nmos4 l=0.5u w=10u
X1/R4 12 X1/GND 40k
Output from console:
--- checking package = X1/M12
device = NMOS_TRANSISTOR
Found NMOS transistor. Refdes = X1/M12
Checking prefix. Package prefix =X
correct prefix =M
nomunge mode = #f
different-prefix=#t
--- checking package = X1/M11
device = NMOS_TRANSISTOR
Found NMOS transistor. Refdes = X1/M11
Checking prefix. Package prefix =X
correct prefix =M
nomunge mode = #f
different-prefix=#t
--- checking package = X1/R4
device = RESISTOR
Found resistor. Refdes = X1/R4
--- checking package = X1/R2
device = RESISTOR
Found resistor. Refdes = X1/R2
Most of the errors can be reproduced by invoking gnetlist on the current testbench (before that, V? needs to be changed into V1). Command line:
/usr/bin/gnetlist -v -g spice-sdb -o /home/kiseferi/IC/github/CMOS-555/TBench/geda/Use-Case_astable-mode.ckt /home/kiseferi/IC/github/CMOS-555/TBench/geda/Use-Case_astable-mode.sch
The resulting netlist of course makes no sense (no .MODEL for MOSFETs, etc...), but what is already there should be structurally correct.
Maybe a solution is to use either a .SUBCKT instead of flattening (good only if internal nodes remain query-able), or to use a single schematic page (ugly).
Regards,
Ferenc