After fighting with the place and route part of LibrePDK for over a month now, I finally managed to turn a Qucs schematic like this one into a JSON netlist which then can be fed to the generator, placer and detailed router.

The schematics below which has been drawn in Qucs, can be found in the LibrePDK GitLab repo and shows a driver with an input, output and enable signal.

Converting the netlist into JSON results in the file which can be found in the GitLab repo as well

It’s 8 transistors with M7/M8 being the output stage which have to drive all the current and hence need a muss lower on resistance respectively saturation current.

{
	"name": "driver_circuit",
	"nets": ["VDD","VSS","EN","IN","OUT"],
	"instances": {
		"M1": {
			"type":"pmos",
			"nets": {
				"drain": "3",
				"gate": "EN",
				"source": "4",
				"bulk": "4"
			},
			"R_on": 1000.0,
			"V_DS": 1.2
		},
		"M2": {
			"type":"pmos",
			"nets": {
				"drain": "1",
				"gate": "EN",
				"source": "VDD",
				"bulk": "VDD"
			},
			"R_on": 1000.0,
			"V_DS": 1.2
		},
		"M3": {
			"type":"nmos",
			"nets": {
				"drain": "3",
				"gate": "1",
				"source": "2",
				"bulk": "2"
			},
			"R_on": 1000.0,
			"V_DS": 1.2
		},
		"M4": {
			"type":"nmos",
			"nets": {
				"drain": "2",
				"gate": "IN",
				"source": "VSS",
				"bulk": "VSS"
			},
			"R_on": 1900.0,
			"V_DS": 1.2
		},
		"M5": {
			"type":"pmos",
			"nets": {
				"drain": "4",
				"gate": "IN",
				"source": "VDD",
				"bulk": "VDD"
			},
			"R_on": 1000.0,
			"V_DS": 1.2
		},
		"M6": {
			"type":"nmos",
			"nets": {
				"drain": "1",
				"gate": "EN",
				"source": "VSS",
				"bulk": "VSS"
			},
			"R_on": 1000.0,
			"V_DS": 1.2
		},
		"M7": {
			"type":"pmos",
			"nets": {
				"drain": "OUT",
				"gate": "3",
				"source": "VDD",
				"bulk": "VDD"
			},
			"R_on": 100.0,
			"V_DS": 1.2
		},
		"M8": {
			"type":"nmos",
			"nets": {
				"drain": "OUT",
				"gate": "3",
				"source": "VSS",
				"bulk": "VSS"
			},
			"R_on": 100.0,
			"V_DS": 1.2
		}
	}
}

Lets say we’ve cloned the repo with

git clone https://gitlab.libresilicon.com/generator-tools/librepdk.git
cd librepdk
export LIBREPDK_REPO=`pwd`

Running that JSON file through LibrePDK with the command below leaves us not only with a GDSII but also a SPICE model, Magic VLSI, DEF and LEF file.

export DESIGN_DIR=$LIBREPDK_REPO/tests/driver_circuit
export DESIGN_FILE=$DESIGN_DIR/driver_circuit.json
export ANAROUTE_WORKDIR=$LIBREPDK_REPO/workdir_driver
export ANAROUTE_DEBUG_OUT=$ANAROUTE_WORKDIR/debug/
export ANAROUTE_DEBUG_OUT_PREFIX=$ANAROUTE_DEBUG_OUT/snapshot

rm -rf $ANAROUTE_WORKDIR
mkdir -p $ANAROUTE_DEBUG_OUT
pushd $ANAROUTE_WORKDIR
uv run ../bin/librepdk_generator -d $DESIGN_FILE -t SG13G2 -o out &> out.log
cp $DESIGN_DIR/*.spice .
popd

First lets look at the GDS2 file. We can easily identify M7 and M8 because they’re much larger than the other transistors and have fingers.

Running the test simulations in NG Spice for when the input is enabled and disabled results in the desired behavior.

Output enable is inverted so when it’s 1 (VDD) the output is disabled, when it’s 0 (VSS), the output is enabled.

The below NGSPice simulation shows the result of running `ngspice workdir_driver/test1.spice with the output being disabled.

The below NGSPice simulation shows the result of running `ngspice workdir_driver/test2.spice with the output being enabled.

I just found the command for cleaning up my changes before committing them into my GIT repo

for FILE in `git diff --check | sed '/^[+-]/d' | sed -r 's/:[0-9]+:.*//' | uniq`; do sed -i 's/[[:space:]]*$//' "$FILE"; done

