Simulations with differen corner-library (`.lib ../.../cornerMOSlv_psp.lib mos_tt and ...ss ...ff ...fs ...sf`), what would You do?

[StefanSchippers]

@olisnr

if You want to make some simulations with differen corner-library (.lib ../.../cornerMOSlv_psp.lib mos_tt and ...ss ...ff ...fs ...sf), what would You do? i can use a launcher.sym to set a lib-variable and then xschem netlist; xschem simulate but i didnt figured out, how to wait of the end of the simulation before update the lib-variable, and simulate again. or i could use TCL to write different spice-netlists and run them in parallel (also without knowing when it ended)...

now it looks like:

and the possibility to load different .raw-files is REALLY great!

Originally posted by @olisnr in https://github.com/StefanSchippers/xschem/issues/141#issuecomment-1816409510

[StefanSchippers]

would it be good to start the xschem file with #!/usr/local/bin/xschem ?

I never tested this. It seems if you put the above hashbang on the first line of a .sch file , make it executable you can call the .sch file directly. seems working, but never tested and used... if you modify the schematic and save the hashbang is not preserved of course.

[olisnr]

the question is, if You want to use some mechanism to link the file to Xschem? optimal also in windows (even if i dont care about it). then there are many different *.sch files and simply use the extension isnt usable.

i like to double-click in a file-browser to start the schematics.

[StefanSchippers]

when a schematic file begins with #!/path/to/xschem the shell recognizes it is a script, starts the specified program (xschem) and gives the entire file as argument to the program. Since the shebang starts with # and xschem considers lines beginning with # as comments it is safe to shebang schematic files. However the shebang is lost when saving.

[olisnr]

it could also be an TCL-script that loads it self in Xschem (and installs Xschem on systems without (and removes windows and installs linux (and so on))).

[StefanSchippers]

the question is, if You want to use some mechanism to link the file to Xschem? optimal also in windows (even if i dont care about it). then there are many different *.sch files and simply use the extension isnt usable.

i like to double-click in a file-browser to start the schematics.

If this is what you want to do then the shebang is not the right way to go. You need to register a new file type with the default application (xschem). May be some info can be found here or here.

[olisnr]

about the memory i think: if the OS is not taking back freed memory, because it thinks that the application will need it again, then Xschem should not allocate new memory from the OS, because it has already more then it needs. we load always the same size of data, and free also that much. only some handles for ngspice and so on will grow. may be i make an TCL-loop that loads and unloads the hole time an look, if i overflow the RAM at some point.

[StefanSchippers]

I have done a test (on a smaller test case) to load/unload raw files 1200 times, no significant memory increase was observed (just a small quantity, but may be glibc or tcl buffers xschem does not control directly).

https://github.com/StefanSchippers/xschem/assets/69359491/baf11e29-b841-47c2-aba8-1ac0b95815d0

[olisnr]

this is clear now. the simulation was missing the list of the write blabla.raw before the append. so all this simulations without the OP where getting bigger and bigger... haha

  ...
  save all
  op
  write [rawfilestart]${lv_corner}_hv${hv_corner}.raw

  set appendwrite

  alterparam rset = $rset0
  reset
  save all
  dc VDD 0 5.5 0.01
  write [rawfilestart]_dc_lv${lv_corner}_hv${hv_corner}.raw
  ac dec 10 $fstart $fend
  ...

now it stays at 55MB :)

[olisnr]

here comes the testcase: i started Xschem from the dirctory with the two .sch files.

then i clicked "Netlist", "Simulate" and then "Waves - Dc" then i clicked "Ok". the waveforms are loaded, but the gods of the semaphore arent happy whit it...

blocktest.zip

[StefanSchippers]

here comes the testcase: i started Xschem from the dirctory with the two .sch files.

then i clicked "Netlist", "Simulate" and then "Waves - Dc" then i clicked "Ok". the waveforms are loaded, but the gods of the semaphore arent happy whit it...

