<#221 Separate KLayout DRC script and XML wrapper>...
# ihp-sg13g2
g
#221 Separate KLayout DRC script and XML wrapper Issue created by mole99 Currently, the DRC scripts are implemented using a
.lydrc
file, which is an XML wrapper around the DRC script: https://github.com/IHP-GmbH/IHP-Open-PDK/tree/dev/ihp-sg13g2/libs.tech/klayout/tech/drc Instead, it would be great if the DRC script could be separated from the wrapper and simply included with
# %include
. This would make it possible to run the DRC scripts from within a Ruby or Python script. It is actually possible to run the .lydrc macro directly. An example of how this works can be found in sky130. There is one sky130A_mr.drc DRC script that is included in several
.lydrc
files: • run_drc_beol.lydrcrun_drc_feol.lydrcrun_drc_full.lydrc By setting the values of global variables, different DRC runsets can be enabled/disabled. The same approach could be used to combine the
sg13g2_maximal
and
sg13g2_minimal
DRC scripts into a single file. IHP-GmbH/IHP-Open-PDK
🙌 1
t
Yes please 😁
And as a side note, same thing for the LVS script where the whole "device" extraction part could be split so you could easily include it from custom LVS scripts (since apparently custom LVS scripts are required for a lot of real-life use cases).
k
@Andreas Krinke what do you think ?
l
@tnt, true! I haven't even had a look at LVS yet. The DRC setup from gf180mcu is also an interesting idea: https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/drc/rule_decks There, each category is in its own DRC file, so they can be included in any way you want. I don't know how efficient that is though.
a
It should be easy to separate the scripts from the wrapper XML. Although I think it should already be possible to run the lydrc files directly from Python and Ruby. Currently, you can use global variables to switch certain checks on and off. I can provide an example, if you want.
l
@Andreas Krinke You're right! I did some testing using KLayout's
Macro
class (https://www.klayout.de/doc/code/class_Macro.html) and it seems that it can execute lydrc scripts. Still, it would be useful to have macro and script separated, if only to avoid duplication of parts of the DRC script. Compared to sky130, there's one more thing I would like to see changed: Currently the DRC scripts always
source
the active layout (or a GDS file). What if there is no active layout, like in my case where I simply create a layout using
pya.Layout()
? In the case of sky130, the first argument to
source
can be specified via a global variable (https://github.com/efabless/sky130_klayout_pdk/blob/68b8aa87c129191f642da662d348e9ca6930581b/tech/sky130/drc/sky130A_mr.drc#L49C9-L49C14). This makes it possible to create a layout and run DRC in batch mode without ever writing to disk. It would be great if this could be done for ihp in the same way.
a
I agree, this sounds like a good idea! I will take a look.
👍 1
t
On the LVS side it looks like there is both a macro and split files ... but then the macro doesn't use the split files, it repeats them leading to duplication of most of the LVS extraction stuff. So definitely avoid that for DRC 😅
a
Yes, thanks for the heads up. For the DRC, the minimal and maximal scripts are generated and only contain the relevant layers. So I have to think about the best way to avoid duplicating code.