3 observations

[olisnr]

not real problems:

1. if i use a symbol with the schematic attribute, the netlist.spice includes both, the .subckt symname and the .subckt schematic

2. the icon is transparent on cinnamon

3. sometimes the simulation button dont goes read if ngspice is running. but sometimes it works, and i didnt found out whats different

[olisnr]

4. if xschem generate a netlist, a net is highlighted. has this a reason?

https://github.com/StefanSchippers/xschem/assets/120017377/62a719d9-baa4-46e7-93e0-a29f652058bc

[olisnr]

5: crash while auto-save symbol with open dialog:

/tmp/xschem_emergencysave_cmos_example_opamp_fold_casc_bbbbfefdff

FATAL: signal 11
while editing: cmos_example_opamp_fold_casc

https://github.com/StefanSchippers/xschem/assets/120017377/6ce88698-902b-491f-85a8-5cc996c48800

[StefanSchippers]

4. if xschem generate a netlist, a net is highlighted. has this a reason?

netlist_highlight.mp4

In general Open View-> Show/Hide -> Show ERC info window. A highlight net means in this case the net is driven by someone but goes nowhere. In some cases this might spot a misconnection. In cases like this you should waive the warning and put a noconn.sym device onto this net.

[StefanSchippers]

not real problems:

1. if i use a symbol with the `schematic` attribute, the `netlist.spice` includes both, the `.subckt symname` and the `.subckt schematic`

This is known. It is not a problem in general on any simulator I have tried, you just end up with an additional subcircuit that might be unused. Anyway I will take a note and since I also don't like this I will see if there i an easy way to remove the symbol associated schematic if "schematic" attribute specifies another circuit.

2. the icon is transparent on cinnamon

This was done on purpose since on old school desktops I don't like icons with a frame/background around, unless the icon background color is exactly the same as the desktop background. Like in this picture, where i have deliberately overlapped some icons.. Don't know if there is a way to nicely accommodate both.

3. sometimes the simulation button dont goes read if ngspice is running. but sometimes it works, and i didnt found out whats different

The difference is : if xschem simulate is given as a command (either at the CLI or by using a launcher) the button does not go red, if it is invoked from the Simulate button it does. This is known and it is on the list, at lower priority than more serious issues. Will arrange for a fix.

[StefanSchippers]

5: crash while auto-save symbol with open dialog:

/tmp/xschem_emergencysave_cmos_example_opamp_fold_casc_bbbbfefdff

FATAL: signal 11
while editing: cmos_example_opamp_fold_casc

crash.open.dialog.mp4

Thank you, this should be fixed in next commit.

[olisnr]

6: if i use " in a symbol the rendering of parameters is a bit strange: the part in the schematic uses: name=x1 schematic=opamp_p_fold_casc2.sch nw=10u nl=.45u pw=20u pl=.4u now if the symbol uses pmos: @pw\/@pl it renders in the schematic to pmos: 20u/.4u. but "pmos: @pw\/@pl" would give "pmos: 20u/. i would expect, it would not replace any parameter or all in the ""

https://github.com/StefanSchippers/xschem/assets/120017377/c0c7c136-82ce-47c2-bd8d-0651659d2938

[StefanSchippers]

6: if i use " in a symbol the rendering of parameters is a bit strange: the part in the schematic uses: name=x1 schematic=opamp_p_fold_casc2.sch nw=10u nl=.45u pw=20u pl=.4u now if the symbol uses pmos: @pw\/@pl it renders in the schematic to pmos: 20u/.4u. but "pmos: @pw\/@pl" would give "pmos: 20u/. i would expect, it would not replace any parameter or all in the "" parameter.in.Quotation.Marks.mp4

@ substitution allows to replace -say- @param with the value assigned to param by the instance:

instance: param=100 symbol: @param will be displayed as 100

To make pcb engineers happy the set of characters allowed in attributes includes almost all characters, so

@a"33"[2] is a valid attribute name. A better solution should be to restrict attributes to be regular identifiers like in almost all programming languages. Go ask pcb makers to accept this.

