It looks like you're new here. If you want to get involved, click one of these buttons!
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:
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:
Here is the DRC script:
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?
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?
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
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".