This will clean up all trailing spaces and make the spaces which are highlighted red when running git diff go away

Just wanted to note it down somewhere

Everyone assumes that all the humans we see in the Matrix-fields in the movies would be operating inside the Matrix itself.

But what if some of those humans in those pods grew up teleoperating one of those robot maintenance bugs? Maybe a sentinel?

When you grow up in a certain embodiment, you know nothing else but that embodiment.

Just a thought

OK. The last few weeks I’ve been hacking around on the LibrePDK support for IHP’s SG13G2 node.

After lots of cursing and questioning my life’s choices which led me to the situation I was in, I just finally managed to make the tool dynamically spit out NMOS and PMOS FETs based on the input provided by a JSON file.

For example for an NMOS (tests/single_nmos/single_nmos.json)

{
        "name": "single_nmos",
        "nets": ["drain","gate","source"],
        "instances": {
                "M1": {
                        "type":"nmos",
                        "nets": {
                                "drain": "drain",
                                "gate": "gate",
                                "source": "source",
                                "bulk": "source"
                        },
                        "R_on": 100.0,
                        "V_DS": 1.2
                }
        }
}

Or matching for a PMOS (tests/single_pmos/single_pmos.json)

{
        "name": "single_pmos",
        "nets": ["drain","gate","source"],
        "instances": {
                "M1": {
                        "type":"pmos",
                        "nets": {
                                "drain": "drain",
                                "gate": "gate",
                                "source": "source",
                                "bulk": "source"
                        },
                        "R_on": 100.0,
                        "V_DS": 1.2
                }
        }
}

Running librepdk_generator -t SG13G2 -
d single_pmos.json -o out in the tests/single_pmos, opening the magic file in out results in a transistor with the proper amount of fingers.

ngspice -a test1.spice produces the expected output. With 100 Ohms as target R_DS resistance in saturation, with 1.2V over Drain to Source, 12mA are pretty much what we need.

Same now also works for NMOS

I’m done for today… OMG… that was a hackathon.

You can check out the code on our LibreSilicon GitLab repo here: https://gitlab.libresilicon.com/generator-tools/librepdk

Please comment when you know why the predicted currents still are a bit off.

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.

After more than a week of hacking, and a lot of cursing due to so much having changed in GDS Factory in the last year, I finally have Danube River work properly again.

I even finally got around and updated the wiki page and fixed some open bugs which have been open for a year now.

Besides finally properly stating the expected area size of the capacitors in the PDF also, instead of only in the CSV, I now also have more infos about the pin assignment and how to measure it in the exported PDF.

It’s really annoying that while GDS Factory broke Danube River with all their changes, their basic components still aren’t really very useful when it comes to auto-generating my circuits for the project I had to bring LibrePDK back up to speed for.

I’ve considered using GDSPy only but unfortunately I require some of the facilitation tools they’re providing like a proper snap to grid function and so.

At least I got around updating the wiki page for the Libre Silicon Stack now, and there’s now finally a page for the LibrePDK

Next step now is to get the Standard Cell Generator to spit out standard cells again.

It has been a year since I had last time touching the code of my test wafer generator, and I was hoping that others might keep maintaining my code and keep it up to date, but instead folks just walked away after the first minor dependency changes.

The idea of DanubeRiver is to call all the generator functions from LibrePDK and generating test structures for characterizing any given process.

The original code can be found on my GitLab repository here:
https://gitlab.libresilicon.com/generator-tools/danube-river

