<@U01819B63HP> The latest xschem does not bring up...
# xschem
h
@Stefan Schippers The latest xschem does not bring up
top.sch
for sky130A when I just start xschem w/o an argument… any idea why? (I am referring to our IIC-OSIC-TOOLS image, why I currently try to build for the next release.)
c
In my
xschemrc
, I see the lines
Copy code
###########################################################################
#### WINDOW TO OPEN ON STARTUP: XSCHEM_START_WINDOW
###########################################################################
#### Start without a design if no filename given on command line:
#### To avoid absolute paths, use a path that is relative to one of the
#### XSCHEM_LIBRARY_PATH directories. Default: empty
set XSCHEM_START_WINDOW {sky130_tests/top.sch}
Does that have anything to do with it? Question back: I'm thinking of playing along with the analog layout synthesis contest. As usual, by far the most difficult part will be the dependency and configuration hell (for a minor example, see the above
xschemrc
case). How can I keep exposure to docker, python, anaconda, … to the absolutely necessary minimum, and how can I make that minimal installation a non-moving target (i.e., immune to "well-meaning" tool updates)? At the moment, I'm using Tim Edwards's tool chain configuration which avoids all that software configuration crud as much as possible.
p
Hello Harald, I just built xschem from source and launched it, got the expected window. One difference may be that I like to have my xschemrc, with all the sky stuff, in ~./xschem That's where
set XSCHEM_START_WINDOW {sky130_tests/top.sch}
is setup. Is it in the rc file you're using?
@Christoph Maier, I traditionally do all my tool installs on my bare system and have often been through dependency hell... I just did an analog design for TT06 and did everything using the Tiny Tapeout VM (an artifact of the actions at https://github.com/TinyTapeout/analog-virtualbox-vm-sky130a/actions installable in virtualbox). That went really nicely, but didn't come with CACE built-in or necessarily the latest/greatest. So that could work, but I'm also going to try the IIC-OSIC-TOOLS, and I think it's one of the recommended paths for chipalooza... I'd guess either one would bet setup well enough for mostly plug & play and, as long as you just play in the sandbox and don't update it, I don't see how you could be bitten by unexpected updates midstream.
c
@Pat Deegan, I've let the chipalooza2024 deadline whoosh by because I don't really need the confirmation that I can get a tiny piece of silicon (been there, done that), but using it as an excuse for a deep dive into the details of the key infrastructure (ngspice, magic, xschem). I might venture into a standard environment for anaconda, because I already have some of them lying around when I got Jupyter notebooks to run in 2021 (and don't remember how).
👍 1
h
Thanks @Pat Deegan and @Christoph Maier on the hint with
XSCHEM_START_WINDOW
, not sure why this does not work on the latest release. I just rolled back the xschem version and works fine again. As I want to push out the new IIC-OSIC-TOOLS release I leave it at that for now, and debug it for the next release. P.S. I use the stock
xschemrc
that is part of the PDK, not a local one.
@Christoph Maier Solving some of the dependency issues is the main motivation for IIC-OSIC-TOOLS, because I want an environment that “just works”(TM). 🙂
❤️ 1
c
@Harald Pretl, I'll give it a shot, sometime between now and the start of https://sscs.ieee.org/about/tc-ose/sscs-pico-design-contest Might be the least painful exposure to the version and dependency hell of docker, anaconda, etc.
s
@Harald Pretl the default schematic (
XSCHEM_START_WINDOW
) does not load if you launch xschem with command line arguments, for example
xschem --command ....
or
xschem -b
or any other command line option. The reason is if you launch schem to do some background tasks you don't want the start schematic to get in the way. If there are command line switches you use and still want the
XSCHEM_START_WINDOW
loaded let me know, I will add exceptions.
h
@Stefan Schippers What I often use is
-b
(when I don’t need the Tcl console, which is pretty much always) and
--rcfile
It would be great if these could be exceptions.
c
@Stefan Schippers, this 30th of April is the perfect date to point out that while adding exceptions to handle specific user requests, nearly everything that matters is a side effect, and the open design tools would greatly benefit from minimalistic, consistent input grammars instead of an exploding number of exceptions. CACE etc., while I start seeing the sense behind them, are to a large extent workarounds to compensate lack of understanding of insufficiently explained schematic capture and layout programs, and the more exceptions you add, the harder (with, considering side effects, the factorial of the number of exceptions) it becomes to ever produce a sufficient documentation for the critial tools. Goes completely against the Software Engineering mindset that more features are better.
That said, where's the authoritative documentation of
xschem
command line options, anyhow?
s
@Harald Pretl I have reverted the change, if no file to load is given $XSCHEM_START_WINDOW is loaded regardless of other command line switches. It will be user's task to comment out this seting in xschemrc if they want to. @Christoph Maier the list of cmdline options is
xschem -h
or
man xschem
.
💡 1
🙌 1
c
@Stefan Schippers, thanks! Now I need to figure out the not-so-obvious question what is documentation and what are error and warning messages, and which of the various contexts within xschem the options belong to — they seem to be neither consistently sorted by context nor by alphabetical order. The
-b
option is immediately helpful, because it unlocks my launching terminal … but why would I need the tcl console in the first place, anyhow?
Copy code
xschem --help
Warning: PDK_ROOT env. var. not found or empty, trying to find an open_pdks install
open_pdks installation: using /usr/local/share/pdk
SKYWATER_MODELS: /usr/local/share/pdk/sky130A/libs.tech/combined
SKYWATER_STDCELLS: /usr/local/share/pdk/sky130A/libs.ref/sky130_fd_sc_hd/spice
usage: xschem [options] [schematic | symbol ]
Options:
  -h  --help           Print this help.
  -b  --detach         Detach Xschem from console (no output and no input from console)
  -n  --netlist        Do a netlist of the given schematic cell.
  -v  --version        Print version information and exit.
  -V  --vhdl           Set netlist type to VHDL.
  -S  --simulate       Run a simulation of the current schematc file 
                       (spice/Verilog/VHDL, depending on the netlist 
                       type chosen).
  -w  --verilog        Set netlist type to Verilog.
  --tcl <tcl_cmd>      Execute specified tcl instructions before any other action,
                       after sourcing xschemrc, this can be used to change xschemrc variables.
  --preinit <tcl_cmd>  Execute specified tcl instructions before any other action,
                       and before loading xschemrc.
  --script <file>      Execute specified tcl file as a command script (perhaps with xschem  commands).
  --command <tcl_cmd>  Execute specified tcl commands after completing startup.
  --diff <file>        Show differences with given file.
  --tcp_port <number>  Listen to specified tcp port for client connections. (number >=1024).
  -i  --no_rcload      Do not load any xschemrc file.
  --netlist_path <path>
  -o <path>            Set output path for netlist.
  --netlist_filename <file>    
  -N <file>            Set name (only name, not path) of top level netlist file.
  -t  --tedax          Set netlist type to tEDAx.
  -s  --spice          Set netlist type to SPICE.
  -y  --symbol         Set netlist type to SYMBOL (used when drawing symbols)
  -x  --no_x           Don't use X (only command mode).
  -z  --rainbow        Use a raibow-looking layer color table.
  -W  --waves          Show simulation waveforms.
  -f  --flat_netlist   Set flat netlist (for spice format only).
  -r  --no_readline    Start without the tclreadline package, this is necessary
      --pipe           if stdin and stdout are to be redirected. This also prevents xschem
                       from closing stdin / stdout / stderr even if invoked from pipes.
  -c  --color_ps       Set color postscript.
  --plotfile <file>    Use <file> as output for plot (png, svg, ps).
  --rcfile <file>      Use <file> as a rc file for startup instead of the
                       default xschemrc.
  -p  --postscript
      --pdf            Export pdf schematic.
      --png            Export png schematic.
      --svg            Export svg schematic.
  -q  --quit           Quit after doing things (no interactive mode).
  -l <file>
  --log <file>         Set a log file.
  -d <n>
  --debug <n>          Set debug level:  1,  2,  3,..  C program debug.
                                       -1, -2, -3...  TCL frontend debug.

xschem: interactive schematic capture program

Example:   xschem counter.sch
the schematic file `counter.sch' will be loaded.

setup_tcp_bespice: problems finding a free TCP port
couldn't open socket: address already in use
h
@Stefan Schippers Thanks!
s
@Christoph Maier the console is used since in some cases you want to load / execute scripts or commands. Currently xschem uses the terminal it is launched from, like tclsh or wish does. The tclreadline package is used to enable command history (recall older commands with up arrow, basically). However My plan for the future is to remove tclreadline: 1. eliminate a lib dependency 2. tclreadline is crappy and abandonware May be @Tim Edwards has done something like this for the magic console.
c
@Stefan Schippers, my idea is to find some sort of grammar to unify all the grammars of the fundamental forces in the analog/mixed signal toolchain, to come up with some kind of minimal grammar that is as simple as possible, but not simpler. Difficulties: 1. being nitpicky about details, and trying to remove fancy new features instead of adding them, wins you no popularity contest anywhere 2. Digging into the inner workings of critical infrastructure takes much longer than simply patching over it. 3. I need not only to find a Safe Space where I can focus on the important stuff against the pressure of business types who have the perennial urge to pitch flashy, but detrimental new features and sell out my work on the foundations before they are ready for safe release (i.e., from being used for short term profit expectations of the business suit suite), but also a way to cover the expenses for the Safe Space. 4. The small handful of core developers who have maintained the critical infrastructure since about forever, are so distracted by day-to-day requests for exception that it's next to impossible to get their curiosity, let alone their attention.