Public

Thread: bent gates

20 Discord messages from ℹ️ - Information/general/threads/bent-gates.md.

Category: ℹ️ - Information Parent channel: #general Thread ID: 1525554170323669053

Messages: 20

message-1525554176711459058

2026-07-11T17:27:39.154+00:00 — namibj

Content

Well, so, let's start off with a "mild" complaint about the DRC deck, at least as far as I'd understand it to be:

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "image.png",
    "fileSizeBytes": 1890,
    "id": "1525554176342626425",
    "url": "2026-07_media/image-A7737.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1525554252871635104

2026-07-11T17:27:57.312+00:00 — namibj

Content

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "image.png",
    "fileSizeBytes": 6931,
    "id": "1525554252301340782",
    "url": "2026-07_media/image-5379B.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1525554707706281985

2026-07-11T17:29:45.753+00:00 — namibj

Content

to be clear, the step is 5nm and the sections are 0.32 um and 0.325 um.

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "image.png",
    "fileSizeBytes": 2020,
    "id": "1525554706972282900",
    "url": "2026-07_media/image-E2419.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1525583061180219605

2026-07-11T19:22:25.748+00:00 — tnt (@246tnt)

Content

Channel width is the other direction.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1525583453649895496

2026-07-11T19:23:59.32+00:00 — tnt (@246tnt)

Content

Not that it justifies an error...
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1525588708907290664

2026-07-11T19:44:52.271+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1525554170323669053",
  "guildId": "1361349522684510449",
  "messageId": "1525583061180219605"
}
</details>

Content

Width is measured along the edge of "poly on comp"; length is measured normal to that edge.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
        "color": null,
        "discriminator": "0000",
        "id": "596068704471482370",
        "isBot": false,
        "name": "246tnt",
        "nickname": "tnt",
        "roles": []
      }
    ]
  }
}
</details>

message-1525589682887331920

2026-07-11T19:48:44.486+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1525554170323669053",
  "guildId": "1361349522684510449",
  "messageId": "1525583453649895496"
}
</details>

Content

Yeah, I'm hoping to at least lay down a couple calibration gates to allow calibrating magic extraction and SPICE models for bent gates at least a week ahead of Run3's GDS deadline.

Would be bad to have the DRC deck break that.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
        "color": null,
        "discriminator": "0000",
        "id": "596068704471482370",
        "isBot": false,
        "name": "246tnt",
        "nickname": "tnt",
        "roles": []
      }
    ]
  }
}
</details>

message-1525590856047005728

2026-07-11T19:53:24.189+00:00 — namibj

Content

Might as well post the writeup I did on one use case where bends would/might come up:

https://www.tumblr.com/namibj/821872240790503424/rotationally-symmetric-pseudo-nmos-multiplexers

Embeds

<details> <summary>Embeds data</summary>
[
  {
    "author": {
      "iconUrl": "2026-07_media/cone_open_512-29908.png",
      "name": "Untitled",
      "url": "https://www.tumblr.com/blog/view/namibj"
    },
    "color": "#001935",
    "description": "There are two main variants relevant in common bulk\\-CMOS processes\\:\nthe 4\\:1 MUX, and the 8\\:1 MUX\\.\n\nI have a corner\\-pair \\(double\\-segment\\) of the 8\\:1  MUX drawn in KLayout for gf180mcuD, mostly as a POC and somewhat nicer visualization of the structure involved\\. Notably, I hven't dialed in the DRC\\-compliant _Nplus_​ implant for it, but that will pretty much just follow the _COMP_​ geometry; possibly pushing the active channel away from the 8 corners to meet minimum spacing where it runs into the channel; more on that later\\.\n\nI will also share a hand\\-drawn illustration of the 4\\:1 MUX, primarily for completeness though\\.\n\n## Octagonal corner \\(the diagonal segment is the most complete; the vertical segment notably misses it's data line, and the horizontal segment skipped drawing how it's bottom\\-most gate will join up to the contact it shares with the other \\(not\\-drawn\\) diagonal segment it will be adjacent to\\)\\:...",
    "fields": [],
    "footer": {
      "iconUrl": "2026-07_media/apple-touch-icon-f8ea2554-E4BD6.png",
      "text": "Tumblr"
    },
    "image": {
      "height": 1494,
      "url": "2026-07_media/357b3834e135a63585d4e5903f27478f73169dab-F209F.png",
      "width": 1903
    },
    "images": [
      {
        "height": 1494,
        "url": "2026-07_media/357b3834e135a63585d4e5903f27478f73169dab-F209F.png",
        "width": 1903
      }
    ],
    "inlineEmojis": [],
    "timestamp": "2026-07-11T19:34:07+00:00",
    "title": "Rotationally symmetric pseudo-NMOS multiplexers, part1: Overview",
    "url": "https://www.tumblr.com/namibj/821872240790503424/rotationally-symmetric-pseudo-nmos-multiplexers"
  },
  {
    "description": "",
    "fields": [],
    "image": {
      "height": 3072,
      "url": "2026-07_media/657a69a4806ab42974e4caaba30d8143be980d7e-1D48C.png",
      "width": 1164
    },
    "images": [
      {
        "height": 3072,
        "url": "2026-07_media/657a69a4806ab42974e4caaba30d8143be980d7e-1D48C.png",
        "width": 1164
      }
    ],
    "inlineEmojis": [],
    "timestamp": null,
    "title": "",
    "url": "https://www.tumblr.com/namibj/821872240790503424/rotationally-symmetric-pseudo-nmos-multiplexers"
  },
  {
    "description": "",
    "fields": [],
    "image": {
      "height": 1650,
      "url": "2026-07_media/2a8a13b389d6b23e2460c07fae6dad3075b27815-7B611.png",
      "width": 1758
    },
    "images": [
      {
        "height": 1650,
        "url": "2026-07_media/2a8a13b389d6b23e2460c07fae6dad3075b27815-7B611.png",
        "width": 1758
      }
    ],
    "inlineEmojis": [],
    "timestamp": null,
    "title": "",
    "url": "https://www.tumblr.com/namibj/821872240790503424/rotationally-symmetric-pseudo-nmos-multiplexers"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1525593418410102945

2026-07-11T20:03:35.104+00:00 — tnt (@246tnt)

Content

0.22 um min channel width is the minimal width of the diffusion for a transistor. i.e. the "W" of the transistor.
the measurement you took correspond to the length L of the transistor and the min for that is 0.28um.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1525614318924595231

2026-07-11T21:26:38.175+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1525554170323669053",
  "guildId": "1361349522684510449",
  "messageId": "1525593418410102945"
}
</details>

Content

Oh that yeah; I meant the DRC highlight in bright yellow that was complained about being not wide enough.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/88d17af9d19ab43565b0c46751ef7d12-DFEE5.png",
        "color": null,
        "discriminator": "0000",
        "id": "596068704471482370",
        "isBot": false,
        "name": "246tnt",
        "nickname": "tnt",
        "roles": []
      }
    ]
  }
}
</details>