to make the long story short, use: "pmos: @pw\/@pl\" so the closing double-quote will not be interpreted as part of the pl attribute. Without the backslash xschem tries to substitute pl" instead of pl. Another possibility to avoid these ugly backslashes is to use spaces: "pmos: @pw / @pl "

[StefanSchippers]

Since you are a power user do you have a chance to test this? This is the ability to rotate symbol texts if the symbol is rotated, by making these texts "floaters" which can be moved/sized/rotated independently of the symbol. Some additional features need to be implemented but it is working now.

https://github.com/StefanSchippers/xschem/assets/69359491/4f73b17a-19ae-46a9-a670-4287d1821c94

[olisnr]

the floating text is working. but im not sure i its a good idea to duplicate the text and hide the parts text. wouldnt it be better to make a relative movment and rotation possible? as example You did add a hide_text=bool, why not also a x_offset=long and so on? You would be able to get the text out of the way, or even hide it, but You also could move the symbol, and the text would follow

[olisnr]

7: when You simulate, then You can specify the output filename easy like ngspice -b -r "$n.raw" -o "$d/ngspice.log" "$N" but if You want to load it back in to Xschem, thats not working. would it be possible, to make all the $names and $paths the same in every place of Xschem? (even in the spice-commands)

[olisnr]

is it possible to bring Xschem-variables in a spice-simulation without the -D option of ngspice? is it possible to generate the value of a simulator_commands.sym direct from TCL?. or do i need to write a file and import it via a xschem command?

[StefanSchippers]

Xschem communicates with the simulator via the netlist. This is the only reasonable portable way to have a working setup for different simulators. So the problem is controlling what goes in the netlist.

Usually a schematic ready for simulation consists of some circuits and some simulator commands (usually embedded into a code.sym or similar component).

You can fetch the commands at the xschem prompt with:

set cmd [xschem getprop instance COMMANDS value] You can change the code that is now into cmd and update the code instance: xschem setprop instance COMMANDS value $cmd

Another way to parametrize simulations is to use a code.sym element and wrap the whole value=... into a tcleval():

value="tcleval(
  .temp $mytemp
  .param VCC=$myvcc
  ...
  ...
)"

You then set tcl variables before generating the netlist:

set mytemp 125
set myvcc 4.5

The netlist should contain:

.temp 125
.param VCC=4.5

[olisnr]

thanks!

[StefanSchippers]

7: when You simulate, then You can specify the output filename easy like ngspice -b -r "$n.raw" -o "$d/ngspice.log" "$N" but if You want to load it back in to Xschem, thats not working. would it be possible, to make all the $names and $paths the same in every place of Xschem? (even in the spice-commands)

Why you say you can't load it back? all raw access functions take a file argument. Where the file is stored and the filename is under the control of the designer. Some menu commands like the ones adding a waveform load launcher orthe menu for loading the raw file do some reasonable guesses (raw file base name same as schematic name, located in the path specified by $netlist_dir),. In some examples I have setup testbenches that work both for ngspice and Xyce, so there must be two different raw files. In this case the "menu automation" fails. May be in these cases a file selector should be presented to the user. This is a nice thing to add.

The xschem annotate_op allows no file argument, in this case it assumes $netlist_dir/circuit.raw where circuit is the name of the schematic (circuit.sch)

[StefanSchippers]

As a first action when loading a raw file via the menu a file selector is presented. It is already in the default directory and with the assumed filename already filled in the selector textbox, so it just costs one more click to complete, but allows to select a different file.

[olisnr]

i was writing i "can't load it back" using the $n.raw code, i have to use in the ngspice command. i can use tor read a different TCL code, like the one You suggested for the "load-arrow". but i was thinking it would be nice, if every part in Xschem has the same variable names ($n $N or what ever).

it would make it easy to write a spice-command ("write $n.raw"), run the spice simulation (ngespice -r $n.raw) and load the wave-form-data (xschem raw_load $n.raw) if all this parts would use the same variable name scheme

[StefanSchippers]

