LibreSilicon - User contributions [en]

Basic Tooling

2026-05-30T09:34:02Z

Leviathan: /* Rapid Thermal Processing (RTP) */

In order to not have to rely on foundries anymore and to truly democratize semiconductor manufacturing equipment, and eliminating the risk of supply chain attacks by eliminating the supply chain all together, a minimum viable lab setup is needed for making semiconductor structures in your shed.

In order to manufacture transistors, you need the capability of performing the below basic physical operations on your sample

== Lower Particle Count in the Air ==

== Heat Treatment ==
Heat treatment is critical for several steps like dopant diffusion, in order to control the depth of wells, as well as for depositing materials in a CVD process, like polysilicon and low temperature oxide (LTO) or for forming silicide/salicide thin films reducing the sheet resistance of polysilicon and junctions.

=== Rapid Thermal Processing (RTP) ===
This is used for instance for initiating metallurgical reactions between a deposited titanium thin film and the silicon substrate in order to achieve titanium silicide which reduces the resistance of the polisilicon as I do in step 13 of [[LibreSilicon 1µm CMOS Process Flow (HKUST NFF)|LS1U]] ([[LibreSilicon 1µm CMOS Process Flow (HKUST NFF)#Step 13: Silicidation]])

=== Tube Furnace (and CVD) ===

== Photo Lithography ==

== Etching ==

Basic Tooling

2026-05-30T09:32:37Z

Leviathan: /* Heat Treatment */

In order to not have to rely on foundries anymore and to truly democratize semiconductor manufacturing equipment, and eliminating the risk of supply chain attacks by eliminating the supply chain all together, a minimum viable lab setup is needed for making semiconductor structures in your shed.

In order to manufacture transistors, you need the capability of performing the below basic physical operations on your sample

== Lower Particle Count in the Air ==

== Heat Treatment ==
Heat treatment is critical for several steps like dopant diffusion, in order to control the depth of wells, as well as for depositing materials in a CVD process, like polysilicon and low temperature oxide (LTO) or for forming silicide/salicide thin films reducing the sheet resistance of polysilicon and junctions.

=== Rapid Thermal Processing (RTP) ===
This is used for instance for initiating metallurgical reactions between a deposited titanium thin film and the silicon substrate in order to achieve titanium silicide which reduces the resistance of the polisilicon as I do in [[LibreSilicon 1µm CMOS Process Flow (HKUST NFF)|L1SU]]

=== Tube Furnace (and CVD) ===

== Photo Lithography ==

== Etching ==

ESD Verification

2026-05-29T13:37:54Z

Leviathan: /* HBS Reverse */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path

This is just the driver stage test. The input buffer will be having additional tests

== ESD Tests ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here are the [https://gitlab.libresilicon.com/generator-tools/librepdk/-/tree/master/tests/esd?ref_type=heads SPICE decks]

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]Running the detailed tests for IHP with<syntaxhighlight lang="bash">
./tests/run_single_test.sh SG13G2:1.2 padcell
</syntaxhighlight>yields<syntaxhighlight lang="bash">
Peak PAD voltage: 2.467 V
Peak current: 1.330122 A
Peak resistor power: 2.654 kW
Final dissipated energy: 168.225485 µJ
HBM plots written to /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/plots/hbm_pd_forward
Waveform data: /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/hbm_waveforms_hbm_pd_forward.dat
Peak PAD voltage: 2.310 V
Peak current: 1.330248 A
Peak resistor power: 2.654 kW
Final dissipated energy: 168.240327 µJ
HBM plots written to /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/plots/hbm_ns_forward
Waveform data: /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/hbm_waveforms_hbm_ns_forward.dat
Peak PAD voltage: -0.029 V
Peak current: 1.323457 A
Peak resistor power: 2.627 kW
Final dissipated energy: 166.729178 µJ
HBM plots written to /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/plots/hbm_nd_reverse
Waveform data: /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/hbm_waveforms_hbm_nd_reverse.dat
Peak PAD voltage: -0.029 V
Peak current: 1.323461 A
Peak resistor power: 2.627 kW
Final dissipated energy: 166.782671 µJ

</syntaxhighlight>

=== HBS Forward ===
Simulating forward ESD discharge basically simulates the path drawn below
[[File:ESD forward IHP SG13G2 1V2.png|thumb|277x277px|none]]The forward discharge results in a cummulative energy of 100-150 micro Jules.
[[File:Forward Hbm esd dissipation.png|none|thumb]]
The things won't even get warm

=== HBS Reverse ===
For the reverse test, it's backwards...
[[File:ESD backwards IHP SG13G2-@ 1v2.png|none|thumb|341x341px]]The same graph results from simulating the reverse ESD, because that's how the diodes have been dimensioned
[[File:Reverse Hbm esd dissipation.png|none|thumb]]
Not matter which direction, things won't even get warm

== The IHP SG13G2 case ==
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math display="inline">L_{gate} = I_{target}/I_{sat}</math> with <math>\left [ I_{sat} \right ] = \frac{mA}{uA} </math>

That however has to be combined with the thermal budget, which gives a minimum area for the energy to be dissipated on.

In the case of the 1.2V transistors the saturation current of the channel isn't high enough anyway for violating the minimum area requirement because it doesn't have additional doping like the IHP transistor lifted to 3.3V by additional HV doping.

This doping improves the conductivity of the channel, so the gates had to be scaled up in order to cover enough space for dissipating the energy they conduct.

File:Forward Hbm esd dissipation.png

2026-05-29T13:34:59Z

Leviathan:

Forward Hbm esd dissipation

File:Reverse Hbm esd dissipation.png

2026-05-29T13:34:23Z

Leviathan:

Reverse Hbm esd dissipation

ESD Verification

2026-05-29T13:33:28Z

Leviathan: /* ESD Tests */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path

This is just the driver stage test. The input buffer will be having additional tests

== ESD Tests ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]Running the detailed tests for IHP with<syntaxhighlight lang="bash">
./tests/run_single_test.sh SG13G2:1.2 padcell
</syntaxhighlight>yields<syntaxhighlight lang="bash">
Peak PAD voltage: 2.467 V
Peak current: 1.330122 A
Peak resistor power: 2.654 kW
Final dissipated energy: 168.225485 µJ
HBM plots written to /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/plots/hbm_pd_forward
Waveform data: /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/hbm_waveforms_hbm_pd_forward.dat
Peak PAD voltage: 2.310 V
Peak current: 1.330248 A
Peak resistor power: 2.654 kW
Final dissipated energy: 168.240327 µJ
HBM plots written to /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/plots/hbm_ns_forward
Waveform data: /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/hbm_waveforms_hbm_ns_forward.dat
Peak PAD voltage: -0.029 V
Peak current: 1.323457 A
Peak resistor power: 2.627 kW
Final dissipated energy: 166.729178 µJ
HBM plots written to /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/plots/hbm_nd_reverse
Waveform data: /run/media/leviathan/dde9e2a1-4a6e-4d1b-afec-7c557d080ef8/LibrePDK/librepdk/generated_output/SG13G2/1.2V/padcell/out/io_cell_20mA_1p2V/hbm_waveforms_hbm_nd_reverse.dat
Peak PAD voltage: -0.029 V
Peak current: 1.323461 A
Peak resistor power: 2.627 kW
Final dissipated energy: 166.782671 µJ

</syntaxhighlight>

=== HBS Forward ===
Simulating forward ESD discharge basically simulates the path drawn below
[[File:ESD forward IHP SG13G2 1V2.png|thumb|277x277px|none]]

=== HBS Reverse ===
For the reverse test, it's backwards...
[[File:ESD backwards IHP SG13G2-@ 1v2.png|none|thumb|341x341px]]

== The IHP SG13G2 case ==
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math display="inline">L_{gate} = I_{target}/I_{sat}</math> with <math>\left [ I_{sat} \right ] = \frac{mA}{uA} </math>

That however has to be combined with the thermal budget, which gives a minimum area for the energy to be dissipated on.

In the case of the 1.2V transistors the saturation current of the channel isn't high enough anyway for violating the minimum area requirement because it doesn't have additional doping like the IHP transistor lifted to 3.3V by additional HV doping.

This doping improves the conductivity of the channel, so the gates had to be scaled up in order to cover enough space for dissipating the energy they conduct.

File:ESD backwards IHP SG13G2-@ 1v2.png

2026-05-29T13:32:12Z

Leviathan:

ESD backwards IHP SG13G2-@ 1v2

File:ESD forward IHP SG13G2 1V2.png

2026-05-29T13:28:55Z

Leviathan:

ESD forward IHP SG13G2 1V2

ESD Verification

2026-05-29T13:01:45Z

Leviathan: /* ESD path: Bonding Path to VSS ESD and VDD ESD */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path

This is just the driver stage test. The input buffer will be having additional tests

== ESD Tests ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.

Here are some simulation values extracted from ngspice

* '''Peak PAD voltage:''' 1910.869 V
* '''Peak current:''' 1.314834 A
* '''Peak resistor power:''' 2.593 kW That's over a 1.5 kΩ sense resistor, the power dissipated over the actual diodes is is only 3.144856 µJ
* '''Final dissipated energy:''' 3.144856 µJ

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the '''micro''' Jules range (3.144856 µJ)

That's nothing
[[File:HBM ESD dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

You can see how the voltage on the bonding pad drops while the current and power stays very small[[File:Hbm esd waveforms.png|none|thumb|335x335px]]
2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.

Just as dimensionsed, the ESD protection does its job

Only in the beginning there's a huge peak in current 1.314834 A, but since it's only a burst of a few nano seconds the ESD diodes handle it with ease

== The IHP SG13G2 case ==
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math display="inline">L_{gate} = I_{target}/I_{sat}</math> with <math>\left [ I_{sat} \right ] = \frac{mA}{uA} </math>

That however has to be combined with the thermal budget, which gives a minimum area for the energy to be dissipated on.

In the case of the 1.2V transistors the saturation current of the channel isn't high enough anyway for violating the minimum area requirement because it doesn't have additional doping like the IHP transistor lifted to 3.3V by additional HV doping.

This doping improves the conductivity of the channel, so the gates had to be scaled up in order to cover enough space for dissipating the energy they conduct.

LibrePDK

2026-05-29T11:31:28Z

Leviathan: /* Pad Cells */

The LibrePDK is the library driving [[Danube River]] and the [[Pad Cell Generator]]
[[File:LibrePDK.png|none|thumb|695x695px|ALibrePDK screen shot]]
It is responsible for generating discrete parts with specific parameters for a specific process.

The properties of the parts can be optimized by utilizing the calibration values extracted from the measurements of taped out Danube River test wafers.

== Adding a new technology ==
Technologies currently supported can be found in the technologies subfolder.

https://gitlab.libresilicon.com/generator-tools/librepdk/-/tree/master/LibrePDK/technologies?ref_type=heads

New technologies can be added by modifying '''scripts/update_technologies.sh''' and adding a tech.python script to the technologies folder.

After that, LibrePDK should be capable of auto discovering the new process after running the update script.

== Installation ==
First please clone the repo

pip install [https://gitlab.libresilicon.com/generator-tools/librepdk.git https+git://gitlab.libresilicon.com/generator-tools/librepdk.git]

Don't forget to make sure that all the submodules and their submodules are cloned

git submodule update --init --recursive

For placement of discrete componentes used in more complex components like Driver Circuits, OpAmps, etc. IdeaPlaceExPy is being used.

IdeaPlaceExPy requires the Python system headers to be installed and the virtual env has to match the Python version with which it was compiled.

=== Using LibrePDK in a Virtual Environment ===
It is recommended to use LibrePDK in a Python virtual environment to avoid dependency conflicts with
system-wide Python packages.

After you've installed all the below dependencies the recommended way of installing the remaining dependencies is to run<syntaxhighlight lang="bash">
uv sync --no-cache
</syntaxhighlight>

=== OpenVAF models ===

IHP's SG13G2 technology node uses OpenVAF models for the ngspice simulation tool.

The following script will make sure that rust and the OpenVAF tool are present and then
compiles the models into the osdi format and places them into the technology directory
ready to be used by LibrePDK.

Simply run the following script and confirm the installation by checking for the LibrePDK/technologies/spice/SG13G2/devices/*/*.osdi files.

./scripts/update_ngspice_extensions.sh

=== LP solver ===

Google now officially runs the project and you can get the most recent version from GitHub

Install is by cloning and building it<syntaxhighlight lang="bash">
git clone https://github.com/lp-solve/lp_solve
pushd lp_solve/lpsolve55
rm -rf bin/ux64
sh ccc
popd
</syntaxhighlight> Then you can copy the shared object file in solve/lpsolve55/bin/ux64 into your /usr/lib64 and copy the headers with<syntaxhighlight lang="bash">
mkdir /usr/include/lpsolve
cp lp_solve/*.h /usr/include/lpsolve/
</syntaxhighlight>OR, you can install the system package and devel package with your package manager

=== Lemon ===

That library has been developed by a Hungarian university which doesn't maintain their Mercurial setup. Best approach is to use the version you find in your distribution
=== Limbo ===

The official version of Limbo has been a total mess when it comes to building libs and linking them. I had to make some severe modifications which makes CMake properly build shared object files and detects the system wide installation of the dependencies
using proper CMake detection functions

Just run<syntaxhighlight lang="bash">
git clone https://gitlab.libresilicon.com/leviathan/limbo.git
mkdir Limbo/build
pushd Limbo/build
cmake ..
make
make install
popd
</syntaxhighlight>

= Components =
LibrePDK provides generators for the basic components usually found within a VLSI/ULSI design, such as resistors, capacitors, diodes and transistors.

== Capacitors ==
LibrePDK can calculate the specific geometry based on the device rules and available parameters for generating any desired target capacitance value. Below a 50pF capacitor can be seen. You will notice the enormous dimensions of the structure.
[[File:50pF MiMCap (GF180A, 3.3V).png|none|thumb|300x300px]]
Usually we deal with femto Farad in VLSI design so you should never be in a situation where you have large capacitors on your chip.

LibrePDK still can generate you a device, you just won't be happy about it.

== Resistors ==
There's two types of resistor structures available: Meander and strip resistors

LibrePDK automatically adds a guard ring around any resistor which should be on a well

'''The meander here is 200 Ohms for GF180A@3.3V'''[[File:LibrePDK Meander Example.png|none|thumb|300x300px]]'''The meander here is 500 Ohms for GF180A@3.3V'''[[File:Strip Resistor Example.png|none|thumb|300x300px]]

== Diodes ==
[[File:Diode Example.png|none|thumb|300x300px|Example of a diode]]
While normal fingered diodes now have been implemented Schottky diodes still are work in progress.

== Schottky diodes ==
Those are not yet implemented

== Transistors ==
In order to make sure that our transistors don't go up in flame, we have to take the hot carrier migration and thermal budget into consideration when we decide what transistor to use and whether it should have only one gate or should be fingered.

LibrePDK takes care of this and chooses the right transistor with the right amount of fingers for you based on the target operating voltage and current you plan to pump through it, you provide.

Additionally, you can also overwrite the thermal budget which usually is assumed to be for an internal circuit which isn't bonded directly to the outside.

When LibrePDK calculates that electron migration and thermal budget constraints don't allow for a single gate transistor it will dynamically create a fingered structure, either with bulk and source connected or not with the proper guard ring.
[[File:Fingered Transistor.png|none|thumb|300x300px|Example of a fingered transistor]]
Libre PDK may also decide to just generate a single gate transistor in cases where there's very little power involved
[[File:Single Gate Example.png|none|thumb|300x300px|Example of a single gate transistor]]

== Pad Cells ==
Last but not least: It contains the [[Pad Cell Generator]] which produces beauties like this
[[File:30mA SG13G2@3V3 v2.png|none|thumb|356x356px]]

Pad Frame Generator

2026-05-29T10:25:43Z

Leviathan:

[[File:Pad Frame v2 Example SG13G2@1V2.png|thumb]]
The Pad Frame Generator is part of the [[LibrePDK]]
It's job is to assemble a ready to use pad frame harness, with ESD protection and power rail wire width properly adjusted for accommodating the intended current driving capacity as well as the intended voltage levels to be used.

ESD Verification

2026-05-29T10:20:20Z

Leviathan:

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path
* a bias on <code>NOT_EN</code> so the driver remains disabled during the pulse

This is just the driver stage test. The input buffer will be having additional tests

== ESD path: Bonding Path to VSS ESD and VDD ESD ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.

Here are some simulation values extracted from ngspice

* '''Peak PAD voltage:''' 1910.869 V
* '''Peak current:''' 1.314834 A
* '''Peak resistor power:''' 2.593 kW That's over a 1.5 kΩ sense resistor, the power dissipated over the actual diodes is is only 3.144856 µJ
* '''Final dissipated energy:''' 3.144856 µJ

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the '''micro''' Jules range (3.144856 µJ)

That's nothing
[[File:HBM ESD dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

You can see how the voltage on the bonding pad drops while the current and power stays very small[[File:Hbm esd waveforms.png|none|thumb|335x335px]]
2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.

Just as dimensionsed, the ESD protection does its job

Only in the beginning there's a huge peak in current 1.314834 A, but since it's only a burst of a few nano seconds the ESD diodes handle it with ease

== ESD path from bonding to internal logic ==
The second test is the simulation of whether we have a calculated break through between the external bonding pad and the internal GPIO logic going into the digital core logic (center of the die)
[[File:ESD path from outside to internal.png|none|thumb]]
As you can see (hopefully) in the drawing I quickly made here in my KolourPaint, we simulate the ESD breakthrough path, which is expected to be negligible due to our backwards calculation, from the outside pad based on the Human Body Model through the pad cell, through the digital logic to ground.

=== The IHP SG13G2 case ===
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math display="inline">L_{gate} = I_{target}/I_{sat}</math> with <math>\left [ I_{sat} \right ] = \frac{mA}{uA} </math>

That however has to be combined with the thermal budget, which gives a minimum area for the energy to be dissipated on.

In the case of the 1.2V transistors the saturation current of the channel isn't high enough anyway for violating the minimum area requirement because it doesn't have additional doping like the IHP transistor lifted to 3.3V by additional HV doping.

This doping improves the conductivity of the channel, so the gates had to be scaled up in order to cover enough space for dissipating the energy they conduct.

ESD Verification

2026-05-29T09:56:25Z

Leviathan: /* The IHP SG13G2 case */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh visual
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path
* a bias on <code>NOT_EN</code> so the driver remains disabled during the pulse

This is just the driver stage test. The input buffer will be having additional tests

== ESD path: Bonding Path to VSS ESD and VDD ESD ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.

Here are some simulation values extracted from ngspice

* '''Peak PAD voltage:''' 1910.869 V
* '''Peak current:''' 1.314834 A
* '''Peak resistor power:''' 2.593 kW That's over a 1.5 kΩ sense resistor, the power dissipated over the actual diodes is is only 3.144856 µJ
* '''Final dissipated energy:''' 3.144856 µJ

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the '''micro''' Jules range (3.144856 µJ)

That's nothing
[[File:HBM ESD dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

You can see how the voltage on the bonding pad drops while the current and power stays very small[[File:Hbm esd waveforms.png|none|thumb|335x335px]]
2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.

Just as dimensionsed, the ESD protection does its job

Only in the beginning there's a huge peak in current 1.314834 A, but since it's only a burst of a few nano seconds the ESD diodes handle it with ease

== ESD path from bonding to internal logic ==
The second test is the simulation of whether we have a calculated break through between the external bonding pad and the internal GPIO logic going into the digital core logic (center of the die)
[[File:ESD path from outside to internal.png|none|thumb]]
As you can see (hopefully) in the drawing I quickly made here in my KolourPaint, we simulate the ESD breakthrough path, which is expected to be negligible due to our backwards calculation, from the outside pad based on the Human Body Model through the pad cell, through the digital logic to ground.

=== The IHP SG13G2 case ===
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math display="inline">L_{gate} = I_{target}/I_{sat}</math> with <math>\left [ I_{sat} \right ] = \frac{mA}{uA} </math>

That however has to be combined with the thermal budget, which gives a minimum area for the energy to be dissipated on.

In the case of the 1.2V transistors the saturation current of the channel isn't high enough anyway for violating the minimum area requirement because it doesn't have additional doping like the IHP transistor lifted to 3.3V by additional HV doping.

This doping improves the conductivity of the channel, so the gates had to be scaled up in order to cover enough space for dissipating the energy they conduct.

ESD Verification

2026-05-29T09:53:35Z

Leviathan: /* The IHP SG13G2 case */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh visual
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path
* a bias on <code>NOT_EN</code> so the driver remains disabled during the pulse

This is just the driver stage test. The input buffer will be having additional tests

== ESD path: Bonding Path to VSS ESD and VDD ESD ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.

Here are some simulation values extracted from ngspice

* '''Peak PAD voltage:''' 1910.869 V
* '''Peak current:''' 1.314834 A
* '''Peak resistor power:''' 2.593 kW That's over a 1.5 kΩ sense resistor, the power dissipated over the actual diodes is is only 3.144856 µJ
* '''Final dissipated energy:''' 3.144856 µJ

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the '''micro''' Jules range (3.144856 µJ)

That's nothing
[[File:HBM ESD dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

You can see how the voltage on the bonding pad drops while the current and power stays very small[[File:Hbm esd waveforms.png|none|thumb|335x335px]]
2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.

Just as dimensionsed, the ESD protection does its job

Only in the beginning there's a huge peak in current 1.314834 A, but since it's only a burst of a few nano seconds the ESD diodes handle it with ease

== ESD path from bonding to internal logic ==
The second test is the simulation of whether we have a calculated break through between the external bonding pad and the internal GPIO logic going into the digital core logic (center of the die)
[[File:ESD path from outside to internal.png|none|thumb]]
As you can see (hopefully) in the drawing I quickly made here in my KolourPaint, we simulate the ESD breakthrough path, which is expected to be negligible due to our backwards calculation, from the outside pad based on the Human Body Model through the pad cell, through the digital logic to ground.

=== The IHP SG13G2 case ===
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math display="inline">L_{gate} = I_{target}/I_{sat}</math> with <math>\left [ I_{sat} \right ] = \frac{mA}{uA} </math>

ESD Verification

2026-05-29T09:51:47Z

Leviathan: /* The IHP SG13G2 case */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh visual
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path
* a bias on <code>NOT_EN</code> so the driver remains disabled during the pulse

This is just the driver stage test. The input buffer will be having additional tests

== ESD path: Bonding Path to VSS ESD and VDD ESD ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.

Here are some simulation values extracted from ngspice

* '''Peak PAD voltage:''' 1910.869 V
* '''Peak current:''' 1.314834 A
* '''Peak resistor power:''' 2.593 kW That's over a 1.5 kΩ sense resistor, the power dissipated over the actual diodes is is only 3.144856 µJ
* '''Final dissipated energy:''' 3.144856 µJ

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the '''micro''' Jules range (3.144856 µJ)

That's nothing
[[File:HBM ESD dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

You can see how the voltage on the bonding pad drops while the current and power stays very small[[File:Hbm esd waveforms.png|none|thumb|335x335px]]
2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.

Just as dimensionsed, the ESD protection does its job

Only in the beginning there's a huge peak in current 1.314834 A, but since it's only a burst of a few nano seconds the ESD diodes handle it with ease

== ESD path from bonding to internal logic ==
The second test is the simulation of whether we have a calculated break through between the external bonding pad and the internal GPIO logic going into the digital core logic (center of the die)
[[File:ESD path from outside to internal.png|none|thumb]]
As you can see (hopefully) in the drawing I quickly made here in my KolourPaint, we simulate the ESD breakthrough path, which is expected to be negligible due to our backwards calculation, from the outside pad based on the Human Body Model through the pad cell, through the digital logic to ground.

=== The IHP SG13G2 case ===
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math display="inline">L_{gate} = I_{target}/I_{sat}</math>

ESD Verification

2026-05-29T09:51:15Z

Leviathan: /* The IHP SG13G2 @ 1.2V case */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh visual
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path
* a bias on <code>NOT_EN</code> so the driver remains disabled during the pulse

This is just the driver stage test. The input buffer will be having additional tests

== ESD path: Bonding Path to VSS ESD and VDD ESD ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.

Here are some simulation values extracted from ngspice

* '''Peak PAD voltage:''' 1910.869 V
* '''Peak current:''' 1.314834 A
* '''Peak resistor power:''' 2.593 kW That's over a 1.5 kΩ sense resistor, the power dissipated over the actual diodes is is only 3.144856 µJ
* '''Final dissipated energy:''' 3.144856 µJ

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the '''micro''' Jules range (3.144856 µJ)

That's nothing
[[File:HBM ESD dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

You can see how the voltage on the bonding pad drops while the current and power stays very small[[File:Hbm esd waveforms.png|none|thumb|335x335px]]
2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.

Just as dimensionsed, the ESD protection does its job

Only in the beginning there's a huge peak in current 1.314834 A, but since it's only a burst of a few nano seconds the ESD diodes handle it with ease

== ESD path from bonding to internal logic ==
The second test is the simulation of whether we have a calculated break through between the external bonding pad and the internal GPIO logic going into the digital core logic (center of the die)
[[File:ESD path from outside to internal.png|none|thumb]]
As you can see (hopefully) in the drawing I quickly made here in my KolourPaint, we simulate the ESD breakthrough path, which is expected to be negligible due to our backwards calculation, from the outside pad based on the Human Body Model through the pad cell, through the digital logic to ground.

=== The IHP SG13G2 case ===
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

It's a balance between electron mobility and thermal budget... took a while to code that. It's really complicated physics, but it's now all done in Python so you won't have to solve those partial differential equations yourself.
[[File:30mA SG13G2@1V2 v2.png|left|thumb|419x419px|'''30mA SG13G2@1V2''' ]]
[[File:30mA SG13G2@3V3 v2.png|thumb|335x335px|30mA SG13G2@3V3]]
Lets look at those two pad cells here. One is dimensionsed for 30mA at 1.2V and the other at 3.3V

One would assume that the 3.3V transistors would be larger.

However.

The width of a channel (length of the gate) is being determined by <math>L_{gate} = I_{target}/I_{sat}</math>

File:30mA SG13G2@3V3 v2.png

2026-05-29T09:47:22Z

Leviathan:

30mA SG13G2@3V3 v2

Pad Cell Generator

2026-05-29T09:41:07Z

Leviathan: /* How to use */

[[File:30mA SG13G2@1V2 v2.png|thumb|'''Example 30mA SG13G2@1V2 (version 2)''']]
The LibreSilicon Pad Cell Generator is an extension of the [[LibrePDK]] which besides the driver logic also dynamically generates the mixed signal parts needed for over current and static discharge protection and providing the currents needed for doing useful things with an actual physical chip, like driving an LED or a small motor.

== Existing Groundwork ==
The generator is based on the work of several folks who started developing puzzle pieces for it before Google ran out of funding internally and the project had to go on hiatus

Here's some works our generator will be based on:

* Gowthami Nalla did some work with the logic circuit and the driver but it's specific to XFAB only; https://github.com/gowthaminalla/bidirectional-buffer/
* Very rudimentary development has been done on the ESD front: https://github.com/AishikAnalogCKTdesign/ESD
* Philip's pad frame generator (Perl): https://www2.futureware.at/~philipp/vsd2018/
* Philip's very basic Perl based pad cell generator (https://pdk.libresilicon.com/PadCellGenerator.zip)
** Perl based
** Not portable
** Needs smarter ESD protection
** Needs smarter IO config
** Doesn't have termination resistor configuration (needed for DDR3/DDR4 PHYs)
** Not even yet half finished

== Configuration ==
The Pad Cell Generator has the task of generating a [[Pad Cell]] for generating a pad frame for taping out a circuit with any given set of design rules for any given process.

Just as with the Standard Cell Generator, you need to provide the Pad Cell Generator the appropriate configuration telling it about all the design constraints and mixed signal characteristics of the process you are targeting.

Please look at our reference technology folders like the design rule constraints and parameters, for which we introduced a somewhat standardized format with the advent of our [[Danube River]] test wafer generator.

== How to use ==
The Pad Cell Generator is part of [[LibrePDK]]

Running the following script within the LibrePDK folder, after following the installation instructions...<syntaxhighlight lang="bash">
uv run librepdk_padframe_generator -i tests/padframes/padframe_sg13g2_1v2.json
</syntaxhighlight>You should end up with a set of pad cells dimensioned for 20mA, 30mA, 40mA and 60mA driver strength, plus a demo assembly which looks somewhat like this (still work in progress)
[[File:Pad Frame v2 Example SG13G2@1V2.png|none|thumb]]

== Electrical Discharge Protection ==
Since we're calculating backwards from the target values we wanna achieve based on values extracted from ngspice simulations using the SPICE models, it is no wonder that the final ngspice simulation turns out to check out fine for all the pad cells we generate.

The whole math is being documented in [[Physics-Based Wire Sizing for I/O Pad Cells]]

Subsequently the ngspice analysis and verification of the reverse solved hardware design can be found in [[ESD Verification]]

Pad Cell Generator

2026-05-29T09:39:11Z

Leviathan:

[[File:30mA SG13G2@1V2 v2.png|thumb|'''Example 30mA SG13G2@1V2 (version 2)''']]
The LibreSilicon Pad Cell Generator is an extension of the [[LibrePDK]] which besides the driver logic also dynamically generates the mixed signal parts needed for over current and static discharge protection and providing the currents needed for doing useful things with an actual physical chip, like driving an LED or a small motor.

== Existing Groundwork ==
The generator is based on the work of several folks who started developing puzzle pieces for it before Google ran out of funding internally and the project had to go on hiatus

Here's some works our generator will be based on:

* Gowthami Nalla did some work with the logic circuit and the driver but it's specific to XFAB only; https://github.com/gowthaminalla/bidirectional-buffer/
* Very rudimentary development has been done on the ESD front: https://github.com/AishikAnalogCKTdesign/ESD
* Philip's pad frame generator (Perl): https://www2.futureware.at/~philipp/vsd2018/
* Philip's very basic Perl based pad cell generator (https://pdk.libresilicon.com/PadCellGenerator.zip)
** Perl based
** Not portable
** Needs smarter ESD protection
** Needs smarter IO config
** Doesn't have termination resistor configuration (needed for DDR3/DDR4 PHYs)
** Not even yet half finished

== Configuration ==
The Pad Cell Generator has the task of generating a [[Pad Cell]] for generating a pad frame for taping out a circuit with any given set of design rules for any given process.

Just as with the Standard Cell Generator, you need to provide the Pad Cell Generator the appropriate configuration telling it about all the design constraints and mixed signal characteristics of the process you are targeting.

Please look at our reference technology folders like the design rule constraints and parameters, for which we introduced a somewhat standardized format with the advent of our [[Danube River]] test wafer generator.

== How to use ==
The Pad Cell Generator is part of [[LibrePDK]]

Running the following script within the LibrePDK folder, after following the installation instructions...<syntaxhighlight lang="bash">
#!/bin/bash
TECH=SG13G2
VOLTAGE=1.2
mkdir -p ihp_pads
pushd ihp_pads
uv run librepdk_padcell_generator -t $TECH -v $VOLTAGE -i 20,30,40,60
popd
</syntaxhighlight>You should end up with a set of pad cells dimensioned for 20mA, 30mA, 40mA and 60mA driver strength, plus a demo assembly which looks somewhat like this (still work in progress)
[[File:Preliminary First Pad Frame generated.png|none|thumb]]

== Electrical Discharge Protection ==
Since we're calculating backwards from the target values we wanna achieve based on values extracted from ngspice simulations using the SPICE models, it is no wonder that the final ngspice simulation turns out to check out fine for all the pad cells we generate.

The whole math is being documented in [[Physics-Based Wire Sizing for I/O Pad Cells]]

Subsequently the ngspice analysis and verification of the reverse solved hardware design can be found in [[ESD Verification]]

LibreSilicon stack

2026-05-29T09:37:56Z

Leviathan: /* Pad Cells */

LibreSilicon includes not only software but also a manufacturing process flow standard with recipes and machine designs.
A detailed overview with links goes onto this page.

LibreSilicon can be roughly divided into two main categories, physical manufacturing as well as the tool chain part

== Software ==
For doing anything useful with your foundry, you need a way of verifying your setup, for which we provide you the test wafer generator [[Danube River]], then you need standard logic cells for synthesizing, placing and routing your layout, and of pad cells so that you can wire bond your chip;

=== Process Verification ===
When setting up a new foundry, no matter the scale, the physical manufacturing needs to be verified, using a test wafer, for this purpose we provide a dynamic test wafer generator named [[Danube River]], which you can provide your own technology specs based on initial calculations for your setup and then verify and adjust your values until everything is correct.
[[File:Danube For New Foundry.png|none|thumb|653x653px]]

=== Standard Cells ===
You need standard logic cells, small logic gate layouts made from place and routing discrete FETs, in order to turn the RTL level logic Yosys spits out into an actual digital chip layout.

Originally Philip was working on [[StdCellLib]], but he re-licensed it under Apache which kind of defeats the purpose of a project calling itself '''Libre'''Silicon. Because Leviathan was a bit triggered by this due to his definition of Libre being the same as the Free Software Foundation, which means, that it's supposed under a GNU Public License, he decided to work on introducing the functionality for placing and routing standard logic cells in [[LibrePDK]] as well, in addition to analog and pad cell generation.

=== Pad Cells ===
The [[Pad Cell Generator]] is part of the [[LibrePDK]] and can be used to created custom sets of pad cells with custom rail voltages and you can even define a set of currents your pad frame is supposed to end up driving.
[[File:30mA SG13G2@1V2 v2.png|none|thumb|419x419px|30mA pad cell for IHPSG13G2 at 1.2V]]
The pad cell has such thin wires, because the ultimate wire width has to be determined based on the final current which is supposed to be driven by the overall pad frame the cells are being generated for.
=== Pad Frames ===
The [[Pad Frame Generator]] has the job of taking in a JSON with pin assignment for the East, North, South and West bank and then calculate the wire dimensions of the overall padframe based on the projected peak currents as well as to choose the right pad cell type for each assigned pin.
[[File:Pad Frame v2 Example SG13G2@1V2.png|none|thumb|Pad Frame Example SG13G2@1.2V]]
The resulting output will be a pad frame in Magic, GDS2, LEF and DEF format, which you can use for placing and routing your internal logic to.

==Physical manufacturing==

The physical manufacturing includes things like:

* [[Chemical processing]]
* [[Photolithography]]

File:30mA SG13G2@1V2 v2.png

2026-05-29T09:37:17Z

Leviathan:

30mA SG13G2@1V2 v2

LibreSilicon stack

2026-05-29T09:28:30Z

Leviathan: /* Pad Frames */

LibreSilicon includes not only software but also a manufacturing process flow standard with recipes and machine designs.
A detailed overview with links goes onto this page.

LibreSilicon can be roughly divided into two main categories, physical manufacturing as well as the tool chain part

== Software ==
For doing anything useful with your foundry, you need a way of verifying your setup, for which we provide you the test wafer generator [[Danube River]], then you need standard logic cells for synthesizing, placing and routing your layout, and of pad cells so that you can wire bond your chip;

=== Process Verification ===
When setting up a new foundry, no matter the scale, the physical manufacturing needs to be verified, using a test wafer, for this purpose we provide a dynamic test wafer generator named [[Danube River]], which you can provide your own technology specs based on initial calculations for your setup and then verify and adjust your values until everything is correct.
[[File:Danube For New Foundry.png|none|thumb|653x653px]]

=== Standard Cells ===
You need standard logic cells, small logic gate layouts made from place and routing discrete FETs, in order to turn the RTL level logic Yosys spits out into an actual digital chip layout.

Originally Philip was working on [[StdCellLib]], but he re-licensed it under Apache which kind of defeats the purpose of a project calling itself '''Libre'''Silicon. Because Leviathan was a bit triggered by this due to his definition of Libre being the same as the Free Software Foundation, which means, that it's supposed under a GNU Public License, he decided to work on introducing the functionality for placing and routing standard logic cells in [[LibrePDK]] as well, in addition to analog and pad cell generation.

=== Pad Cells ===
The [[Pad Cell Generator]] is part of the [[LibrePDK]] and can be used to created custom sets of pad cells with custom rail voltages and you can even define a set of currents your pad frame is supposed to end up driving.
[[File:Io cell 20mA.png|none|thumb|20mA pad cell for IHPSG13G2 at 1.2V]]
The pad cell has such thin wires, because the ultimate wire width has to be determined based on the final current which is supposed to be driven by the overall pad frame the cells are being generated for.
=== Pad Frames ===
The [[Pad Frame Generator]] has the job of taking in a JSON with pin assignment for the East, North, South and West bank and then calculate the wire dimensions of the overall padframe based on the projected peak currents as well as to choose the right pad cell type for each assigned pin.
[[File:Pad Frame v2 Example SG13G2@1V2.png|none|thumb|Pad Frame Example SG13G2@1.2V]]
The resulting output will be a pad frame in Magic, GDS2, LEF and DEF format, which you can use for placing and routing your internal logic to.

==Physical manufacturing==

The physical manufacturing includes things like:

* [[Chemical processing]]
* [[Photolithography]]

File:Pad Frame v2 Example SG13G2@1V2.png

2026-05-29T09:27:55Z

Leviathan:

Pad Frame v2 Example SG13G2@1V2

Pad Frame Generator

2026-05-28T16:18:33Z

Leviathan:

The Pad Frame Generator is part of the [[LibrePDK]][[File:Preliminary First Pad Frame generated.png|thumb|First Version of a Padframe of IHP's SG13G2 generated by LibrePDK (Still needs some work)]]It's job is to assemble a ready to use pad frame harness, with ESD protection and power rail wire width properly adjusted for accommodating the intended current driving capacity as well as the intended voltage levels to be used.

Pad Cell Generator

2026-05-28T16:17:06Z

Leviathan:

[[File:Io cell 20mA@1.2V.png|thumb|20mA Pad Cell for IHP's SG13G2@1.2V]]
The LibreSilicon Pad Cell Generator is an extension of the [[LibrePDK]] which besides the driver logic also dynamically generates the mixed signal parts needed for over current and static discharge protection and providing the currents needed for doing useful things with an actual physical chip, like driving an LED or a small motor.

== Existing Groundwork ==
The generator is based on the work of several folks who started developing puzzle pieces for it before Google ran out of funding internally and the project had to go on hiatus

Here's some works our generator will be based on:

* Gowthami Nalla did some work with the logic circuit and the driver but it's specific to XFAB only; https://github.com/gowthaminalla/bidirectional-buffer/
* Very rudimentary development has been done on the ESD front: https://github.com/AishikAnalogCKTdesign/ESD
* Philip's pad frame generator (Perl): https://www2.futureware.at/~philipp/vsd2018/
* Philip's very basic Perl based pad cell generator (https://pdk.libresilicon.com/PadCellGenerator.zip)
** Perl based
** Not portable
** Needs smarter ESD protection
** Needs smarter IO config
** Doesn't have termination resistor configuration (needed for DDR3/DDR4 PHYs)
** Not even yet half finished

== Configuration ==
The Pad Cell Generator has the task of generating a [[Pad Cell]] for generating a pad frame for taping out a circuit with any given set of design rules for any given process.

Just as with the Standard Cell Generator, you need to provide the Pad Cell Generator the appropriate configuration telling it about all the design constraints and mixed signal characteristics of the process you are targeting.

Please look at our reference technology folders like the design rule constraints and parameters, for which we introduced a somewhat standardized format with the advent of our [[Danube River]] test wafer generator.

== How to use ==
The Pad Cell Generator is part of [[LibrePDK]]

Running the following script within the LibrePDK folder, after following the installation instructions...<syntaxhighlight lang="bash">
#!/bin/bash
TECH=SG13G2
VOLTAGE=1.2
mkdir -p ihp_pads
pushd ihp_pads
uv run librepdk_padcell_generator -t $TECH -v $VOLTAGE -i 20,30,40,60
popd
</syntaxhighlight>You should end up with a set of pad cells dimensioned for 20mA, 30mA, 40mA and 60mA driver strength, plus a demo assembly which looks somewhat like this (still work in progress)
[[File:Preliminary First Pad Frame generated.png|none|thumb]]

== Electrical Discharge Protection ==
Since we're calculating backwards from the target values we wanna achieve based on values extracted from ngspice simulations using the SPICE models, it is no wonder that the final ngspice simulation turns out to check out fine for all the pad cells we generate.

The whole math is being documented in [[Physics-Based Wire Sizing for I/O Pad Cells]]

Subsequently the ngspice analysis and verification of the reverse solved hardware design can be found in [[ESD Verification]]

Pad Frame Generator

2026-05-28T16:16:33Z

Leviathan: Created page with "First Version of a Padframe of IHP's SG13G2 generated by LibrePDK (Still needs some work)"

[[File:Preliminary First Pad Frame generated.png|thumb|First Version of a Padframe of IHP's SG13G2 generated by LibrePDK (Still needs some work)]]

Pad Cell Generator

2026-05-28T16:15:58Z

Leviathan:

[[File:Io cell 20mA@1.2V.png|thumb|Io cell 20mA@1.2V]]
The LibreSilicon Pad Cell Generator is an extension of the [[LibrePDK]] which besides the driver logic also dynamically generates the mixed signal parts needed for over current and static discharge protection and providing the currents needed for doing useful things with an actual physical chip, like driving an LED or a small motor.

== Existing Groundwork ==
The generator is based on the work of several folks who started developing puzzle pieces for it before Google ran out of funding internally and the project had to go on hiatus

Here's some works our generator will be based on:

* Gowthami Nalla did some work with the logic circuit and the driver but it's specific to XFAB only; https://github.com/gowthaminalla/bidirectional-buffer/
* Very rudimentary development has been done on the ESD front: https://github.com/AishikAnalogCKTdesign/ESD
* Philip's pad frame generator (Perl): https://www2.futureware.at/~philipp/vsd2018/
* Philip's very basic Perl based pad cell generator (https://pdk.libresilicon.com/PadCellGenerator.zip)
** Perl based
** Not portable
** Needs smarter ESD protection
** Needs smarter IO config
** Doesn't have termination resistor configuration (needed for DDR3/DDR4 PHYs)
** Not even yet half finished

== Configuration ==
The Pad Cell Generator has the task of generating a [[Pad Cell]] for generating a pad frame for taping out a circuit with any given set of design rules for any given process.

Just as with the Standard Cell Generator, you need to provide the Pad Cell Generator the appropriate configuration telling it about all the design constraints and mixed signal characteristics of the process you are targeting.

Please look at our reference technology folders like the design rule constraints and parameters, for which we introduced a somewhat standardized format with the advent of our [[Danube River]] test wafer generator.

== How to use ==
The Pad Cell Generator is part of [[LibrePDK]]

Running the following script within the LibrePDK folder, after following the installation instructions...<syntaxhighlight lang="bash">
#!/bin/bash
TECH=SG13G2
VOLTAGE=1.2
mkdir -p ihp_pads
pushd ihp_pads
uv run librepdk_padcell_generator -t $TECH -v $VOLTAGE -i 20,30,40,60
popd
</syntaxhighlight>You should end up with a set of pad cells dimensioned for 20mA, 30mA, 40mA and 60mA driver strength, plus a demo assembly which looks somewhat like this (still work in progress)
[[File:Preliminary First Pad Frame generated.png|none|thumb]]

== Electrical Discharge Protection ==
Since we're calculating backwards from the target values we wanna achieve based on values extracted from ngspice simulations using the SPICE models, it is no wonder that the final ngspice simulation turns out to check out fine for all the pad cells we generate.

The whole math is being documented in [[Physics-Based Wire Sizing for I/O Pad Cells]]

Subsequently the ngspice analysis and verification of the reverse solved hardware design can be found in [[ESD Verification]]

Pad Cell Generator

2026-05-28T16:15:33Z

Leviathan:

The LibreSilicon Pad Cell Generator is an extension of the [[LibrePDK]] which besides the driver logic also dynamically generates the mixed signal parts needed for over current and static discharge protection and providing the currents needed for doing useful things with an actual physical chip, like driving an LED or a small motor.

<blockquote></blockquote>

== Existing Groundwork ==
The generator is based on the work of several folks who started developing puzzle pieces for it before Google ran out of funding internally and the project had to go on hiatus

Here's some works our generator will be based on:

* Gowthami Nalla did some work with the logic circuit and the driver but it's specific to XFAB only; https://github.com/gowthaminalla/bidirectional-buffer/
* Very rudimentary development has been done on the ESD front: https://github.com/AishikAnalogCKTdesign/ESD
* Philip's pad frame generator (Perl): https://www2.futureware.at/~philipp/vsd2018/
* Philip's very basic Perl based pad cell generator (https://pdk.libresilicon.com/PadCellGenerator.zip)
** Perl based
** Not portable
** Needs smarter ESD protection
** Needs smarter IO config
** Doesn't have termination resistor configuration (needed for DDR3/DDR4 PHYs)
** Not even yet half finished

== Configuration ==
The Pad Cell Generator has the task of generating a [[Pad Cell]] for generating a pad frame for taping out a circuit with any given set of design rules for any given process.

Just as with the Standard Cell Generator, you need to provide the Pad Cell Generator the appropriate configuration telling it about all the design constraints and mixed signal characteristics of the process you are targeting.

Please look at our reference technology folders like the design rule constraints and parameters, for which we introduced a somewhat standardized format with the advent of our [[Danube River]] test wafer generator.

== How to use ==
The Pad Cell Generator is part of [[LibrePDK]]

Running the following script within the LibrePDK folder, after following the installation instructions...<syntaxhighlight lang="bash">
#!/bin/bash
TECH=SG13G2
VOLTAGE=1.2
mkdir -p ihp_pads
pushd ihp_pads
uv run librepdk_padcell_generator -t $TECH -v $VOLTAGE -i 20,30,40,60
popd
</syntaxhighlight>You should end up with a set of pad cells dimensioned for 20mA, 30mA, 40mA and 60mA driver strength, plus a demo assembly which looks somewhat like this (still work in progress)
[[File:Preliminary First Pad Frame generated.png|none|thumb]]

== Electrical Discharge Protection ==
Since we're calculating backwards from the target values we wanna achieve based on values extracted from ngspice simulations using the SPICE models, it is no wonder that the final ngspice simulation turns out to check out fine for all the pad cells we generate.

The whole math is being documented in [[Physics-Based Wire Sizing for I/O Pad Cells]]

Subsequently the ngspice analysis and verification of the reverse solved hardware design can be found in [[ESD Verification]]

LibreSilicon stack

2026-05-28T16:15:04Z

Leviathan: /* Pad Cells */

LibreSilicon includes not only software but also a manufacturing process flow standard with recipes and machine designs.
A detailed overview with links goes onto this page.

LibreSilicon can be roughly divided into two main categories, physical manufacturing as well as the tool chain part

== Software ==
For doing anything useful with your foundry, you need a way of verifying your setup, for which we provide you the test wafer generator [[Danube River]], then you need standard logic cells for synthesizing, placing and routing your layout, and of pad cells so that you can wire bond your chip;

=== Process Verification ===
When setting up a new foundry, no matter the scale, the physical manufacturing needs to be verified, using a test wafer, for this purpose we provide a dynamic test wafer generator named [[Danube River]], which you can provide your own technology specs based on initial calculations for your setup and then verify and adjust your values until everything is correct.
[[File:Danube For New Foundry.png|none|thumb|653x653px]]

=== Standard Cells ===
You need standard logic cells, small logic gate layouts made from place and routing discrete FETs, in order to turn the RTL level logic Yosys spits out into an actual digital chip layout.

Originally Philip was working on [[StdCellLib]], but he re-licensed it under Apache which kind of defeats the purpose of a project calling itself '''Libre'''Silicon. Because Leviathan was a bit triggered by this due to his definition of Libre being the same as the Free Software Foundation, which means, that it's supposed under a GNU Public License, he decided to work on introducing the functionality for placing and routing standard logic cells in [[LibrePDK]] as well, in addition to analog and pad cell generation.

=== Pad Cells ===
The [[Pad Cell Generator]] is part of the [[LibrePDK]] and can be used to created custom sets of pad cells with custom rail voltages and you can even define a set of currents your pad frame is supposed to end up driving.
[[File:Io cell 20mA.png|none|thumb|20mA pad cell for IHPSG13G2 at 1.2V]]
The pad cell has such thin wires, because the ultimate wire width has to be determined based on the final current which is supposed to be driven by the overall pad frame the cells are being generated for.
=== Pad Frames ===
The [[Pad Frame Generator]] has the job of taking in a JSON with pin assignment for the East, North, South and West bank and then calculate the wire dimensions of the overall padframe based on the projected peak currents as well as to choose the right pad cell type for each assigned pin.[[File:Preliminary First Pad Frame generated.png|thumb|An example of an early result of LibrePDK|none]]

The resulting output will be a pad frame in Magic, GDS2, LEF and DEF format, which you can use for placing and routing your internal logic to.

==Physical manufacturing==

The physical manufacturing includes things like:

* [[Chemical processing]]
* [[Photolithography]]

LibreSilicon stack

2026-05-28T16:11:19Z

Leviathan: /* Pad Cells */

LibreSilicon includes not only software but also a manufacturing process flow standard with recipes and machine designs.
A detailed overview with links goes onto this page.

LibreSilicon can be roughly divided into two main categories, physical manufacturing as well as the tool chain part

== Software ==
For doing anything useful with your foundry, you need a way of verifying your setup, for which we provide you the test wafer generator [[Danube River]], then you need standard logic cells for synthesizing, placing and routing your layout, and of pad cells so that you can wire bond your chip;

=== Process Verification ===
When setting up a new foundry, no matter the scale, the physical manufacturing needs to be verified, using a test wafer, for this purpose we provide a dynamic test wafer generator named [[Danube River]], which you can provide your own technology specs based on initial calculations for your setup and then verify and adjust your values until everything is correct.
[[File:Danube For New Foundry.png|none|thumb|653x653px]]

=== Standard Cells ===
You need standard logic cells, small logic gate layouts made from place and routing discrete FETs, in order to turn the RTL level logic Yosys spits out into an actual digital chip layout.

Originally Philip was working on [[StdCellLib]], but he re-licensed it under Apache which kind of defeats the purpose of a project calling itself '''Libre'''Silicon. Because Leviathan was a bit triggered by this due to his definition of Libre being the same as the Free Software Foundation, which means, that it's supposed under a GNU Public License, he decided to work on introducing the functionality for placing and routing standard logic cells in [[LibrePDK]] as well, in addition to analog and pad cell generation.

=== Pad Cells ===
The [[Pad Cell Generator]] is part of the [[LibrePDK]] and can be used to created custom sets of pad cells with custom rail voltages and you can even define a set of currents your pad frame is supposed to end up driving.

=== Pad Frames ===
[[File:Preliminary First Pad Frame generated.png|thumb|An example of an early result of LibrePDK|none]]

==Physical manufacturing==

The physical manufacturing includes things like:

* [[Chemical processing]]
* [[Photolithography]]

LibreSilicon stack

2026-05-28T16:10:42Z

Leviathan:

LibreSilicon includes not only software but also a manufacturing process flow standard with recipes and machine designs.
A detailed overview with links goes onto this page.

LibreSilicon can be roughly divided into two main categories, physical manufacturing as well as the tool chain part

== Software ==
For doing anything useful with your foundry, you need a way of verifying your setup, for which we provide you the test wafer generator [[Danube River]], then you need standard logic cells for synthesizing, placing and routing your layout, and of pad cells so that you can wire bond your chip;

=== Process Verification ===
When setting up a new foundry, no matter the scale, the physical manufacturing needs to be verified, using a test wafer, for this purpose we provide a dynamic test wafer generator named [[Danube River]], which you can provide your own technology specs based on initial calculations for your setup and then verify and adjust your values until everything is correct.
[[File:Danube For New Foundry.png|none|thumb|653x653px]]

=== Standard Cells ===
You need standard logic cells, small logic gate layouts made from place and routing discrete FETs, in order to turn the RTL level logic Yosys spits out into an actual digital chip layout.

Originally Philip was working on [[StdCellLib]], but he re-licensed it under Apache which kind of defeats the purpose of a project calling itself '''Libre'''Silicon. Because Leviathan was a bit triggered by this due to his definition of Libre being the same as the Free Software Foundation, which means, that it's supposed under a GNU Public License, he decided to work on introducing the functionality for placing and routing standard logic cells in [[LibrePDK]] as well, in addition to analog and pad cell generation.

=== Pad Cells ===
[[File:Preliminary First Pad Frame generated.png|thumb|An example of an early result of LibrePDK|none]]
The [[Pad Cell Generator]] is part of the [[LibrePDK]] and can be used to created custom sets of pad cells with custom rail voltages and you can even define a set of currents your pad frame is supposed to end up driving.

=== Pad Frames ===

==Physical manufacturing==

The physical manufacturing includes things like:

* [[Chemical processing]]
* [[Photolithography]]

Basic Tooling

2026-05-28T14:26:15Z

Leviathan: Created page with "In order to not have to rely on foundries anymore and to truly democratize semiconductor manufacturing equipment, and eliminating the risk of supply chain attacks by eliminating the supply chain all together, a minimum viable lab setup is needed for making semiconductor structures in your shed. In order to manufacture transistors, you need the capability of performing the below basic physical operations on your sample == Lower Particle Count in the Air == == Heat Trea..."

ESD Verification

2026-05-28T01:10:44Z

Leviathan: /* ESD Waveforms */

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh visual
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path
* a bias on <code>NOT_EN</code> so the driver remains disabled during the pulse

This is just the driver stage test. The input buffer will be having additional tests

== ESD path: Bonding Path to VSS ESD and VDD ESD ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.

Here are some simulation values extracted from ngspice

* '''Peak PAD voltage:''' 1910.869 V
* '''Peak current:''' 1.314834 A
* '''Peak resistor power:''' 2.593 kW That's over a 1.5 kΩ sense resistor, the power dissipated over the actual diodes is is only 3.144856 µJ
* '''Final dissipated energy:''' 3.144856 µJ

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the '''micro''' Jules range (3.144856 µJ)

That's nothing
[[File:HBM ESD dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

You can see how the voltage on the bonding pad drops while the current and power stays very small[[File:Hbm esd waveforms.png|none|thumb|335x335px]]
2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.

Just as dimensionsed, the ESD protection does its job

Only in the beginning there's a huge peak in current 1.314834 A, but since it's only a burst of a few nano seconds the ESD diodes handle it with ease

== ESD path from bonding to internal logic ==
The second test is the simulation of whether we have a calculated break through between the external bonding pad and the internal GPIO logic going into the digital core logic (center of the die)
[[File:ESD path from outside to internal.png|none|thumb]]
As you can see (hopefully) in the drawing I quickly made here in my KolourPaint, we simulate the ESD breakthrough path, which is expected to be negligible due to our backwards calculation, from the outside pad based on the Human Body Model through the pad cell, through the digital logic to ground.

=== The IHP SG13G2 @ 1.2V case ===
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

The thermal budget also plays a role but not as much as electron migration and so.
[[File:Io cell 20mA@1.2V.png|none|thumb|300x300px|IHP cell for 20mA @ 1.2V]]

=== The IHP SG13G2 @ 3.3V case ===
[[File:Io cell 20mA.png|none|thumb]]

ESD Verification

2026-05-28T01:09:18Z

Leviathan: /* ESD path: Bonding Path to VSS ESD and VDD ESD */

ESD Verification

2026-05-28T01:08:54Z

Leviathan: /* ESD Waveforms */

ESD Verification

2026-05-28T00:45:42Z

Leviathan:

ESD Verification

2026-05-28T00:45:03Z

Leviathan:

ESD Verification

2026-05-28T00:43:16Z

Leviathan:

File:HBM ESD dissipation SG13G2@1.2V.png

2026-05-28T00:42:08Z

Leviathan:

HBM ESD dissipation SG13G2@1.2V

ESD Verification

2026-05-28T00:23:22Z

Leviathan: /* HBM ESD Zoomed In */

ESD Verification

2026-05-28T00:22:25Z

Leviathan:

File:Hbm esd waveforms.png

2026-05-28T00:17:46Z

Leviathan: HBM ESD waveform SG13G2@1.2V

== Summary ==
HBM ESD waveform SG13G2@1.2V

ESD Verification

2026-05-27T23:46:04Z

Leviathan:

Below two examples from our automated test suite showcasing how our approach reverse solving the [[wikipedia:Human-body_model|HBM model]] math as elaborated in [[Physics-Based_Wire_Sizing_for_I/O_Pad_Cells]] actually leads to simulation results in ngspice which show that our ESD diodes we chose actually protect our internal circuitry.

Oh wow. When you solve Ohm's law in one direction and then the other, you end up with the current you originally have defined at a certain voltage. Who would have thought this... anyway. Here some examples.

After running<syntaxhighlight lang="bash">
./tests/test_all_padcells.sh visual
</syntaxhighlight>you end up with a folder called "generated_output"

We're looking at "generated_output/SG13G2/padcell/1.2V" and "generated_output/SG13G2/padcell/3.3V" here as examples

As described [https://gitlab.libresilicon.com/generator-tools/librepdk/-/blob/master/docs/testing/padcells.md?ref_type=heads here] the test setup is really simple:

The deck models a basic HBM discharge setup with:

* a 100 pF capacitor
* a 1.5 kΩ series resistor
* a switched discharge path
* a bias on <code>NOT_EN</code> so the driver remains disabled during the pulse

This is just the driver stage test. The input buffer will be having additional tests

== ESD path: Bonding Path to VSS ESD and VDD ESD ==
The energy which would otherwise go through the internal digital logic takes the alternative path of least resistance, which is the two diodes (we're not generating Schottky diodes yet, see the list of devices in [[LibrePDK]]), which we put as close to the bonding pad as possible.

Here a quick drawing to illustrate the configuration.
[[File:PAD-VDD-VSS ESD path.png|none|thumb|200x200px]]
Inthe case of IHP SG13G2 @ 1.2V the discharge simulation looks like plotted below.
[[File:Hbm esd dissipation (Diodes) SG13G2@3.3V.png|none|thumb|Hbm esd dissipation (Diodes) SG13G2@1.2V]]
You can see how the voltage on the bonding pad drops while the current and power stays very small
[[File:Hbm esd waveforms.png|none|thumb]]
Hbm esd dissipation (Diodes) SG13G2@1.2V

Just as dimensionsed, the ESD protection does its job

== ESD path from bonding to internal logic ==
The second test is the simulation of whether we have a calculated break through between the external bonding pad and the internal GPIO logic going into the digital core logic (center of the die)
[[File:ESD path from outside to internal.png|none|thumb]]
As you can see (hopefully) in the drawing I quickly made here in my KolourPaint, we simulate the ESD breakthrough path, which is expected to be neglectable due to our backwards calculation, from the outside pad based on the Human Body Model through the pad cell, through the digital logic to ground.

=== The IHP SG13G2 @ 1.2V case ===
Comparing those two you will notice that the pad with the lower operational voltage needs more area.

While at first counter intuitive, this is because we're not dealing with Ohm's law here but with solid state physics, such as hot carriers and the such.

The thermal budget also plays a role but not as much as electron migration and so.
[[File:Io cell 20mA@1.2V.png|none|thumb|300x300px|IHP cell for 20mA @ 1.2V]]

==== HBM ESD Dissipation ====
Assuming a typical ESD discharge of a few nanoseconds the energy absorbed by the chip itself is in the micro Jules range

That's nothing[[File:Hbm esd dissipation SG13G2@1.2V.png|none|thumb]]

==== ESD Waveforms ====
The current flowing through the pad during an ESD event is only 2100 * 1e-10 at its peak.

2100*0.1nA = 210nA = 0.2uA ... high ohmic inputs when being turned off are doing high ohmic things.[[File:Hbm esd waveforms SG13G2@1.2V.png|none|thumb]]

==== HBM ESD Zoomed In ====
[[File:Hbm esd zoom SG13G2@1.2V.png|alt=Hbm esd zoom SG13G2@1.2V|none|thumb|Hbm esd zoom SG13G2@1.2V]]

=== The IHP SG13G2 @ 3.3V case ===

When you look at this thing here and its simulation result, it's no surprise that it has the same results as the 1.2V one, because they've been dimensioned based on the same math.[[File:Io cell 20mA.png|none|thumb|IHP cell for 20mA @ 3.3V]]

==== HBM ESD Dissipation ====
[[File:Hbm esd dissipation SG13G2@3.3V.png|none|thumb]]

==== ESD Waveforms ====
[[File:Hbm esd waveforms SG13G2@3.3V.png|none|thumb]]

==== HBM ESD Zoomed In ====
[[File:Hbm esd zoom SG13G2@3.3V.png|none|thumb]]

File:PAD-VDD-VSS ESD path.png

2026-05-27T23:44:30Z

Leviathan:

PAD/VDD/VSS ESD path

ESD Verification

2026-05-26T19:17:08Z

Leviathan:

File:ESD path from outside to internal.png

2026-05-26T19:15:19Z

Leviathan:

I quickly made it in KolourPaint

LibrePDK

2026-05-26T02:35:29Z

Leviathan:

Pad Cell Generator

2026-05-26T02:33:13Z

Leviathan: /* Configuration */

The LibreSilicon Pad Cell Generator is an extension of the [[LibrePDK]] which besides the driver logic also dynamically generates the mixed signal parts needed for over current and static discharge protection and providing the currents needed for doing useful things with an actual physical chip, like driving an LED or a small motor.
[[File:Preliminary First Pad Frame generated.png|thumb|First Version of a Padframe of IHP's SG13G2 generated by LibrePDK (Still needs some work)]]
<blockquote></blockquote>

== Existing Groundwork ==
The generator is based on the work of several folks who started developing puzzle pieces for it before Google ran out of funding internally and the project had to go on hiatus

Here's some works our generator will be based on:

* Gowthami Nalla did some work with the logic circuit and the driver but it's specific to XFAB only; https://github.com/gowthaminalla/bidirectional-buffer/
* Very rudimentary development has been done on the ESD front: https://github.com/AishikAnalogCKTdesign/ESD
* Philip's pad frame generator (Perl): https://www2.futureware.at/~philipp/vsd2018/
* Philip's very basic Perl based pad cell generator (https://pdk.libresilicon.com/PadCellGenerator.zip)
** Perl based
** Not portable
** Needs smarter ESD protection
** Needs smarter IO config
** Doesn't have termination resistor configuration (needed for DDR3/DDR4 PHYs)
** Not even yet half finished

== Configuration ==
The Pad Cell Generator has the task of generating a [[Pad Cell]] for generating a pad frame for taping out a circuit with any given set of design rules for any given process.

Just as with the Standard Cell Generator, you need to provide the Pad Cell Generator the appropriate configuration telling it about all the design constraints and mixed signal characteristics of the process you are targeting.

Please look at our reference technology folders like the design rule constraints and parameters, for which we introduced a somewhat standardized format with the advent of our [[Danube River]] test wafer generator.

== How to use ==
The Pad Cell Generator is part of [[LibrePDK]]

Running the following script within the LibrePDK folder, after following the installation instructions...<syntaxhighlight lang="bash">
#!/bin/bash
TECH=SG13G2
VOLTAGE=1.2
mkdir -p ihp_pads
pushd ihp_pads
uv run librepdk_padcell_generator -t $TECH -v $VOLTAGE -i 20,30,40,60
popd
</syntaxhighlight>You should end up with a set of pad cells dimensioned for 20mA, 30mA, 40mA and 60mA driver strength, plus a demo assembly which looks somewhat like this (still work in progress)
[[File:Preliminary First Pad Frame generated.png|none|thumb]]

== Electrical Discharge Protection ==
Since we're calculating backwards from the target values we wanna achieve based on values extracted from ngspice simulations using the SPICE models, it is no wonder that the final ngspice simulation turns out to check out fine for all the pad cells we generate.

The whole math is being documented in [[Physics-Based Wire Sizing for I/O Pad Cells]]

Subsequently the ngspice analysis and verification of the reverse solved hardware design can be found in [[ESD Verification]]

ESD Verification

2026-05-26T02:27:35Z

Leviathan:

ESD Verification

2026-05-26T02:05:26Z

Leviathan: /* HBM ESD Dissipation */