blocktest.zip

Unfortunately I can not trigger the problem. May be you have some specific xschemrc setting? (there was no xschemrc so i created one with your defauts).

https://github.com/StefanSchippers/xschem/assets/69359491/cb6e3ec2-1ce3-47cc-8597-308aeee8a809

[olisnr]

my settings:

set replace_key(Control-z) u        ;# undo
set replace_key(Control-y) Shift-U  ;# redo
set replace_key(z) Control-z        ;# zoom out
set unzoom_nodrift 1
set draw_crosshair 1
set persistent_command 1 ;#for click instead of w

#set enable_stretch 1 ;#for preserve the connections
#set connect_by_kissing 1 ;#for preserve the connections
set unselect_partial_sel_wires 1 ;#for preserve the connections

set local_netlist_dir 1

#append XSCHEM_LIBRARY_PATH :/ALL/Xschem
append XSCHEM_LIBRARY_PATH :/ALL/Xschem/symbol
append XSCHEM_LIBRARY_PATH :/ALL/Xschem/design
append XSCHEM_LIBRARY_PATH :/usr/local/share/xschem/xschem_library

set no_ask_save 1

set editor {xed -w}

set terminal {gnome-terminal }

set cadgrid 80

set autotrim_wires 1
set incremental_select 0
set zoom_full_center 1

set tabbed_interface 0

[olisnr]

https://github.com/StefanSchippers/xschem/assets/120017377/b6379c7a-f180-4014-9723-aadcfa54dd9a

[StefanSchippers]

Thank you for the test case and the update video. Looking to find the culprit. Is your installed xschem the last one? just to avoid research with older commits

[olisnr]

its the commit from today (-13h)

[StefanSchippers]

Please create an xschemrc file in the blocktest/ directory, containing this:

set replace_key(Control-z) u        ;# undo
set replace_key(Control-y) Shift-U  ;# redo
set replace_key(z) Control-z        ;# zoom out
set unzoom_nodrift 1
set draw_crosshair 1
set persistent_command 1 ;#for click instead of w
#set enable_stretch 1 ;#for preserve the connections
#set connect_by_kissing 1 ;#for preserve the connections
set unselect_partial_sel_wires 1 ;#for preserve the connections
set local_netlist_dir 1

set XSCHEM_LIBRARY_PATH {}
append XSCHEM_LIBRARY_PATH :[pwd]
append XSCHEM_LIBRARY_PATH :$XSCHEM_SHAREDIR/xschem_library

set no_ask_save 1
set editor {xed -w}
set terminal {lxterminal}
set cadgrid 80
set autotrim_wires 1
set incremental_select 0
set zoom_full_center 1
set tabbed_interface 0

This way when xschem starts this file will be used and not any other. Does the 'semaphore' problem still occur?

[olisnr]

its still blocked

[StefanSchippers]

I think last commit fixes the problem. This was very hard to spot since it was a combination of different things (including 4 lines deleted in xschem.tcl by mistake , probably due to the "interrupted while doing a change" effect and the change got done halfway :-) )

There was a flaw in the "configure simulators and tools"

What you need to do:

• If there is a file ~/.xschem/simrc rename to something different, like ~/.xschem/simrc_old.
• start xschem and reconfigure Simulation->Configure simulators and tools. If you need you can look in the simrc_old for command lines. Do not keep the old simrc file since it is probably broken.

I think the semaphore locking will no more occur. Please if you have a chance to test let me know. Thank you for your patience and support.

[olisnr]

Super! its working!

(& i was even afraid i have to reinstall windows!)

in the diode-example the model is model=dantenna. do You know if this is a "anti-antenna diode" for protection of the gate-isolation?

[olisnr]

something other is strange: if i open a sub-sheet via alt-e, and open a dialog-box in this sub-sheet, then the focus jumps back to the top-sheet, if i click into the dialogbox.

https://github.com/StefanSchippers/xschem/assets/120017377/3a0ef5cf-2dce-49c4-9168-9fe28dbd6041

