Is there metal coloring support in KLayout?

Some advanced nodes have metal coloring rules. Is there support for metal coloring in Klayout? If not, is it planned to support metal coloring in the future?

Thanks.

Comments

  • I don't know what this means and I'm a semiconductor "lifer" (though never below 12nm/14nm) , so maybe explain a bit more - is this just more "purpose" sub-layers, some sort of secondary layer, or just display fill codes?

    Just because nobody's done it, doesn't mean there isn't a way to skin it - if "it" can be explained.

  • Sorry, I think multi patterning is the "right" term to use.
    https://semiengineering.com/knowledge_centers/manufacturing/patterning/double-patterning/double-patterning-methodologies/

    It's like 2 different photomasks for the same layer.

  • In that reference I see a couple of things. One is that
    a basic dual-layer patterning -can- be done the hard way
    by the designer (who should then know the algorithm, and
    presumably might be able to script some assistive tools).

    Another is that fanciest automation seems to be the
    province of the foundry support people, who are unlikely
    to be using klayout for such "golden" data validation /
    prep.

    In the middle seems to be that the layout designer draws
    something short of full detail and some automation of the
    "decomposition" helps out. This might be the messiest
    as they took two examples just to show variations.

    Certainly option #1 is doable, looks like just another
    purpose added to a layer-purpose pair. The others would
    require scripting and I'd bet that a few ingredients of the
    secret sauce are closely held foundry software / process IP.

    But in that case the foundry ought to be offering you the
    "no color" (they decomponse & verify, you send the check)
    option directly or through one of their approved EDA
    partners (none of whome want competition).

    I expect the first order of business is to determine which
    of the four or so options, applies to your present efforts.
    Then drill down into practicalities, which evidently vary.

  • This was more of a general question, but if you are looking for a first pass requirements specification. I think it would be great if we could add an optional mask/color information into the layer class (LayerInfo) so we can enable/disable color information. Defining it as an addition layer (since it is a separate datatype) is what we have been doing, but it's a little bit clunky since whether the layers matter or not depends on the foundry flow and what you want to use it for. For ex, if you want to absorb the GDS in a tool that doesn't support multiple patterning, you want to export it all as no color.

  • @dboby First, you'll need a source for that information. There is no attribute like color (either for phase shift, dual patterning, dual exposure or other reasons) in GDS and OASIS. So in these formats, color is either mapped to a layer (the usual way) or properties (I don't know of a case where this is done).

    LEF/DEF has a concept of a color attribute, but that is mapped to layers (or can be mapped to layers) on import.

    Once you have separate layers, you can simply assign them different display attributes.

    Matthias

  • Hey Matthias,
    Sorry for the late reply. Not sure if I can post the layer map information without sharing confidential information from a really big foundry I would not like to name. As you said, you can handle it as separate layers, the clunkiness comes from the whole multiple patterning thing is a manufacturing quirkiness that you don't handle while designing layouts. The methodology I have been used to with a certain tool X is to do the layouts as if the patterning didn't exist and tool X provides a toolset to automatically assign colors, (i.e separate the shapes into which ones goes to mask A and mask B for example).

    It's cool to handle it as separate layers too, and now that I think about it, it might also be possible for me to write a wrapper class around LayerInfo that defines additional properties which allow a more tool X like flow.

  • I imagine the first step is to see what the foundry would put
    out from a "colored" layout that went all the way to mask fab.
    What you find in that GDS / OASIS file ought to inform you
    of the end outcome desired, how it's represented.

    But if you wanted the coloring done by klayout*scripts, that
    might need a detailed look at the algorithms (secret sauce,
    probably, whether or not justified).

    Once you have the layers you can start looking at how and why
    "sub-colors" are made, and deduce algorithms if those are not
    going to be shared with customers.

Sign In or Register to comment.