message-1526065582766817361

2026-07-13T03:19:47.859+00:00 — namibj

Content

@Tim Edwards Does this (m1 hidden) look like it should work effectively for calibrating how channel width is to be measured most accurately for extraction to work properly?
I'd look forward to extending it by one or 2 contact pitches into an elongated shape to have a convenient linear shaped one for reference/calibrating against.

This is specifically to check your way of calculating the BSIM4 instance parameters from the geometry.

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "image.png",
    "fileSizeBytes": 10998,
    "id": "1526065582196396172",
    "url": "2026-07_media/image-34E9C.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
        "color": null,
        "discriminator": "0000",
        "id": "1365118310701600900",
        "isBot": false,
        "name": "rtimothyedwards_19428",
        "nickname": "Tim Edwards",
        "roles": []
      }
    ]
  }
}
</details>

message-1526212919631810591

2026-07-13T13:05:15.705+00:00 — Tim Edwards (@rtimothyedwards_19428)

Content

@namibj :  I did a set of annular/enclosed drain devices for GF180MCU last week, and these all appear to be DRC clean.  I will post the layout and netlist.  Only device type "E" is extracted incorrectly, and that's because without the source terminals connected, it is effectively a 5-terminal device and the tech file does not describe how to extract a 5-terminal device (even when I connect the sides, the extracted width is lower than I would expect).

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "annular_fet_types.png",
    "fileSizeBytes": 20704,
    "id": "1526212919241736312",
    "url": "2026-07_media/annular_fet_types-06F50.png"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
        "color": null,
        "discriminator": "0000",
        "id": "262706220073222144",
        "isBot": false,
        "name": "namibj",
        "nickname": "namibj",
        "roles": []
      }
    ]
  }
}
</details>

message-1526213159956775015

2026-07-13T13:06:13.003+00:00 — Tim Edwards (@rtimothyedwards_19428)

Content

These are the layout and netlist files.

Attachments

<details> <summary>Attachments data</summary>
[
  {
    "fileName": "annular_fet_potpourri.mag",
    "fileSizeBytes": 1217,
    "id": "1526213159159988356",
    "url": "2026-07_media/annular_fet_potpourri-18A02.mag"
  },
  {
    "fileName": "annular_fet_potpourri.spice",
    "fileSizeBytes": 1220,
    "id": "1526213159898058772",
    "url": "2026-07_media/annular_fet_potpourri-7ACC4.spice"
  }
]
</details><details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1526213952730693782

2026-07-13T13:09:22.015+00:00 — Tim Edwards (@rtimothyedwards_19428)

Content

When I run extraction, I am getting an error that I expect is related to some development work I did a few months ago;  that development work resulted in much better estimates of width for these type of transistors.  But it appears that magic is having problems with an angled edge at one specific orientation, which might make the width calculations slightly off.  I will investigate this.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1526215506602889276