and also the mouse is a bit strange:

https://github.com/StefanSchippers/xschem/assets/120017377/1cb1425d-99ee-4f64-a98f-84f8d5ef14f3

[StefanSchippers]

Thank you for reporting this. In multi window interface now clicking on an element to edit its attributes (as well as many other dialog boxes) will no more raise the top sheet. Please test.

For the second problem, how windows are focused (and how windows loose focus) is decided by the window manager. Can you please click into a window and see if the mouse behaves correctly? some focus policies require a click to activate a window (Click to focus) some others not (Focus follows Mouse) Modern window managers have then a plethora of other fancy options, may be the next generation WMs will use AI to decide.

[StefanSchippers]

In general multi window interface is not recommended. It is MUCH better to fire another xschem instance if you want another separate window (or use tabbed interface). A single xschem process handling multiple windows is tricky as it must switch context to the right window whenever the mouse flies over a window or enters / exits a window. Since the application <--> Xserver is asynchronous there are many corner cases that can lead to malfunction. It is complex since it is a threesome: Application - Xserver - Window manager. In tabbed interface the switchover is simpler and explicit. You click the tab.

[olisnr]

... It is MUCH better to fire another xschem instance ... what does this mean? open the sub-sheet in a new Xschem process? dont i do this using the anti-tab interface?

[olisnr]

the "jiump to top" problem is fixed. but i also think sometimes the Tk isnt sooo perfect matched to the fancy new window-managers: evey time the mouse is not over the text-field from a dialog-box, the text-field looses the keybord-inputs. other programs like xed dont do this. You can go with the mouse on even some other screens, and as long You dont click somewhere, all keyboard input is included.

[StefanSchippers]

... It is MUCH better to fire another xschem instance ... what does this mean? open the sub-sheet in a new Xschem process? dont i do this using the anti-tab interface?

exactly. In windowed interface you are not creating a new process. Xschem just creates a new toplevel window. It is possible to open a subsheet in a different process with Alt-Shift-E

[StefanSchippers]

the "jiump to top" problem is fixed. but i also think sometimes the Tk isnt sooo perfect matched to the fancy new window-managers: evey time the mouse is not over the text-field from a dialog-box, the text-field looses the keybord-inputs. other programs like xed dont do this. You can go with the mouse on even some other screens, and as long You dont click somewhere, all keyboard input is included.

The focus policy is set by the window manager, either "focus follows mouse" or "click to focus". in "click to focus" mode, both on IceWM and FVWM the tk text boxes behave exactly like other applications. Some window managers can apply different policies to different applications, but this depends on the WM.

https://github.com/StefanSchippers/xschem/assets/69359491/e1ac7320-2107-4638-934f-8c555e4fe7f4

[olisnr]

i have the click to focus active per cinnamon-default:

but as example if i go from the Tk-dialog over the Xchem-window, the dialog losses the focus. maybe thats some Tk-option somewhere?

https://github.com/StefanSchippers/xschem/assets/120017377/7e5f6fca-65f6-4d5d-94a8-208c9b2846a4

[StefanSchippers]