I see. The $n, $N etc variables are "alive" just in the context of the simconf dialog box. these are local to a procedure. These variables are super short to make command lines reasonably short. I will not use such short variables at global scope. At global scope, in any context the way to retrieve file names and such is via the following commands / globals:

xschem get schname : get full path of current schematic xschem get current_name : name (no path) of current schematic xschem get current_dirname : directory containing current schematic $netlist_dir: directory where netlist is generated and simulation is run. xschem raw_query rawfile: returns full path of currently loaded raw file if any (or returns empty string) xschem get netlist_name fallback: return the name of the netlist that will (or is already) produced in $netlist_dir. Usually inherits the name of the schematic with an extension that depends on the netlist backend (.spice for spice), but can be set to any different name by the user Default or custom name is returned without the path (which is $netlist_dir) xschem get netlist_name: returns an empty string if no custom name was set by the user for the netlist, or the custom name.

Many users complain why there are 2 different methods to choose the output directory for the netlist and the name of the netlist itself. The reason is that xschem has also a split netlisting mode where each block will be netlisted in a separate file (possibly in different formats, spice, verilog, vhdl etc).

netlist_name can be changed with the xschem set command. netlist_dir is a tcl global so can be changed with plain tcl set command.

[StefanSchippers]

if i use a symbol with the schematic attribute, the netlist.spice includes both, the .subckt symname and the .subckt schematic

I have investigated this. The schematic attribute can be set on instances or inside the symbol. If set in the instance that specific instance will use the specified schematic. Any other instance not specifying any schematic attribute and using the symbol will be using the schematic associated to the symbol. This schematic is present in the netlist just because it is difficult to ensure no other instance deep down in the hierarchy will use it or not. The subcircuit removal could be eventually done at the end of the netlist process if no reference is found.

If the schematic attribute is specified inside the symbol ALL instances using the symbol will land on this specified schematic, and in this case the default schematic associated to the symbol (if existing) is NOT present in the netlist.

In the image below the netlist of comp_65nm.sch is inserted inside subcircuit comp_ngspice

[olisnr]

thanks. now i can put the TCL variables into the spice-command:

name="ngspice: set variables"
simulator=ngspice
only_toplevel=true 
value="tcleval(
  set schname           [xschem get schname]
  set current_name      [xschem get current_name]
  set current_dirname   [xschem get current_dirname]
  set netlist_dir       $netlist_dir
  set rawfile           [xschem raw_query rawfile]
  set fallback          [xschem get netlist_name fallback]
  set netlist_name      [xschem get netlist_name]
  set rawfilestart      $netlist_dir/[file rootname [xschem get current_name]]
)"

gives in the spice-netlist:

...
  set schname           /ALL/Xschem/design/cmos_example_opamp_casc_exp.sch
  set current_name      cmos_example_opamp_casc_exp.sch
  set current_dirname   /ALL/Xschem/design
  set netlist_dir       /ALL/Xschem/design/simulation
  set rawfile
  set fallback          cmos_example_opamp_casc_exp.spice
  set netlist_name
  set rawfilestart      /ALL/Xschem/design/simulation/cmos_example_opamp_casc_exp
...

but i struggle with the concat:

  set raw_ac            [string cat $rawfilestart _ac.raw] 
  set raw_ac            ${rawfilestart}_ac.raw 

are both not ok. do You see the problem?

[StefanSchippers]

I don't understand why you are putting TCL code into a code blocks that will then go into a spice netlist. Ngspice (or any other spice simulator) will not understand those lines. If you need tcl code to be executed , -say- to drive a simulation or a set of simulations you should put this code into a component that will not go into a netlist (and without using the tcleval(...) wrapper) . The best candidate is the launcher.sym component and place all the stuff into the tclcommand attribute.

You can then trigger the execution either by GUI (Ctrl-Left-Click) or by CLI: eval [xschem getprop instance h1 tclcommand] where in above sample line h1 is the instance name of the launcher in the schematic (set any name you like for this component)

[StefanSchippers]

Regarding the problem about the string concatenation consider this.

tcleval(.....) submits the inner string to the interpreter to do variable ($var) substitution and command ([cmd]) substitution (see the tcl subst command).

