It looks like you're new here. If you want to get involved, click one of these buttons!
We need to support the L and W parameter to the Cap devices just like Resistor if possible. I see this in Klayout base code:
https://github.com/KLayout/klayout/blob/a4b663199dc9115e5681f5add7f04f76022d48d8/src/db/db/dbNetlistDeviceClasses.cc#L511
Regards,
Amro
Comments
Is this an enhancement request? There is the Issue tracker on GitHub for this purpose: https://github.com/KLayout/klayout/issues
As a workaround, it's basically possible to create custom device extractors using this class: https://www.klayout.de/doc-qt5/code/class_GenericDeviceExtractor.html#k_1
A sample how to use this class is here: https://github.com/KLayout/klayout/blob/1f2e59c192c41702709bf91a1f1e0d8c51cec490/testdata/lvs/res_combine3.lvs
However, you will need to reimplement the capacitors extraction logic. I assume this is somewhat tedious.
Matthias
Related question: how do you define W and L for a cap?
There is no current flow, so W does not qualify as "perpendicular to current" and L not as "length of current path". Is that rather W is the smaller side of a rectangle and L the larger one?
If you're not modeling series R then it's a "don't care".
Asking for W and L presumes a rectangular form. I
am used to seeing "free-form" capacitors in analog
IC design (older vintage) and I'd just be taking the
thin oxide * top plate polygon area for the value.
@dick_freebird thanks for this comment
Plus I really don't know how W and L are supposed defined for caps.
Matthias
You'd first need to be able to assign terminals and figure
a direction between them (L) and orthogonal (W). Same
as a thin film resistor I expect.
But capacitors I have seen (and drawn) tend to be direction
agnostic - MIM caps are nothing but plates, PCells I have
seen (in Brand X kits) can be attached from any side or corner
on either plate.
A MOS cap will more resemble a MOSFET, if it's built with
an eye to parasitics. But even this cannot be assumed a
"universal truth". You -could- (say) contact the bottom plate
on one end and not the other, of the X-axis. But your poly
plate will not normally be on the opposite, rather an adjacent end.
What I think is, maybe an example in the "build your own device
extractor" that would be built around an example that OP can
contribute.
If I imagine ways to guide the figuring of Rs (which in MOS caps
is messy, very dependent on bias as well as geometry), I think back
to older PDKs (from back when we didn't have an army of SKILL
schooled PDK developers,) where we used rectangles on
"length/drawing", "width/drawing" layers placed on
features-to-measure during PCell evaluation that scaled along
with those created features. Then extract "just took the area"
of the target-Boolean (like "LE" is area(lengthNplusPbase)
for a NPN).
So for R I'd consider something like a path from terminal to
"center of gravity" of the top plate, created somehow, and
then pull its area and scale appropriately.
But I also believe that caps are few and often uniformly
drawn (in modern CMOS mixed signal, arrays of small
uniform capacitors are normal) and there may be very little
value in automating a parasitic resistance to check against
an arbitrarily applied device property on the schematic side.
Just analyze it by hand and call it "good enough"?
Hi Jim,
thanks for these thoughts.
You're right about the MOS Caps - in that case W and L may make sense if you consider the same geometry than a MOS transistor. Maybe that is what @atork has in mind?
The devices I know are sandwich (MIM, inter-metal, poly-metal) caps which can be contacted from every side which is convenient. I also know metal finger (lateral) caps which are something that can hardly be captured by some area measurement and for which there is no out-of-the box solution.
Matthias
@Matthias I believe it should be defined by the user using layer derivations just like (x) tool. Building an entire custom device is hectic.
That leaves the question open how to define W and L in a non-ambiguous way. I have no clue. If there was a specification I could work with that. But guessing the definition is tedious trial-and-error work.
Matthias
OP mentions vaguely that there's already a method. What
attempt so far, to replicate that method in the "custom device
extractor" way?
My points have been generally, that there is not a general
agreement on even an always-rectilinear form factor, let alone
how W and L should be defined / figured.
I would suggest that OP should show the PCell and feaures
used by "Brand X" to do what's been asked (like, -are- there
"length bars" and "width bars", identification layers, or logic
that attempts to find a "thin ox center / top plate of gravity"
and "bottom plate connection point / c.o.g." (depending on
whether bottom plate is "bulk" or an isolated one)?). Bearing
in mind the developer's sensitivity to verification tool & foundry
IP, maybe you could at least provide a summary of "how it's
been done, to your satisfaction" that's actionable.
But my gut says, just do the custom-extractor work, and
donate it to the community. Nobody said it was easy. Have
not made a dent, myself. But every contrib is a learning
opportunity for us all. And maybe if you pitched in on what
you're asking for, Matthias could drop the missing clue here
and there without trying to guess what you really wanted
(if you knew what you and everybody else wanted) and how.
Then when it actually does what you want, it can be added
to the set of supported methods / devices.
Might be simpler to bifurcate, make a "MOS cap" and "MIM
cap" (and maybe some kind of custom PCell / extractor
combo for the MMM / MOM interfinger cap, where the
source C value is pased on rather than forced to figure
a 3G capacitance mesh) - OK, trifurcate. Believe that for
MIM / MOM, series R might well be trivial until you are up
in high-RF territory, and by that point you ought to be
doing your own 3D EM analysis of a built MOM cap, not
expecting a 2D connectivity tool to do it for you.
Wisely spoken!
That is basically the way I'd appreciate it. Custom devices are actually meant as a prototyping feature. It won't give you best performance, but in the end it is a way to test an idea and contribute something that is easy to integrate and optimize.
Thanks,
Matthias