Oh yes, there is an option (was asked by someone don't remember):

set autofocus_mainwindow 0

try to add this line.

from the commit history: "_added xschemrc variable autofocus_mainwindow (default setting: enabled (1) ), if this variable is set moving the mouse to the main drawing area when a dialog box is open (typically while editing a component attribute list) will focus the main window, so user can move / zoom/pan the schematic using the usual commands, for example to look at a different part of the schematic while editing the component. If this variable is unset a click is needed to focus the main window. This will thus not allow to move / zoom, but allows to type into the dialog box if the mouse goes out of it_."

[olisnr]

great. it works!

but this option could be made a little bit even better: if You go with the mouse over the schematic-window and dont click, but zoom via mouse-wheel, then the dialog also looses the focus. if it wouldent, then You would have the possibility to navigate through the entirety schematic and stay focused in the text (some sort of software-ritalin).

[StefanSchippers]

Sorry i did nott remember this setting. By the way I also use this set autofocus_mainwindow 0 because the textboxes losing focus if you push the mouse with the arm while typing is annoying.

[olisnr]

yes, but navigating across the schematic while a text-dialog is open is also great. we need the option: set autofocus_mainwindow_while_zooming_via_mouse_wheel_around 0! and my experience with Xschem, says me this option is allready implementet! (i will try it out)

[olisnr]

by the way, what settings are You using Yourself?

[olisnr]

if i have more the 2 Xschem as there own process the copy-function does work a bit strange: the part is captured in the first window i move over.

https://github.com/StefanSchippers/xschem/assets/120017377/e904e248-6aa3-4a6e-8deb-924af2a3e364

[StefanSchippers]

Yes this is done on purpose, to allow copying pieces across windows. If this is not desired move the other window apart or minimize it.

[olisnr]

copy across windows is very desired and it would be interesting to be able to copy to any window: if i have 4 windows open (in a gid of 2 x 2), its only possible to copy to 2 of them. im not able to copy to the window thats diagonal from the source. its also strange, thats not possible to take the part back in to the source-window, but only if i was touching a 2nd target window. my work around is cntr-c cntr-v

[StefanSchippers]

Yes the communication between the different windows is limited. I will look if there is a way to improve that. I also found some crashes while aborting (with escape) such operations, so I have something to do in the afternoon :-)

[StefanSchippers]

The occasional crash problem (when copying between windows) is fixed. Will look if there is a simple way for each target window to grab the copy (including the window the copy started from).

[olisnr]

now i had a crash while autorangeing (f - key) the y axis of a plot. Xschem said:

...
Raw file data read: /ALL/Xschem/design/simulation/aa_pmosfets_m_factor.raw
points=1, vars=282, datasets=1 sim_type=op
Raw file data read: /ALL/Xschem/design/simulation/aa_pmosfets_m_factor_dc.raw
points=38507, vars=283, datasets=1 sim_type=dc
Raw file data read: /ALL/Xschem/design/simulation/aa_pmosfets_m_factor_ac.raw
points=61, vars=566, datasets=1 sim_type=ac
free_rawfile(): clearing data
free_rawfile(): clearing data
free_rawfile(): clearing data
Raw file data read: /ALL/Xschem/design/simulation/aa_pmosfets_m_factor.raw
points=1, vars=282, datasets=1 sim_type=op
Raw file data read: /ALL/Xschem/design/simulation/aa_pmosfets_m_factor_dc.raw
points=38507, vars=283, datasets=1 sim_type=dc
Raw file data read: /ALL/Xschem/design/simulation/aa_pmosfets_m_factor_ac.raw
points=61, vars=566, datasets=1 sim_type=ac
done
EMERGENCY SAVE DIR: /tmp/xschem_emergencysave_aa_pmosfets_m_factor_eeafadebag

FATAL: signal 11
while editing: aa_pmosfets_m_factor

i have plot crashes from time to time, but i cant reproduce it. sometimes it crashes also in the plotdialog.

xschem_emergencysave_aa_pmosfets_m_factor_eeafadebag.zip

[StefanSchippers]

The copy between windows is now improved. please test. Thank you for the info about the crash while zooming. If I can trigger the crash it would be easy to fix.

[olisnr]

what is in the xschem_emergencysave_aa_pmosfets_m_factor_eeafadebag? is it helpful?

[olisnr]

now i had the same with auto-ranging the x-axis. load the .raw files and autorange:

aa_pmosfets_m_factor.sch.zip

[olisnr]

copy via c works great.

there remain are some "ghost" devices on the window, that looses there focus, maybe this could also be removed in the correct event.

but it works!

[StefanSchippers]

what is in the xschem_emergencysave_aa_pmosfets_m_factor_eeafadebag? is it helpful?

