During the past couple of weeks, I’ve been fighting not only with a constantly changing API of GDS Factory, and its decrease in performance due to it now spinning up a frigging KLayout instance in the backend, because who needs simple geometry libs when you can load an entire Qt toolchain into the RAM in the background, right?

After lots of cursing and questioning my life choices which led to me being confronted with such a mess, I finally managed the pipeline here, spit out GDS2 files with correctly rendered meander resistors, strip resistors, capacitors and single gate transistors, finally passing the design rule checks for the various processes once again, and actually looking OK: https://gitlab.libresilicon.com/generator-tools/danube-river/-/pipelines/155

Now LibrePDK properly takes the enclosure design rules into account again, when it comes to active areas within deep oxide regions, respectively the wells.

The technology files can be found in our repository here, adding gate extension was needed for LibrePDK to generate FETs uniformly without DRC violations: https://gitlab.libresilicon.com/generator-tools/librepdk/-/tree/master/LibrePDK/technologies?ref_type=heads

In addition we now also take into consideration the design rule for the gate length extension over the active area, which for SG13G2 is a hard rule.

The resistors and via strip taps were out of whack after the very last GDS Factory changes. Keeping up with their API changes is like a game of whack a mole.

You can download the most recent Danube River GDS2 files from the pipeline artifacts.

After that you can run klayout from within our Docker image and open the GDS2 file (this command line is meant for Linux)

docker pull leviathanch/libresilicon-tools
docker run -it -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -v `pwd`:/work leviathanch/libresilicon-tools -l -c ". /root/env/bin/activate && /usr/bin/klayout"

After that you can run set the technology of the wafer in File > Layout Settings and run DRC checks and so.

We already have integrated the newly supported SG13G2 node by IHP into our Standard Cell Generator (https://gitlab.libresilicon.com/generator-tools/standard-cell-generator/-/pipelines/152) but are still encountering some short circuit issues with the antenna diodes, when trying to characterize the cells being generated.

This will require some more tinkering, probably even within the LCLayout code itself.

At this point I’m seriously starting to consider using a genetic algorithm with Gemma 3 270M as code generator, because what I’m doing here manually is basically would a genetic algorithm would be doing automatically and much faster: Generalizing code out of design rules in order to produce device structures which work for any given DRC set.

That’s exactly for what Machine Learning has been invented.