Complete set of device generation scripts for magic

[RTimothyEdwards]

Added scripts to magic for generated devices, as well as an overhaul of the tech file to split it into
multiple files. The generated devices have also been split into multiple files with one file per device class. Certain devices that have fixed layout are kept as a Tcl script of magic commands which build the cell. The magicrc startup file now sources the generated devices.

Fixes #<issue_number_goes_here>

• Tests pass
• Appropriate changes to README are included in PR

[RTimothyEdwards]

This pull request comprises the work I have done over the past three months. All devices have generation scripts in magic and are done to my ability to make them complete. There are some questions remaining about what the syntax of CDL format is supposed to be. The Schottky diode may be incomplete as I only noticed today the pull request that adds the Schottky model. But I still have a week to finish things up, according to plan.

I will put this in draft mode while I prepare some tests and documentation. An initial review would be helpful.

There were about a dozen commits to this repo, but I had difficulty in attempting to rebase and ended up just cloning a fresh version of dev and copying all my work into it, and committing that. Notice that the original branch was called "gencell_devel" but is now "magic_gencells". I will add my original commit notes to my release notes.

[sergeiandreyev]

Hi @RTimothyEdwards, thank you for your valuable contribution to this project!
now we need volunteers to try it out :)

[RTimothyEdwards]

@sergeiandreyev @KrzysztofHerman : I have taken the pull request out of draft mode; it is ready for review and merge.

[d-m-bailey]

@RTimothyEdwards We've been working on testing the lvs extraction mode of the tech file and have come across some issues. These issues are not just with the magic tech file, but the CDL definitions, klayout, and xschem models also.

We're working on test cases based on previously taped out designs.

Here's a sample of bipolar devices that don't extract.

testcase_IHP-Open-PDK-PR724.tar.gz

CC: @H-Ojiro

[d-m-bailey]

@sergeiandreyev @KrzysztofHerman

@H-Ojiro and I have been reviewing, testing and comparing the magic tech file, klayout LVS rules, Laker CDL documentation, ngspice models, xschem primitive devices, and the online LVS documentation for sg13g2 here.

We'd like to help verify and clarify the interoperability of these systems.

We could start a new issue, a discussion, or somewhere else. Where would be the best place to do that?

Maybe we could start a discussion where the main topic would be a continually updated section that contains the status of each device with explanations of discrepancies and links to individual issues and pull requests. Here's a sample #738.

[d-m-bailey]

@RTimothyEdwards the klayout lvs rules have data for a unit test suite here.

Would you like us to attempt to use this data to implement a regression test for the magic/netgen flow also? There's also a test suite for the standard cells.

[RTimothyEdwards]

@d-m-bailey : Yes, definitely.

[rjordans]

I have been testing this with my LDO design from https://github.com/rjordans/TO_Sep2025/tree/main/FLDO/design_data/mag

In Klayout I get a bunch of TGO.a DRC errors on the thick oxide expansion. It needs to be at least 0.27 um, magic now has a bloat-or to extend it to 0.185 um. The below change fixes the problem:

diff --git a/ihp-sg13g2/libs.tech/magic/ihp-sg13g2-cifout.tech b/ihp-sg13g2/libs.tech/magic/ihp-sg13g2-cifout.tech
index dff8294..302f5a0 100644
--- a/ihp-sg13g2/libs.tech/magic/ihp-sg13g2-cifout.tech
+++ b/ihp-sg13g2/libs.tech/magic/ihp-sg13g2-cifout.tech
@@ -373,7 +373,7 @@ style gdsii
  layer THKOX schottkyarea,varactorarea
        grow 100
        or alldiffhv,var,pvar
-        bloat-or alldiffhv,var,pvar * 185 alldifflv 0
+        bloat-or alldiffhv,var,pvar * 270 alldifflv 0
        grow-min 860
        bridge 860 860
        grow    430

[RTimothyEdwards]

@rjordans : Fixed, thanks for the diff.

[d-m-bailey]

@RTimothyEdwards
Here is the test setup @H-Ojiro created for the errors found when testing the new tech file against the klayout regression test data.

1. missing diffusion - tap connection
2. small nwells dropped when placed in deep nwell

The README in the attached file has more details.

testcase-ihp-magic-netgen-cells.tgz

I think the tech file is missing DigiSub 60/0. This layer is like the SUBCUT layer, except for digital circuits. See the discussion here. #648

There is a modified tech file that passes the tests included. However, it doesn't handle cifout for DigiSub, so shouldn't be used as is.

@sergeiandreyev @KrzysztofHerman
We're working on the primitive device regression test, but have run in to a couple issues.

1. The test cell names are the same as the primitive devices. eg. sg13_lv_nmos. We're trying to rename these.
2. The primitive devices are unconnected. Literally, just placements of basic devices. magic extracts these unconnected, unlabeled nets, but netgen considers them all as floating. netgen has special processing that combines devices with floating nets, right?

[d-m-bailey]

@RTimothyEdwards @sergeiandreyev @KrzysztofHerman

Starting a discussion about the differences between the klayout and magic extraction of ntap1 and ptap1 devices.

klayout ntap1 and ptap1 devices are extracted as specified in the PDK here. nwell taps with well text and psubstrate taps with sub! are extracted as R devices. The klayout rule uses the holes function to define a region that contains n/ptap1 devices. This is fine for simple devices, but at the block or chip level, guard rings surrounding large areas (or the entire chip in case of the seal ring), will cause unwanted devices to be extracted.

