Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Latest maintenance release
Chock full of goodness, stuff I would have wanted desperately if I was that far along in my own efforts (like the annular MOSFET gates - recently we paid a second-tier commercial CAD vendor tens of $K to implement the same thing in -one PDK's- verification decks). Much of it I had no idea was even happening until I skimmed the release notes.
Which now makes me wonder about how far behind the documentation is, relative to all this progress. Are there maybe new examples up somewhere, that were used to validate these improvements and now could serve as education?
Comments
Uh ... thanks
Well, the circular (same as annular?) gates where just a natural extension. Validation was not done with such a full layout but only with a simple device layout (sorry, no full LVS run).
The device model of a MOSFET is simply this: there is some polygon (any shape, but a single coherent area) for the source area, one for the drain area and that there is some gate region connecting both. Initially the gate had to be rectangular, so that width and length are easy to derive, but I dropped that constraint. So with an annular gate, the gate simple separates "inside" and "outside" rather than "left" and "right". The length and width are approximated by measuring the gate polygon area and perimeter (see https://github.com/KLayout/klayout/issues/462).
So the documentation is still correct. No need for special handling of such devices - it's done by the code internally.
Best regards,
Matthias
Hi, Matthias,
In our (mumblemumble) annular device PCells and extraction, we had some trouble dealing with the gate stub that projects from the core "donut". In fact we gave up on getting great accuracy and just tolerate the error for absolute width.
I have seen in the distant past, a scheme where we had added layers "width" and "length" to the layertable, and we would draw rectangles of 1um x feature length, 1um x feature width and use these in Booleans to assert, rather than calculate, such things - the "area" of the (say) NEMITTER*width -is- the width. So you can tell just how long ago that was (SDA2.0, predecessor to Cadence as an entity, but we stayed with it for its simple convenience on technologies with >1um feature sizes). These subfeatures were stretched by the PCells same as what they mark.
If it were my PDK I think I'd stilk do the same, only make the "width" nm-range and do the math to scale it. If I made the "inner" "width" a 5nm wide path at the inner periphery and the "outer" "width" path also 5nm wide, at the outer periphery (and stop at the "stub" which contributes no conduction) the "averaging" is built in if you scale by /10nm.
Just felt like sharing "how people did stuff". I recognize that many folks like the elegance of a calculated derivation, but I'm a grimy get-it-done sort who likes simplicity and visibility.
Hey, I like simplicity too
Don't overestimate my urge to innovate. When I started programming back in early 80s my favourite tool wasn't a mouse but a solder iron, and simplicity was a matter of fact, not a design concept. With a slow clock, you could literally see the bits flowing. I believe at this time it was possible for a single human brain to understand entirely - down to the physical details of the CRT tube - what's going on when you played Space Invaders (for example). I doubt this is possible today. The capacity of a single human brain simply isn't sufficient to learn every detail of what really happens when you play Call of Duty on your phone (just to pick an equivalent example). Not to speak of the things we're not supposed to know like spyware, tapped communication, hacked accounts, trojans, backdoors and other fine inventions. I'm sceptic about many of these developments. Or getting old. And I pity the young ones who need to deal with this incredible complexity.
And I also like transparency. Hence Open Source. With open source, the implementation becomes visible and transparent. For example, the transistor parameter computation is here: https://github.com/KLayout/klayout/blob/master/src/db/db/dbNetlistDeviceExtractorClasses.cc, line 171 for a symmetric 3 or 3-terminal device. I don't expect everyone to be able to review or enhance this, but at least the algorithm isn't a secret. And it should be possible to figure out it's limitations.
Matthias