DRC enforcement in PDKs

[HelgeGehring]

Would there be a way to declare minimum and maximum values in PDKs?
For example for the vias gdsfactory/components/via.py it would be nice to define in the PDK minimum and maximum widths to enforce at least some DRC rules already at the design stage.
Also it would be nice to have a way to fix certain parameters, e.g. fix the width for a certain class of vias but not the length.

Could we do this function definition in the PDK which offers a reduced set of parameters, checks the remaining parameters and returns an initialized version of the Component? Or is there a better way?

@joamatab

[joamatab]

most PDKs have a fixed via size and spacing (or gap), so they could be added as constants in PDK.constants

having a good way to capture DRC rules in a PDK would be useful, at the moment we only do that for klayout DRC generation
https://gdsfactory.github.io/gdsfactory/notebooks/_2_klayout.html#klayout-drc

[HelgeGehring]

The idea was not only about vias, just as an example where the DRC fixes only one dimension and the other one is within certain limits.
Also for the metal crosssections, the PDK might there also only define a min and max value for the width. Would be great to also catch illegal values early at the design stage

[simbilod]

That's what we do at Princeton we put rules like VIA1_MIN_SPACING and you can call it in scripts

[simbilod]

See #1391 for a way to dynamically size vias given some rules (which could be set to DRC)

[simbilod]

This only works if your foundry has minimum sizing, and not fixed sizing of course

[HelgeGehring]

Yeah, I'm mostly thinking of components which we restrict in the PDK to certain sizes - if we want to generate a vía which is too small or to large we directly get an error while designing.

I mean, if we know that there's certain limits (for visa, metal widths, ...) Why not enforce them already at the PDK level? We don't need to be able to generate a vía which is larger than possible?

[tvt173]

I think this could get to be a rat's nest though... I also like the idea of using DRC values defined as constants in the process of creating a component. We sometimes do things like this too... Then I think it is useful to have a quick way to run DRC, that can be run as a part of your PDK's tests, but I think it is better to have separation of concerns here... e.g. Verification runs separate from Layout.

That said, I think it's perfectly valid if you want to add warnings or validation like this within your PDK's implementation of its components. Components wrapped with the @cell decorator already use pydantic's validate_arguments wrapper, so you could even define constraints like this in the function signature if you wanted, like this

[joamatab]

I'll mark this as close, one can define values through PDK constants