In this update of the magic technology file, with or without text, all ntaps in deep nwell nBuLay are extracted as ntap1 and all ptaps in Substrate 40/0 are extracted as ptap1. These are both X devices. Tim, correct me if I'm wrong, but I don't think that magic can differentiate shapes based on text, can it?

I believe there have been discussions of the necessity of ntap1 and ptap1 before. From a purely netlist view, I don't see any merit - there are other ways to separate nets. However, if the circuit designer wanted to ensure that specific components were surrounded by a unique guard ring of a specific size, then this might be a way to do it. Is that the intended purpose?

One solution to the difference in extraction would be to use a new recognition layer instead of text. Any taps inside the recognition layer would be extracted as n/ptap1. klayout and magic can both process this the same way. magic can not extract this device as a R device, but we have shown that it is possible to extract a device ntap1_sub and then add the following subckt to the extracted layout to have LVS pass with the same CDL netlist as klayout.

.subckt ntap1_sub plus minus
R1 plus minus ntap1 a=1 l=1 w=1 perim=1
.ends

@H-Ojiro Thanks again for the analysis on this.

[RTimothyEdwards]

It is difficult to impossible to specify an R value for the ptap anyway. Is that supposed to include just the R value of the tap? The contact as well? The diffusion around it? The entire well or substrate network? That's a job for parasitic extraction. Certainly the designer drawing a schematic will have no idea what the R value is, making it useless for LVS purposes.

And yes, magic does not have an extraction method based on text stamping. Probably it could be added without much effort. It should only require searching all labels and then including all the material the label is attached to. Currently, magic is identifying ptaps as devices only during "lvs"-style extraction, and only when the "substrate" layer is present. Likewise for ntaps, if deep nwell is present. I do not know how valid that is. The PDK documentation does not say how to identify a ptap or ntap device. The libraries are inconsistent---The I/O library CDL has ptaps but not ntaps.

[d-m-bailey]

@RTimothyEdwards I agree with you on not being able to specify an R value. However, setting W and L values should be pretty straightforward, don't you think?

The "official" definitions of the ntap1 and ptap1 devices are here I think.

For example, ptap1 has Device Recognition | Activ, pSD, Substrate, text (sub!)

[RTimothyEdwards]

@d-m-bailey : "However, setting W and L values should be pretty straightforward, don't you think?"---Not at all! What is the W and L of a tap ring? Unless you make the tap a simple rectangle, only area and perimeter make sense and are measurable. Even in the I/O cell, there's a single tap in the CDL netlist which corresponds to multiple shapes in the layout. It does not pass LVS, because the L and W given for the device seem to be pulled out of thin air.

[d-m-bailey]

@RTimothyEdwards

"However, setting W and L values should be pretty straightforward, don't you think?"---Not at all!

I guess I didn't think that through.

For resistor and capacitors, there's a new derive function that allows the calculation of area and perimeter from length and width, right?
I wonder if it's possible to derive the equivalent length and width from area and perimeter for an arbitrary shape?

A=L*W -> L=A/W
P=2L+2W -> P = 2(A/W) + 2W -> PW = 2A + 2W^2 -> 2W^2 - PW + 2A = 0

Using the quadratic formula where a=2, b=-P, and c=2A

W = ( P - sqrt(P^2 - 16A)) / 4
L = ( P + sqrt(P^2 - 16A)) / 4

Doesn't quite work for closed loops though. For width=2 length=40 (10x10 square loop) the formula gives L=37.9 and W=2.1 which is within 10%. More error for shorted length and wider width.

[RTimothyEdwards]

There are plenty of non-real solutions to the quadratic equation.

But have you looked at the subcircuit model for the taps?

**ptap1 (TIE SUB)
* In order to have consistency between the netlisted device format
* the w and l parameters are defined but not used.
* The value of R is calculated by schematic capture tool.
.subckt ptap1 1 2
.param R=262.8 w=0.78e-6 l=0.78e-6
R1 1 2 R=R
.ends ptap1

That is, the simulation model doesn't even use W and L.
And it's expecting that schematic capture tool to produce R, a value that can only be known from the layout.

[d-m-bailey]

@RTimothyEdwards

There are plenty of non-real solutions to the quadratic equation.

Yes, for an arbitrary quadratic equation, there may be non-real solutions.
For the example above, this only occurs when 16A > P^2.
In other words, when
16LW > (2L+2W)^2 or 4L^2 + 8LW + 4W^2.
Reducing,
2LW > L^2 + W^2 or L^2 - 2LW + W^2 < 0 or (L - W)^2 < 0 which is never true.

But have you looked at the subcircuit model for the taps?

Yes, I did see the ngspice subcircuit model for the taps. I may be wrong, but I don't think the intention was to have an accurate resistance for simulation. I think the intention was to have an LVS verifiable tap shape (L and W).
@sergeiandreyev is that assumption correct?

I apologize if I'm assuming or suggesting too much.

[mole99]

Just checking in on what's the status of merging this PR?
The updates to the magic tech file would be important for LibreLane.

[sergeiandreyev]

Hi @KrzysztofHerman, could you please take care?

[mole99]

Hi @KrzysztofHerman, it would be great if this could be merged.

It's blocking librelane/librelane#832 and librelane/librelane#837.