2026-07-13T13:15:32.487+00:00 — Tim Edwards (@rtimothyedwards_19428)

Content

Note that there are various methods for calculating effective width of an annular or enclosed-drain device.  Ultimately there is no real exact answer;  to reproduce the exact device characteristics in simulation would require a dedicated model.  Trying to force it into a model for a rectangular device can only be an approximation.  My approach (which is similar to others' approaches if not exact in detail) is to use the minimum length as the length of the transistor, then find all other parts of the geometry and measure the (W / L) and then scale those to the minimum length.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1526238568308146227

2026-07-13T14:47:10.826+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1525554170323669053",
  "guildId": "1361349522684510449",
  "messageId": "1526215506602889276"
}
</details>

Content

Oh I'm not at all against calibrating a derivative/sibling of the `level=54` BSIM4 model adapted specifically to appropriately handle the bends (for larger devices)/true-annular-aspects (for [near-]minimum-size devices).
I'd just really hope to not need to do some teacher forcing transfer learning thing of using a less-abandoned BSIM model type/`level` (that's still appropriate for the planar non-LDMOS non-parasitic mosfets the gf180mcuD process can produce) who's parameters are fitted to match (up to some appropriate regularization scheme that keeps the parameters physically realistic instead of going for some pathological overfitting) the existing `level=54` models, and from where support for annual nuances would be less-nonphysical.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
        "color": null,
        "discriminator": "0000",
        "id": "1365118310701600900",
        "isBot": false,
        "name": "rtimothyedwards_19428",
        "nickname": "Tim Edwards",
        "roles": []
      }
    ]
  }
}
</details>

message-1526307279970762938

2026-07-13T19:20:12.963+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1525554170323669053",
  "guildId": "1361349522684510449",
  "messageId": "1526213952730693782"
}
</details>

Content

We have about until the test dies of Run2 get to whatever e-test "lab" goes through a stack of dies with the DC equivalent of a network analyzer (source measure unit?), because IMO we'd want to have reasonable bounds for the expected current for all the voltage combinations applied, to (1) immediately flag potential shorts/opens to not accidentally melt a hole into a test die from a badly behaved test structure, and (2) have a chance of measuring the current for _interesting_ tuples of node voltages, i.e., ones that together vaguely approximate a perfectly picked group of that-many bias points when the goal is to calibrate a new BSIM model or at least new (previously not-modeled but legal to tape out) BSIM model bins.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
        "color": null,
        "discriminator": "0000",
        "id": "1365118310701600900",
        "isBot": false,
        "name": "rtimothyedwards_19428",
        "nickname": "Tim Edwards",
        "roles": []
      }
    ]
  }
}
</details>

message-1526414261390151810

2026-07-14T02:25:19.321+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1525554170323669053",
  "guildId": "1361349522684510449",
  "messageId": "1526212919631810591"
}
</details>

Content

would you be interested in sharing a slot with various such test structures aimed at improving simulation (incl. extraction) accuracy?
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
        "color": null,
        "discriminator": "0000",
        "id": "1365118310701600900",
        "isBot": false,
        "name": "rtimothyedwards_19428",
        "nickname": "Tim Edwards",
        "roles": []
      }
    ]
  }
}
</details>

message-1526640988662137014

2026-07-14T17:26:15.315+00:00 — Tim Edwards (@rtimothyedwards_19428)

Content

Sure, I'd be happy to work on test structures.  Although if you mean for Run #2, I don't have time to work on it before the run deadline.  For Run #3, I'd be happy to collaborate on a test chip.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {}
}
</details>

message-1526653519644590211

2026-07-14T18:16:02.934+00:00 — namibj

Reply/reference

<details> <summary>Reference data</summary>
{
  "channelId": "1525554170323669053",
  "guildId": "1361349522684510449",
  "messageId": "1526640988662137014"
}
</details>

Content

Oh hmmm.

Well I can't promise I'll succeed to cook up the e-test MUX and sufficient project wrapper to pass w.s platform precheck, but if I do, I'd be happy to drop in a good couple of those.

Rough estimates suggest there'll be about 80 DUTs, though if nothing else uses the top half of the core area for other purposes, I might mirror the MUX and thus double the DUT count.
<details> <summary>Other message metadata</summary>
{
  "author": {
    "avatarUrl": "2026-07_media/f885abc0dddd0a33e4d4991b3c99091d-7ACD2.png",
    "discriminator": "0000",
    "isBot": false
  },
  "message": {
    "mentions": [
      {
        "avatarUrl": "2026-07_media/6bcc8e61db497b620550682309ace5d5-D89B4.png",
        "color": null,
        "discriminator": "0000",
        "id": "1365118310701600900",
        "isBot": false,
        "name": "rtimothyedwards_19428",
        "nickname": "Tim Edwards",
        "roles": []
      }
    ]
  }
}
</details>