the string: set schname [xschem get schname] contains a tcl command and it will be substituted: set schname /.../.../.../xxx.sch

The resulting string is not further evaluated, it is just placed when writing the netlist.

If you want to go one level deeper in the evaluation do: [set schname [xschem get schname]] this line has 2 level of tcl commands which will be recursively evaluated. the return value of the above evaluation is the value of schname, that is now a new tcl global variable. in the netlist this line will be probably replaced by/.../.../xxx.sch

If a following line does something like set myvar ${schname}_some_trailer it will probably work as you expect. Again it will not create a myvar TCL global, it just spits out a line of text with the tcl syntax to set a variable. If you need to evaluate it do the same as above.

[StefanSchippers]

You can do very nasty things by attaching tcl code to schematic components. If you have a capacitor in the schematic and set its value as:

value="tcleval(0.2p[puts hello;return {}])" the netlist will just contain 0.2p as desired for the capacitor, however any time the component is drawn (because the @value in the capacitor symbol needs to be substituted) or a netlist is generated the hello word will be printed on the terminal xschem was started from (if any, otherwise lost in /dev/null).

the return {} at the end of the command list [...] will ensure an empty string is returned so nothing is attached after 0.2p.

This is a wasteful example just to show how the tcl evaluation goes.

[olisnr]

tanks a lot, now its working:

tcleval(
  set schname           [xschem get schname]
  set current_name      [xschem get current_name]
  set current_dirname   [xschem get current_dirname]
  set netlist_dir       $netlist_dir
  set rawfile           [xschem raw_query rawfile]
  set fallback          [xschem get netlist_name fallback]
  set netlist_name      [xschem get netlist_name]

                        [set rawfilestart $netlist_dir/[file rootname [xschem get current_name]]; return {}]
  set raw_ac            [string cat $rawfilestart _ac.raw]
  set raw_dc            ${rawfilestart}_dc.raw
)

gives:

  set schname           /ALL/Xschem/design/cmos_example_opamp_casc.sch
  set current_name      cmos_example_opamp_casc.sch
  set current_dirname   /ALL/Xschem/design
  set netlist_dir       /ALL/Xschem/design/simulation
  set rawfile           /ALL/Xschem/design/simulation/cmos_example_opamp_casc.raw
  set fallback          cmos_example_opamp_casc.spice
  set netlist_name

  set raw_ac            /ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw
  set raw_dc            /ALL/Xschem/design/simulation/cmos_example_opamp_casc_dc.raw

now i can write raw-files with different file-name endings, and use it in different plots :)

[StefanSchippers]

3. sometimes the simulation button dont goes read if ngspice is running. but sometimes it works, and i didnt found out whats different

I think this is now fixed. Pressing the Simulate button or giving the xschem simulate command (or just the tcl simulate command, xschem simulate is there for backward compatibility) will set the button to Red. This is just to inform users a simulation is already running. The Simulate button will not allow to launch other simulations while one is already running (anti-dumb-user feature, I want to avoid users clicking the button 10 times in a row, spawning 10 simulator processes), however the CLI command is always working (CLI users are not considered dumb). It is the designer responsibility to ensure it is used appropriately (you can run for example multiple simulations if you direct simulator outputs to different files.)

[olisnr]

i have an other question: if i have many simulator_commands.sym, some for commands, some for libraries and others for setting variables, how is the order in writing the netlist defined?

[olisnr]

8: if asimulator_commands.sym dialog is openxschem get schname crashes:

ich@x13g3:~$ xschem
xschem [~] xschem get schname

readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)

[olisnr]

also:

xschem [~] xschem getprop    
rename dir (null) to /tmp/xschem_emergencysave_cmos_example_opamp_casc_geedbagcbb failed
EMERGENCY SAVE DIR: /tmp/xschem_emergencysave_cmos_example_opamp_casc_geedbagcbb

FATAL: signal 11
while editing: cmos_example_opamp_casc

[StefanSchippers]

8: if asimulator_commands.sym dialog is openxschem get schname crashes:

ich@x13g3:~$ xschem
xschem [~] xschem get schname

readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)

