Pad Cell Generator: Difference between revisions

From LibreSilicon
Jump to navigation Jump to search
No edit summary
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
The LibreSilicon Pad Cell Generator is an extension of the [https://wiki.libresilicon.com/LibrePDK 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: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.
[[File:Padcell.png|none|thumb|302x302px|Pad Cell in Magic editor]]<blockquote></blockquote>


== Existing Groundwork ==
== Existing Groundwork ==
Line 22: Line 21:
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.
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 targetting.
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.
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.


https://github.com/thesourcerer8/StdCellLib/tree/master/Tech.GF180MCU
== How to use ==
 
The Pad Cell Generator is part of [[LibrePDK]]
== How to use (WIP) ==
First clone the repository
 
git clone https://gitlab.libresilicon.com/leviathan/PadCellGenerator.git
cd PadCellGenerator
 
Then you fetch the Dockerimage with all the LibreSilicon tools preinstalled, just as with DanubeRiver and the Standard Logic Cell generator library:
 
docker pull leviathanch/libresilicon-tools:latest
 
Then you've got to start the Docker container and build the pad cells for your specific process


xhost +local:docker
Running the following script within the LibrePDK folder, after following the installation instructions...<syntaxhighlight lang="bash">
docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -v `pwd`:/work -it leviathanch/libresilicon-tools
uv run librepdk_padframe_generator -i tests/padframes/padframe_sg13g2_1v2.json
Or respectively just
</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)
./start_docker.sh
[[File:Pad Frame v2 Example SG13G2@1V2.png|none|thumb]]
<blockquote>'''Notice''': This is work in progress. This Wiki page is about to change a lot and gain much more content soon... hopefully


== 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.


'''Notice''': NLNet approved the grant. On it (https://nlnet.nl/project/LibreSilicon-PadCellGen/)</blockquote>After that there's some make commands telling my Python scripts, which I haven't pushed yet, what to do, as soon as they can actually do it...
The whole math is being documented in [[Physics-Based Wire Sizing for I/O Pad Cells]]


For now it's just Perl scripts and some loose Magic files
Subsequently the ngspice analysis and verification of the reverse solved hardware design can be found in [[ESD Verification]]

Latest revision as of 09:41, 29 May 2026

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:

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...

uv run librepdk_padframe_generator -i tests/padframes/padframe_sg13g2_1v2.json

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)

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