DRC extension for voltage dependent rules

Hi,
I'm looking for a possibility to utilize design rules which are sensitive to the voltage levels on the checked net. Before I'm working my way down I would ask if someone had already thought about or know a way to solve such requirements.

may first thought would include following steps:

  • layout nets can be identified by labels
  • additional labels (on same layer but different purpose) with Vmin/Vmax strings (usually these are floating numbers) can be attached to the net
  • a property on each shape of a net according to the Vmin/Vmax values need to be added
  • during DRC the properties can be used to apply different rules

That is a very hypothetical approach since my klayout API knowledge is quite limited. But hopefully someone points me into the right direction.

thanks in advance

Comments

  • In my (industrial) experience the voltage rating
    runs with the device design specifics and the
    unique device master should point to the rule.
    The "vanilla CMOS" flows that have come out
    for OSEDA tend to not exercise this (even old
    MOSIS AMI, they curtailed the device set to
    only the 5V CMOS). So you may not find a lot
    of examples. But my take is, at some point you
    will need to wither "tag" or logically recognize
    "which?" device, and then have sections in the
    DRC deck that logically only check the device
    master / type in question.

    Telling N from P is easy. Telling a 40V LDMOS
    from a 20V LDMOS would want either identification
    -and measurement-, presence of a tag-layer or
    tag-text that the deck will use to steer what
    "device specific" construction rules there may be.

    Now the other part, that DRC should know specific
    nets' voltage (and now do you care about duty
    cycle, current, frequency - reliability impactors all,
    potentially?) is much more "iffy".

    You could consider using net layers / datatypes
    to impose requirements on a wire and adjacent
    features (used to see VDDMET1, HVMET1, etc.
    which will get Booleaned into a single metal and
    could have both intra-layer checks (like space-to
    for voltage) and inter-layer (like HVMET1 cannot
    cross lightly doped resistors).

    But pushing SPICE results onto schematic nets
    seems messy and you have to wonder whether
    a given simulation has exercised every net that
    -could- develop high voltage under some set of
    circumstances, did so for every one. And what
    net-net voltage -differences-, rather than single
    ended voltage-to-gnd! as SPICE would deliver?

    Foundries do not want to go that deep, you pick
    a device that's all-terminals-voltage-capable to
    what you understand about its application, and
    then you own it. I have never encountered a DRC
    or LVS that is "parametric" with detailed device
    terminal voltages or net voltages. Maybe I just
    haven't gotten to work on stuff where that kind
    of thing is the "done thing". Or maybe it just isn't
    and no way to know, other than "dead air".

  • Thank you very much for your very detailed answer. I completely agree with your views on all points. I also believe that there are not many engineers in the field of analog HV design, which makes it less likely that such techniques will be supported by OSEDA. On the other hand, I would like to take this into my own hands, simply because there are these extended DRC rules from the fab and the fab itself only offers, in my opinion, inadequate tools.

    For example, the “tagging” you mentioned. However, the main problem is that you can only use this in very specific cases and if there are several voltage domains, you would have to extend the tagging to sub-blocks (standard cells, etc.), which is practically impossible. Large EDA manufacturers offer a flow that is intended to enable sign-off checks with voltage labels. For whatever reason, some fabs do not want to support this. If you then have to tinker with DRC rules yourself, you can just as well do it directly with OSEDA ... I personally find it much better anyway.

    The question of how to store voltage information in the layout is very interesting.You can of course do this manually or directly with simulation data (this is the voltage dependent flow mentioned above). This is at least possible with the commercial EDA software. However, it is then also up to the user how well these Vmin/Vmax voltages are mapped. In any case, the risk of forgetting something in extensive designs is lower.

    If I wanted to use the process mentioned in my question, I think I could somehow manage the first 3 points by myself. For the 4th point (“apply DRC rules depending on properties”) I don't know if this would be possible. A KLayout expert would have to help me.

    But perhaps there are completely different ideas on how to solve such a problem much more easily.

  • Hello acs

    That's interesting, maybe you have simple & concrete example to show what you want.
    I had split label and tried to do something by using a Ruby or Python script, before ( in different field )
    But the efficiency will be lower than DRC module.

    Vincent

  • I think there's a lot of opportunity to add a "meta"
    layer using the properties but that seems like it
    needs a lot of thought and definition, and risks
    to back-compatibility to lesser GDS editors might
    be lost?

    However if the meta "layer" is (re)generatable from
    plain layout data just like in Brand X, "extraction"
    precedes LVS, maybe the latter concern goes away
    and we'd have the "hooks" to push (say) simulation
    results back onto layout. "Pre-architecture", many
    things are possible (in theory).

  • Dear all,

    thanks for this discussion.

    Actually KLayout has support for net classes, because you can form nets and filter names by glob pattern. So here is a solution if you name your HV nets like "...!HV". This sample is assume three layers L1, L2 and L3, corresponding to metal1, via, metal2.

    It checks three rules on L1:

    1. The space between shapes on different HV nets must be >= 1µm
    2. The space between HV net shapes and other L1 shapes must be >= 600nm
    3. The space between all L1 shapes must be >= 300nm

    Here is the DRC script:

    report("Discussion 2608")
    
    l1 = input(1, 0)
    l2 = input(2, 0)
    l3 = input(3, 0)
    
    # form connections
    # NOTE: call "clear_connections" to restart
    connect(l1, l2)
    connect(l2, l3)
    
    l1_hv = l1.nets("*!HV")
    l1_other = l1 - l1_hv
    
    # HV vs. HV, different nets
    # NOTE: "props_ne" checks shapes from different nets only
    l1_hv.space(props_ne, 1.um).output("Space between different HV < 1µm")
    
    # HV vs. LV
    l1_hv.sep(l1_other, 600.nm).output("Space between HV nets and other nets < 600nm")
    
    # Lithography limit
    l1.space(300.nm).output("Space < 300nm")
    

    And some sample results:

    Rule 1:

    Rule 2:

    Rule 3:

    Matthias

  • Hello Matthias

    wow.. never thought it could be done this way.
    BTW, it should be supported on version 0.29 or more latest.

    Vincent

  • Very interesting. So now I must ask another question -
    is it possible to use the same scheme (!blahblah append)
    to somehow "tag" a device by its name (recent discussion)
    or any concerns with it?

    and another, can !blahblah and !anotherthing be
    concatenated (maybe there's two concerns) for nets?
    Like maybe there's voltage spacing and there's
    crosstalk spacing, and the greater of the invoked
    should apply?

  • acsacs
    edited October 26

    Thank you Matthias, this looks great!
    I think it corresponds exactly to the "tag" based approaches of the industry and could therefore be described as state-of-the-art (please take this as a compliment).
    Unfortunately, the disadvantage is that you would have to label every network accordingly. In the sketch, all nets would have to be changed in X1 if VDDHV!HV were used. This is not possible with standard cells. At least with simulation-based methods, all nets can be labeled automatically and you could then query them.
    So, like @dick_freebird , I wonder whether it is possible to simply extend the global pattern expression. Probably a slightly more advanced filter with simple query options would go in the right direction?

  • edited October 26

    I don't know if that helps, but the net names are taken from the topmost level in the hierarchy. The names from the lower levels are ignored. The reality is slightly more complex, but that is the basic idea. Nets are considered "full" always - not separated into subnets.

    So if you label the net with "...!HV" on the top level in one case and without in the other, the net inside the sub circuit will become a HV net once and a LV net for the other instance.

    Plus, as the net filters are basically only glob expressions, multi-tagging is possible if you stick to certain labeling rules - for example "!HV" will match on "net1!HV!PWR" as well as "net2!HV" and "!PWR" will select power "net1!HV!PWR" only.

    Matthias

  • The other way I have seen (may have mentioned) is to proliferate in-layer "purposes" and enforce a discipline that can be "codified" in DRC and LVS.

    For example Met3 (33,0) might be attended by M3VDDA, M3VDDA, M3PGND, M3HV... all roll up to mask fab 33/0 by some Boolean tapeout deck, but until then you can do what you like for fine detail verification based on net purposes.

    Of course some "fineness" might be overkill and you just "live in the box, for that".
Sign In or Register to comment.