The output rendering for GF180MCU, which can be found in tapeout/gf180.gds is shown below.

However, in the meanwhile, lots of code in gdsfactory has changed and after several days of intensive hacking I finally got LibrePDK and Danube River to finally spit out a GDS file at all containing structures which at least kind of resemble the original test structures, as can be shown below, but it’s still kind of out of wack.

I keep on working on Danube River and LibrePDK in the next few days and try bringing it up to speed, fixing all the bugs currently still present.

I’ll be doing so in the refactor branches of LibrePDK and Danube River and will merge them into master after some rebasing.

Those are the repos, I still need to update the documentation on the Wiki page for addressing some changes when it comes to installation of the tool.

• The Danube River repo:
  https://gitlab.libresilicon.com/generator-tools/danube-river/-/tree/refactor?ref_type=heads
• The LibrePDK repo:
  https://gitlab.libresilicon.com/generator-tools/librepdk/-/tree/refactor?ref_type=heads

Problem,s yet to be solved

• Interconnect: The routing has changed
• Area of capacitor electrodes needs a slight rework
• Spacing around the transistor structures is broken

During the past few months I’ve been hacking a lot on the Verilog Schematic support for Qucs, and we’ve gotten very far, with only some minor issues remaining.

While component placement now works properly, with all the orientations, positioning and the visibility of properties being exported into Verilog and read back in again, there’s still issues with the text placement of the properties, and the wire labels are missing.

Above you can see the screenshot of one of the example projects

As comparison above the screenshot of the rendering of the Verilog Schematic dump. Most of the content is now properly dumped, parsed and displayed. The only issues remaining are meta data information, specifically the preamble, text positioning and the labels of the wires.

Charly, my Ender 3 Pro, now has auto bed leveling, and I’ll guide you through the odyssey which was the last two days, where I had to trouble shoot the thing.

It all began with a steal offer on AliExpress, some cheap BLTouch clone, the TZT 3D Touch Sensor from ShengYang: https://www.aliexpress.com/item/1005006042275346.html

I managed to hack together some connection to the probe port on my 4.2.7 board, making the non polarized pin header connectors coming with the sensor stay in the socket using some duct tape for lateral force, or in other words: I made it thicker.

You could of course also go through the trouble of getting the proper Molex connector with polarity knobs and wait another few weeks until it arrives, then crimp it.

But when you’re as dangerously happy as Chris Boden and me (Wanna see something cool?), you just assume that it’s your 3D printer, and with anything else fun in your life, it’s meant for grown ups who can remember how the polarities are meant to be set up.

It’s written on the board after all. Ground goes to ground VCC to VCC and the signal to the servo, that’s the IN.

The only thing those folks in the factory seem to have messed up was the polarity of the wires for the output signal from the Hall sensor, because for some reason I only got it to work after I did switch black and white (white is supposed to be the signal) going to Ground (G) and OUT (where the signal from the Hall sensor is supposed to come from)

You’ll need a Marlin build for your printer, where the BLTouch feature is enabled, then you can try hooking the sensor up and select Deploy in the BLTouch section of the config.

When the little nob of your 3DTouch probe suddenly looks much more happy to see you than before, then you’re in luck, and you at least already got the servo working, the next part is a bit trickier.

Outside of some specific protocol, the probe will have it’s red error LED start blinking like a disco light, but that’s not very informative anyway.

In order to find out, whether the probe properly communicates to the board, that it has been triggered, after it shrank back after you touched it, quicker than me on a cold Swiss winter day (trust me, that place was cold) you’ve got to hook up your little printer to the USB of your computer and run the following G-Code command M119

You can either do that using pronterface or picocom

When after retraction M119 tells you, that the z_probe is in the state of basically every liberal ever since orange man won, then you’re in luck and your probe has been successfully installed.

It’s always a problem when you buy something from China during Chinese new year, because around that time there’s lots of Baijiu involved so a batch can have some polarities messed up and it’s your job to figure that out.

And that’s pretty cool 🙂