@Matt Venn with the web browser xschem viewer, is the

xschemrc

file expected to be in the same directory as the schematic? It looks like at least some of the chipaloosa designs have the

xschemrc

file in the parent directory.

It doesn't read xschemrc at all - rather, takes some heuristic approach to finding the subcircuit symbols:

Ok. My misunderstanding. The schematics with the xschemrc file in the parent directory have symbols with relative devices that start with

xschem/

which the web browser viewer can’t find if the specified schematic is in that

xschem

directory.

Can you drop a link to such repo?

Thanks! Added a heuristic to look for the file relative to the repo's root, seems to do the trick in this case: https://github.com/TinyTapeout/xschem-viewer/commit/e808113483abdddfb9eab77126ebd1b6b39f9a82

For what it's worth, if you try to creatively combine chipalooza circuits no one else has connected before, you run into a pandemonium of xschem path definition inconsistencies.

@Christoph Maier Interested in hearing what problems you are encountering. Theoretically, it should be as simple as cloning the repo and adding the relevant paths to the

XSCHEM_LIBRARY_PATH

variable in the local

xschemrc

file. Conflicting cell names will always be a problem (maybe a prefix convention would be advisable), as will locally copying (and altering) libraries.

@Mitch Bailey, after an Easter break, I'm looking into

xschemrc

. First problem:

append XSCHEM_LIBRARY_PATH :[file dirname [info script]]

is not documented in this manual: https://xschem.sourceforge.io/stefan/xschem_man/tutorial_xschem_libraries.html Such inconsistencies take forever to sort out, and adding yet another syntax to do things increases the complexity with the factorial of the different ways to do things.

@Christoph Maier I feel your pain. I also find tcl to be somewhat cryptic. Although, I imagine this would do the same thing.

append XSCHEM_LIBRARY_PATH :$env(PWD)

Now which would be the way introducing the fewest inconsistencies and ambiguities that would tell xschem: if you don't find the schematic or symbol in the current directory or its subdirectories, try again from

..

(i.e., one directory up)? The PROBLEM here is the _stackoverflow problem_: For each good solution, there are at least 3 that obfuscate things unnecessarily or have bad side effects.

> The PROBLEM here is the _stackoverflow problem_: > For each good solution, there are at least 3 that obfuscate things unnecessarily or have bad side effects. Very true. But then again, stackoverflow does provide answers that I can’t find (easily) anywhere else. Each ip should probably include instructions about what library paths should be added. I’m uncertain of how useful

..

would be here. For example,

# to use this ip in xschem, add the following to your xschemrc, replacing <INSTALL_DIR> with the cloned ip repo directory
append XSCHEM_LIBRARY_PATH :<INSTALL_DIR>/xschem
append XSCHEM_LIBRARY_PATH :<INSTALL_DIR>/xschem/macros

@Mitch Bailey, I'm starting to get somewhere with

set CURRENT_DIR [file dirname [info script]]
append XSCHEM_LIBRARY_PATH :${CURRENT_DIR}
append XSCHEM_LIBRARY_PATH :[file dirname ${CURRENT_DIR}]

in

xschemrc

, but then statements like

.lib $::SKYWATER_MODELS/sky130.lib.spice tt

only work in a control block with

format="tcleval( @value )"

specified, which, if not clearly specified in an easy to find written documentation, but buried in the bad SNR of a video, or worse yet, under the SNDR of a discussion forum, this is a MAJOR nuisance. ... and I still can't just start

xschem

from one place and netlist, let alone simulate, all the circuits cloned from this list.

@Christoph Maier good to hear that you’re making progress. I’ve not touched simulation, so I can’t help you there. Anything tcl related is pretty much trial and error for me too. It would be nice to have a sample recommended

xschemrc

for using ip, though.