search

StefanSchippers / xschem_sky130

XSCHEM symbol libraries for the Google-Skywater 130nm process design kit.
Apache License 2.0
55 stars 11 forks source link

`XSCHEM_LIBRARY_PATH` issue with default symbols #21

Open mole99 opened 6 days ago

mole99 commented 6 days ago

Hi Stefan!

First of all, thank you very much for your work on xschem! I've a question and maybe a request for change:

By default, the xschem library is installed under ${XSCHEM_SHAREDIR/xschem_library/ and contains the devices folder with all of the default symbols.

By default, $XSCHEM_LIBRARY_PATH points to ${XSCHEM_SHAREDIR/xschem_library/devices. If we start xschem and place a vsource.sym, it simply points to vsource.sym.

The xschemrc for sky130 sets the XSCHEM_LIBRARY_PATH to the following:

append XSCHEM_LIBRARY_PATH ${XSCHEM_SHAREDIR}/xschem_library

As you can see, the last part devices is omitted. If we start xschem, load the sky130 xschemrc and place a vsource.sym, it points to devices/vsource.sym.

This is not optimal, because if you open this schematic without the sky130 xschemrc sourced, none of the symbols are displayed correctly. If the sky130 xschemrc would include ${XSCHEM_SHAREDIR}/xschem_library/devices, then you could at least see all of the default symbols. This is really useful when looking at a testbench that doesn't even contain any sky130 symbols (but was created with the sky130 xschemrc sourced).

Therefore my question is, was this change intentional or just an oversight when creating the xschemrc? I know the improvement by correcting it is not huge, but I believe every little bit counts.

The problem with this fix is that it would beak the default symbols for all sky130 designs.

I think there are several ways to tackle this problem:

  1. Just change it and don't care for backwards compatibility. (Bad in my opinion)

  2. Add append XSCHEM_LIBRARY_PATH ${XSCHEM_SHAREDIR}/xschem_library/devices before append XSCHEM_LIBRARY_PATH :${XSCHEM_SHAREDIR}/xschem_library/ so that the correct symbol library is shown first when inserting a symbol. New designs created for sky130 will probably use the correct path. Disadvantage: there are two paths for the default library and it will take time until new designs use the correct path.

  3. Just change it and add some kind of automatic conversion to xschem. This could be some specific hook for sky130 or a change in the logic how symbol paths are saved (maybe always use the shortest path if two entries in XSCHEM_LIBRARY_PATH point to the symbol).

What do you think?

The IHP PDK is still in it's infancy, but its xschemrc has the same issue. So as long as not many designs have been created with the IHP PDK, this could still be changed.

Thanks! Leo

StefanSchippers commented 4 days ago

The standalone xschem setup is to have XSCHEM_LIBRARY_PATH pointing to last level directories contaning .sym files. This is a simple setting for first time users, or users who want to create a simple schematic (may be for a pcb board) Every symbol in the schematic is referenced simply by its name.

Xschem configured for silicon PDKs is a bit more structured. Specifically XSCHEM_LIBRARY_PATH points one level above the last directories containing .sym files. So symbol references in a schematic have the last directory name preceding the symbol name, like devices/vsource.sym.

This different setting is done on purpose, since ASIC designs are far more elaborate and complex than simple pcb schematics. This allows you to have more inv.sym symbols in different directories and use one or the other (but not both!) in a design. For example you might want multiple standard cell libraries with different symbols (but same naming). Using the last directory name before the cell name lets you know where the cell came from.

If you load a standalone xschem schematic from a sky130 xschem session (or any other pdk) you will see missing symbols, since vsource.sym is not found (should be devices/vsource.sym).

You can give this command to the xschem console:

fix_symbols 1

this means add the last one directory component to symbol references.

If you load a sky130 (or any other pdk) schematic from a standalone xschem session you should give: fix_symbols 0 to remove the last directory component from symbol references (so you will see at least the xschem base symbols like ipin, opin and so on).

StefanSchippers commented 4 days ago

You can also add upper and last directories to XSCHEM_LIBRARY_PATH:

append XSCHEM_LIBRARY_PATH :${XSCHEM_SHAREDIR}/xschem_library:${XSCHEM_SHAREDIR}/xschem_library/devices

Note that the order is important. In the above setting if you place a vsource.sym its reference will be devices/vsource.sym, because the 1-level up directory is parsed first, and this path is removed from the absolute path of vsource.sym, (they match) leaving devices/vsource.sym in the schematic.

mole99 commented 3 days ago

Thanks for the explanation Stefan!

My ${XSCHEM_SHAREDIR}/xschem_library only contains the devices folder. And the symbols for the sky130 PDK are added to XSCHEM_LIBRARY_PATH independently. So I don't think it is really necessary to point to ${XSCHEM_SHAREDIR}/xschem_library. Therefore, it would still be possible to use ${XSCHEM_SHAREDIR}/xschem_library/devices for the standard symbols, right?

I think it would be nice if PCB and ASIC designs were compatible in terms of standard symbols, that would make it easier to share testbenches for example (without relying on fix_symbols). If there was another folder in ${XSCHEM_SHAREDIR}/xschem_library, it could be added to the XSCHEM_LIBRARY_PATH in the PDK's xschemrc, but that doesn't seem to be the case with any of the open PDKs anyway.

Regarding upper and last directories, that's what I suggested in my second solution: list ${XSCHEM_SHAREDIR}/xschem_library/devices first, so that new symbols are placed with the same path as in PCB designs.

I know that changing established things are not easy. But in this case I think it would be worth it, even if only for a small gain. Would you be open to a PR?