In case of a crash a signal handler is called. If the signal handler is able to complete its duty, the undo stack is saved to /tmp/xschem_emergencysave_xxxxxx directory.

The directory contains all undo levels (up to MAX_UNDO, 80) present when the program crashed. these undo1, undo2, .... undon files inside the directory are just gzip compressed xschem files.

you can restore one such undo by doing:

zcat /tmp/xschem_emergencysave_aa_pmosfets_m_factor_eeafadebag/undox > ~/xxx.sch

you can then open xxx.sch and if it looks ok you get your schematic back. You should do a ls -ltr /tmp/xschem_emergencysave_aa_pmosfets_m_factor_eeafadebag to see the last undo that was written. This is the most recent schematic you were working on when xschem crashed.

My plan in the future is to add a GUI recovery option. If xschem recognizes such an emergencysave directory matching the file that is being edited it might ask the user if he wants to restore the schematic from there. or just forget it and delete.

But a more important plan is to avoid such crashes :-)

[StefanSchippers]

now i had the same with auto-ranging the x-axis. load the .raw files and autorange:

aa_pmosfets_m_factor.sch.zip

Thank you I hope to be able to trigger the failure so I can fix that. If you start the schematic and just load the raw files (no simulations) do you see the crashes? or does this happen only if you run the simulations before loading the graphs?

[olisnr]

no: i open the schematic, then i load the .raw-data via the "Wave - OP annotate", and the i try to autorange different axis from different plots until it crashes. may be You have to reload if it dont crashes fast enough. on my laptop it crashes so all 6 tries or so...

[StefanSchippers]

now i had the same with auto-ranging the x-axis. load the .raw files and autorange:

aa_pmosfets_m_factor.sch.zip

I am looking at the simulation commands in the schematic (I can not run the sims since I have not the pdk/model data)

This loop:

    foreach corner $corners {
        set hv_corner $corner; 
        xschem netlist; 
        delay 111;
        set [string cat {id_} ${corner}] [simulate]; 
    }

should be modified by putting the delay 111 after the [simulate] line The reason is you must give some time to ngspice to read and parse the netlist before generating a new netlist. I also recommend using 300ms at least to ensure ngspice has finished reading the netlist:

    foreach corner $corners {
        set hv_corner $corner; 
        xschem netlist; 
        set [string cat {id_} ${corner}] [simulate]; 
                delay 300
    }

PS: In TCL you don't need to close each line with ;. ; is used to separate commands on the same line, like in bash

[StefanSchippers]

Good news. I also had a crash while full-zooming graphs. I think I can start debugging.

[StefanSchippers]

I think the occasional crash while full-zooming graphs is fixed now. graph_fullxzoom() function did look up the sweep variable (the x axis) position in raw file before switching to the graph specific raw file, so looking in a raw file that is potentially not the one used in the graph. Can you please try to crash again with the full x/y autoranges? Let me know if you see differences. I do no more see crashes now. Thank you for your cooperation.

[olisnr]

should be modified by putting the delay 111 after the [simulate] line The reason is you must give some time to ngspice to read and parse the netlist before generating a new netlist. I also recommend using 300ms at least to ensure ngspice has finished reading the netlist:

  foreach corner $corners {
      set hv_corner $corner; 
      xschem netlist; 
      set [string cat {id_} ${corner}] [simulate]; 
                delay 300
  }

You are right, the delay is at the wrong position. but it would be saver to write different netlists. i will try this.

[olisnr]

now i had a "undo" button from an Xschem instance on the screen. i made a video, but the button was from the other instance. it disappeared with closing the 2nd Xschem. i hope i can reproduce it...

https://github.com/StefanSchippers/xschem/assets/120017377/02a90787-3027-4a44-b25a-f923c35b934d

[StefanSchippers]

This is the Undo tooltip. If the tooltip remains open you must hover the mouse over the undo toolbar button of the xschem instance that generated it. It has happened to em also once. Difficult to reproduce.