Need to enable L and W parameters to Cap devices

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

  • edited June 14

    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

Sign In or Register to comment.