This is a tclreadline problem. Solution for now: not throwing in commands while UI state is not idle. I have submitted the problemyears ago. They are like gnome developers, no answer. starting without tclreadline (xschem -r) does not crash

[StefanSchippers]

also:

xschem [~] xschem getprop    
rename dir (null) to /tmp/xschem_emergencysave_cmos_example_opamp_casc_geedbagcbb failed
EMERGENCY SAVE DIR: /tmp/xschem_emergencysave_cmos_example_opamp_casc_geedbagcbb

FATAL: signal 11
while editing: cmos_example_opamp_casc

Thank you! this is now fixed.

[StefanSchippers]

i have an other question: if i have many simulator_commands.sym, some for commands, some for libraries and others for setting variables, how is the order in writing the netlist defined?

the order is the order they are created. All instances are in a list. You can change the position in the list by selecting an instance and pressing Shift-S or with cli command xschem change_elem_order.

if order is A-B-C-D-E and I want C after D I can select C and set its sequence number to 3 (or more)

[olisnr]

super, this helps! it seems that thats a secret command, i dont find it in the menu...

9: if a ngspice-simulation end with errors its not possible to save the sheet, at cntr-s the * in the tab-names stays and the write-time of the HD isnt updated. but if You go in a subsheet with the autosave-option on, its saved anyway...

[olisnr]

for the simulation button, do You think it would be nice not only to code, if a simulation is running, but also if the simulator returned 0?

[StefanSchippers]

for the simulation button, do You think it would be nice not only to code, if a simulation is running, but also if the simulator returned 0?

Yes that would be very nice. I need to change the color of the SImulator button to Yellow while simulator is running, and turn to Green or Red depending on the exit code.

At least this is a color code that looks reasonable to me :-)

[olisnr]

yes sounds great, could also be used for the netlist generation

[olisnr]

this strange point No 9 shows his obstinate behavior after any error i think. i see it also if loading the waveforms dont work, because i put wrong file-paths in the dialogs. as example Xschem says:

raw_read(): failed to open file /ALL/Xschem/design/simulation/cmos_example_opamp_casc.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw for reading
extra_rawfile() read: /ALL/Xschem/design/simulation/cmos_example_opamp_casc.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw not found or no ac analysis
raw_read(): failed to open file /ALL/Xschem/design/simulation/cmos_example_opamp_casc.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw for reading
extra_rawfile() read: /ALL/Xschem/design/simulation/cmos_example_opamp_casc.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw not found or no ac analysis
raw_read(): failed to open file /ALL/Xschem/design/simulation/cmos_example_opamp_casc.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw for reading
extra_rawfile() read: /ALL/Xschem/design/simulation/cmos_example_opamp_casc.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw/ALL/Xschem/design/simulation/cmos_example_opamp_casc_ac.raw not found or no ac analysis

[StefanSchippers]

super, this helps! it seems that thats a secret command, i dont find it in the menu...

9: if a ngspice-simulation end with errors its not possible to save the sheet, at cntr-s the * in the tab-names stays and the write-time of the HD isnt updated. but if You go in a subsheet with the autosave-option on, its saved anyway...

This is strange. Yes there si something wrong here.

[StefanSchippers]

It seems to me that the problem is the '*' not updated in the tab and in the window name. The save is however done.

[StefanSchippers]

for the simulation button, do You think it would be nice not only to code, if a simulation is running, but also if the simulator returned 0?

With ngspice there is no clear indication of a failure, however. Even if a simulation does not converge, as long as the simulator does not crash the return code might be 0 (success). There are some measures that can be taken as explained in Section 18.5 of the ngspice manual. In general you should set some goals and do some meas statements or similar to measure your targets, then set yourself the error code (quit 0 / quit 1) if target is met or unmet.

[olisnr]

in a first step, i would be ok to get only syntax-errors in the netlist. if something is really wrong it would be nice if we get a "red". if it dont converge, the simulation will need much time, and the user will see, that the simulation needs absurd much time. he will the check the log anyway, i think.

[StefanSchippers]

