@Stefan Schippers: Is is possible that when a schematic file is read in xschem, that the intepretation of "cwd" can be relocated to the location of the schematic being read? This would make projects using xschem schematics more portable. The problem is that I am trying to use entire projects as dependencies of other projects; I have, for example, a project called

sky130_ef_ip__analog_switches

which is a library of analog switches. It is all self-contained, so it has an "xschem" directory, and all the schematics in that directory include components from the same directory. If I want to use those switches in another project, then I create a directory called "dependencies" in that project, and under "dependencies" I clone the

sky130_ef_ip__analog_switches

repository. Then I can include a switch symbol by navigating to the repository and choosing a switch symbol. However, that symbol is linked to a schematic, and that schematic may refer to other symbols in the same directory. If so, then xschem cannot find those symbols. But it can find the schematic linked to the symbol, so it seems to understand that a schematic should be in the same location as its corresponding symbol, but doesn't understand that symbols instanced in the schematic might also come from the same directory as the schematic. It appears that xschem has some built-in concept of "cwd" because if I don't put the current directory into the XSCHEM_LIBRARY_PATH (either as an absolute path from root or as

.

), then xschem will still find symbols in the directory where I start up. It doesn't seem like too much of a stretch to ask that the built-in concept of "cwd" should change to the directory where a schematic is being read, so that local files referenced by that schematic will be discovered automatically. Hopefully I explained that in an understandable way. . .

That actually sounds like exactly what I was trying to do in another thread. And xschem does as a fallback try to resolve path as relative to

curdirname

which is the directory name of the current schematic, but it's sometimes buggy when generating the spice netlist because it messes with

curdirname

. But yeah, I'd love some way to have symbol references relative to the path of the schematic they are being referenced from.

Maybe a checkbox in the menu like "make schematic dir first in XSCHEM_PATH"?

@Luke Harold Miles Thing is it's not that simple because if you have a schematic that include a symbol, when you dig to the schematic of that symbol, the symbols within it need to be loaded relative to its path and not relative to the top level schematic path.

That is why I like the concept of libraries, cells, and cellviews in the openaccess (not so open) format.

@Tim Edwards the function you want is: "look for instantiated symbols in the directory of the containing schematic" before looking in the XSCHEM_LIBRARY_PATH directories. This is very clear when you navigate and descend into schematics and sub-schematics. However when a hierarchic netlist is produced there is no concept of "schematic containing the symbol". The same symbol could be instantiated more times in different schematics, at different hierarchy levels, all residing in different directories. At this point it is not clear where to look for the symbol. Xschem used to consider '.' the directory of the currently loaded schematic, this fancy interpretation was removed in commit 5e93182 since it generated an endless amount of problems, as this '.' dinamically changes depending on the schematic you are in. Netlisting algorithm is the following. • generate netlist of top level • for symbol=0 to

last_loaded_symbol

◦ load corresponding schematic (searching in the full list of paths if

search_schematic

xschemrc boolean variable is set or looking up the symbol

schematic

attribute if set or looking in the same directory of the symbol) ◦ generate netlist of schematic • end for note that as new schematics are loaded new symbols might be loaded, appended to the list and

last_loaded_symbol

will be incremented.

Hi @Stefan Schippers, I have a few related questions about what is the correct way to do things. Let's assume we have this basic setup:

project
├── testbench.sch
├── schematic.sch
└── schematic.sym

When I start xschem and place

schematic

inside

testbench

, the absolute path to

schematic.sym

is written to the file. This is not great as it is not portable, and most users are not even aware of this. Many of the Chipalooza submissions had absolute paths in their schematics. To be portable one would need to add

project

to the

XSCHEM_LIBRARY_PATH

. Then

schematic

inside

testbench

would refer to

schematic.sym

and not to the absolute path. This is also not perfect because you have to set

XSCHEM_LIBRARY_PATH

every time you want to edit a schematic. You can create a Makefile that does that for you, but then you are less flexible when creating new schematics. If you forget to set

XSCHEM_LIBRARY_PATH

when invoking xschem and then place some symbols, there would be absolute paths again. What is the correct solution here? Adding an xschemrc to

project

with the content

append XSCHEM_LIBRARY_PATH :[file dirname [info script]]

? This should always append

project

to

XSCHEM_LIBRARY_PATH

, no matter from where it is sourced, right? This would solve the issue, but if your project has subfolders, you can only ever start xschem from

project

, otherwise the paths would not be correct. Maybe that's just the price one has to pay? This should also work well with standalone IPs: you just need to source the xschemrc of the IP to add it to the

XSCHEM_LIBRARY_PATH

. I think the current handling of files in the same directory is not optimal. It helps users to get started designing their circuits without setting

XSCHEM_LIBRARY_PATH

, but in its current implementation it's more trouble than it's worth, I think 🤔️ I appreciate your feedback and thank you so much for your work on xschem 🙌️ Leo