I have a first implementation, there are some issues with ngspice error reporting for syntax errors, convergence issues etc as explained in Sec. 18.5 of the manual. I have set the strict_errorhandling variable as suggested in the manual, the video was done with this variable set, but error reporting remains inconsistent.

https://github.com/StefanSchippers/xschem/assets/69359491/f86d5274-d450-4cea-910e-f2122bb60908

[olisnr]

i use strict_errorhandling anyway since i saw obvious wrong data from ngspice simulations... may be Xschem should tell the user, or set it per default

[olisnr]

it seems not to work in batch-mode with ngspice -b -r "$n.raw" "$N" -o ngspice.log. the button turns to green straightaway.

[StefanSchippers]

it seems not to work in batch-mode with ngspice -b -r "$n.raw" "$N" -o ngspice.log. the button turns to green straightaway.

to me it seems to work, but update the program, since i have done some updates on the button color handling as explained in the clip.

https://github.com/StefanSchippers/xschem/assets/69359491/5424de7d-7ed2-4ec7-8150-d823bf3b62dd

[olisnr]

https://github.com/StefanSchippers/xschem/assets/120017377/f45ad111-12be-4a85-9810-6ad1b1ff7d3f

[StefanSchippers]

If you run ngspice inside a terminal the process that gets monitored by xschem is the terminal. Some desktop environment terminals do not even start as a new process, if an instance of the terminal is already running on the system it attaches to the existing instance, hands over to it the script to execute and exits immediately. Always keep an old terminal like xterm or rxvt, and try to see what happens with these, Desktop terminals have all kind of fancy and non standard (often non-sense) behaviors. I remember the lxterminal of the LXDE desktop (the last DE that I used, before deciding to get rid of all this stuff and get myself the tools I need) did not even pass the environment to the shell to be exected therein, using the environment of an existing instance, This is extremely wrong/insecure/nonstandard/(add more as you like).

[StefanSchippers]

I have done the test, instead of my usual terminals I have tested lxterminal (after 10 years). behavior is the same. If I run ngspice inside lxterminal and there is no running lxterminal on the system if behaves like all normal terminals. Xschem waits for the lxterminal to finisch.

If there is an already running lxterminal somewhere on the system the behavior is exactly as yours. It's like you give some stuff to deliver to DLH, DHL gives it away to some other delivery immediately and sets the tracking info to "delivered"

[olisnr]

i dont ran ngspice in a terminal, i used the terminal to run tail -f ngspice.log. the ngspice was run from Xschem via ngspice -b -r "$n.raw" "$N" -o ngspice.log

[olisnr]

i wanted to show how long the simulation is running, compared to the coloring of the simulation-button

[StefanSchippers]

Ahhh, sorry. Misunderstanding.

It looks like if you run a simulation in batch mode (ngspice -b) and direct the simulator output to a file (-o ngspice.log) , ngspice closes stdout immediately after launching. This means the control tower (xschem) will get an EOF, that occurs normally when a process is finished. Xschem knows this situation and avoids to shoot itself in the foot. Normally after an EOF the file descriptor should be closed, but if the child process is still running (with closed stdout) the close command deadlocks. A close command is necessary to get the exit status of the child process, but as the manual says: "If channelId is a blocking channel for a command pipeline then close waits for the child processes to complete". In these scenarios xschem does a nonblocking close. The other end has closed the radio transmitter and is out of sight, so just do an asynchronous close that always succeeds. No way to track if the flight got to destination or crashed somewhere.

The simple trick is to wrap the command into a subshell, so xschem tracks the subshell and (as long as it is not a freedesktop.org made shell) the shell EOF's when she has done the assigned tasks and forwards to the caller the exit status of the assigned task too.

sh -c "ngspice -b -r '$n.raw' '$N' -o ngspice.out"

[StefanSchippers]

You can attach callbacks when invoking a simulation, like this:

xschem [~] simulate {if {$execute(exitcode,last) ne 0} { puts FAIL } else {exit}}

You will need to launch the simulate command again and again until the return code is success, then it closes xschem so you can go lunch :-) ... and in the middle of the lunch you realize the exit command does not save the circuit.