All professional tools require to setup a library configuration before starting a project, like the cds.lib in Cadence. If you don't do that you won't be able to open / instantiate objects at all (you will not see anything in the library manager). If you insert a symbol from a directory that is not known to xschem the full absolute path will be used. This makes the design unportable, but at the very least will make it work on the system you are working on. When an instantiated object is inside a directory known by xschem the path prefix is removed from the symbol reference. This will make the design portable on a different system (after setting up the project xschemrc file on the new system that tells xschem where the design is located). That said, using

append XSCHEM_LIBRARY_PATH :[file dirname [info script]]

will append the directory containing the xschemrc. If you have

subfolder

inside this

project

directory it is OK, objects inside

subfolder/

will have a reference

subfolder/component.sym

, this is a relative path so design is portable. If you want to include other folders that are not children of

project/

you really should add these folders to your xschemrc. You can organize your project in many different ways, please read this manual page about xschem path management. You don't need to setup

XSCHEM_LIBRARY_PATH

every time you create a new schematic, you have to create a

xschemrc

file (which sets also

XSCHEM_LIBRARY_PATH

of course) once when you create a new project. We have done this for any project in Cadence. Often designers don't realize this because there is a CAD/EDA team working behind the scenes that does all this maintenance work. A project might be organized like this (for xschem schematics and symbols): •

.../project

◦

testbench

◦

analog

◦

digital

◦

io

◦ ... (whatever else)... ◦ ... Then you have the base symbols xschem needs (pins, net labels, ideal spice devices etc): •

.../share/xschem/xschem_library

◦

devices

And then the pdk data (example for sky130A): •

.../share/pdk/sky130A/libs.tech/xschem

◦

sky130_fd_pr

(the silicon device symbols, MOSFETs, diodes, capacitors, resistors, ...) ◦

sky130_stdcells

(the digital standard cell gates) A good setup for this is to add 3 directories (the absolute paths on the host) to `XSCHEM_LIBRARY_PATH`: •

.../project

• .

../share/xschem/xschem_library

•

.../share/pdk/sky130A/libs.tech/xschem

A

schematic.sch

from the

analog

subfolder will have a reference in the schematic as

analog/schematic.sch

A schematic

top.sch

under

project/

will have reference

top.sch

(no subfolders) A

pfet_01v8.sym

will have reference:

sky130_fd_pr/pfet_01v8.sym

A voltage source will have reference:

devices/vsource.sym

. This happens because the XSCHEM_LIBRARY_PATH dirs are defined one level above the directory containing the .sym/.sch files. Xschem adds the last level directory to the reference. If you provide to XSCHEM_LIBRARY_PATH the last level directories then the components will be referenced by their names only.

Thank you Stefan, for the detailed explanation! I read through your tutorial and it seems that I understood that part correctly. Still, I have some comments/questions :)

All professional tools require to setup a library configuration before starting a project, like the cds.lib in Cadence. If you don't do that you won't be able to open / instantiate objects at all (you will not see anything in the library manager).

Exactly, so maybe we should require the same for xschem (you always have to specify your project in

XSCHEM_LIBRARY_PATH

) if that means we gain portability.

If you insert a symbol from a directory that is not known to xschem the full absolute path will be used. This makes the design unportable, but at the very least will make it work on the system you are working on.

True, but I do not think that it's worth it. Most designers never realise that they should have specified their project path in

XSCHEM_LIBRARY_PATH

and that they are using absolute paths.

When an instantiated object is inside a directory known by xschem the path prefix is removed from the symbol reference. This will make the design portable on a different system (after setting up the project xschemrc file on the new system that tells xschem where the design is located).

That is not quite true, maybe I'm doing something wrong. For me, this is only the case if you are on the system on which the schematic was created (the absolute path must be valid). But if you are on a different system, the abolute paths are no longer valid, setting up the xschemrc does not fix the absolute paths then. --- For this reason I think if no

XSCHEM_LIBRARY_PATH

is set up for the project, then instead of writing absolute paths, relative paths should be written, as if the directory of the currently open schematic is appended to

XSCHEM_LIBRARY_PATH

. Doing it this way, it will also "just work" if you haven't set up

XSCHEM_LIBRARY_PATH

for your project, but it is portable and can be referenced by others as a dependency by appending the project to

XSCHEM_LIBRARY_PATH

. Of course, this breaks down when you have something like "testbench -> schematic 1 -> schematic 2", but then you know at least that you need to properly specify the project path in

XSCHEM_LIBRARY_PATH

, as it should have been done in the first place. What do you think of this idea? Thanks!

> For this reason I think if no

XSCHEM_LIBRARY_PATH

is set up for the project, then instead of writing absolute paths, relative paths should be written, as if the directory of the currently open schematic is appended to

XSCHEM_LIBRARY_PATH

. > Doing it this way, it will also "just work" if you haven't set up

XSCHEM_LIBRARY_PATH

for your project, but it is portable and can be referenced by others as a dependency by appending the project to

XSCHEM_LIBRARY_PATH

. I'm very supportive of this idea. I didn't know the

XSCHEM_LIBRARY_PATH

mechanism. Just made a symlink from the PDK supplied xschemrc to

~/.xschemrc

. So, with several people on a design team, we all have to be conscious of relative paths and modify the .sch file text to remove absolute paths if necessary. We exactly encountered the problem of having a lot of absolute paths that made the design reuse very difficult, although we kept the relative directory structures well in the project.

That is not quite true, maybe I'm doing something wrong. For me, this is only the case if you are on the system on which the schematic was created (the absolute path must be valid). But if you are on a different system, the abolute paths are no longer valid, setting up the xschemrc does not fix the absolute paths then.

This happens if the original design already has absolute paths inside it. This is an unportable design no matter what you do afterward. You need to specify the project directory locations in XSCHEM_LIBRARY_PATH, reopen the schematics and save. This time the absolute paths will be removed.

This happens if the original design already has absolute paths inside it. This is an unportable design no matter what you do afterward.

You need to specify the project directory locations in XSCHEM_LIBRARY_PATH, reopen the schematics and save. This time the absolute paths will be removed.

Yes, that's exactly our problem. Users will create schematics that are unportable, because they don't know any better.

So far the best way (in my opinion) to have a portable schematic and not requiring any

xschemrc

editing si to place an

xschemrc

file inside the project root directory, the whole project is located in this directory or in subdirectories below this one, and

xschemrc

has this setting:

append XSCHEM_LIBRARY_PATH :[file dirname [info script]]

This way you can call xschem on the project from any location using:

xschem --rcfile /path/to/project/xschemrc

If the project includes symbols from directories outside the project root directory then these directories should be added to

XSCHEM_LIBRARY_PATH

to have a portable schematic (no absolute path references).

@Stefan Schippers I fully agree! That's exactly the way I've been organising my projects lately. Doing it this way, it's pretty clear that the xschemrc needs to be sourced and the whole project is portable. My only grudge is that it is way too easy to do it the "wrong", non-portable way: New users won't create an xschemrc file as long as they can add their symbols without it. For small projects with only one folder this is always the case. That is why I suggested removing the feature of auto-detecting symbols in the same folder altogether. This way, users will need to set up an xschemrc if they want to include their own symbols in their schematic. Would it be possible to remove this feature? I know, this is a major change, but it will lead to more portability in the long run.

@Stefan Schippers But if you have a xschemrc in the project dir, does the user/global one still get read ?

@Leo Moser @tnt > That is why I suggested removing the feature of auto-detecting symbols in the same folder altogether. The parent schematic folder is no more used (this was a flawed approach, my fault). If a symbol reference is given with no path it will be searched for in all directory items present in XSCHEM_LIBRARY_PATH. If no matching filename is found the reference is taken as is, so it will be searched for in current directory, like in Unix: if you search for a filename with no path it will be searched for in CWD. > But if you have a xschemrc in the project dir, does the user/global one still get read ? In this case the

~/.xschem/xschemrc

is not read, only the system

.../share/xschem/xschemrc

file is read. (by default this file is 100% commented, so it does nothing) > Like I'd like the project xchemrc to ONLY append some items to

XSCHEM_LIBRARY_PATH

for the local project symbols and that's it. > Certainly not change user preferences. And also not set things like PDK device symbols or default xschem library symbols since those will be different > for different users. You can do something like this in your project dir:

source $USER_CONF_DIR/xschemrc

append XSCHEM_LIBRARY_PATH :.....

append XSCHEM_LIBRARY_PATH :.....

@Stefan Schippers Thanks for your reply!

If no matching filename is found the reference is taken as is, so it will be searched for in current directory, like in Unix

And this is exactly what I suggest to remove, because then the design will contain absolute paths and won't be portable. As long as this mechanism exists, users will use it 😅️

Not sure I get a vote, but I'd definitely vote against that 😅 Now I agree when you add a symbol that's under

pwd

, it shouldn't be added as an absolute path, it should be added without that

pwd

prefix.

@tnt I would be fully satisfied with this solution 😃️ In fact, I even proposed something similar here: https://open-source-silicon.slack.com/archives/C017P3RAD42/p1719566263319399?thread_ts=1719160381.935589&cid=C017P3RAD42

@Leo Moser @tnt I finally understood your issue (a bit late, it's hot summer, lol) , and you are right about this request!. I have pushed a commit that removes absolute path from symbols if these are picked from the current working directory, even if the directory is not in the XSCHEM_LIBRRARY_PATH list.

commit 8b5ed3f32ed77b67044b7097376e845be518cdc2 (HEAD -> master, origin/master, origin/HEAD)
Author: stefan schippers <stefan.schippers@gmail.com>
Date:   Fri Jul 19 15:13:38 2024 +0200

    symbols picked up from CWD are saved in parent design without absolute paths even if the CWD is not in XSCHEM_LIBRARY_PATH list of places.

So if you start xschem in a directory

1234/

where

top.sch

includes symbol

xxx.sym

(all these file under

1234/

) the design will not have absolute paths:

v {xschem version=3.4.5 file_version=1.2
}
G {}
K {}
V {}
S {}
E {}
C {xxx.sym} 30 -90 0 0 {name=x1}

Yeah, I suffer with you... it's very hot here too 😅️ Thanks a lot Stefan, that's great 🙌️