Sealring Pcell dimenssion inconsistency

[PhillipRambo]

In klayout its possbile to set the length and width of the sealring arbitrarily small. This creates rather funky structures that defently arent realizable. This is shown in the attached pictures. I'm not sure if the minimum size is (50x50)u or (150x150). First picture shows structur for 50 x 50, and second picture is for 1x1.

50 x 50 micro

1 x 1 micro

[KrzysztofHerman]

The default minimum minW and minL are set to 50 um in the json file and sourced by pycell when instantiated.

        defL       = techparams['sealring_complete_defL']
        minL       = techparams['sealring_complete_minL']
        defW       = techparams['sealring_complete_defW']
        minW       = techparams['sealring_complete_minW']

Reviewing the code they are never used...

[dnltz]

I think 50x50 is far too small for any reasonable design. You don't even fit a pad inside ...

@KrzysztofHerman maybe a simple assert self.l > params['Lmin'] in setupParams would be enough to fail with too small sealrings?

[KrzysztofHerman]

@dnltz yes we need such kind of assertations. I am consulting our backend lab in order to get the information about minimal values for seal ring.

[KrzysztofHerman]

@dnltz @ThomasZecha there is a function RangeConstraint described in Python API Reference Manual 2022.06-SP2 pp. 236. It could perfectly limit the values of the parameters in the parameter window and avoid the
situation where the wrong value is set.

        specs('l', defL, 'Length(X-Axis)', RangeConstraint(150,3000))

Unfortunately I do not know how to deal with the units. I have also experimented with nmos_code.py cell trying to use this function to restrict the number of gates ng however it does not take any effect.
@ThomasZecha do we need some extensions in API to support this ?

[ThomasZecha]

RangeConstraint is already supported by the PyCell-API, see https://github.com/IHP-GmbH/IHP-Open-PDK/blob/dev/ihp-sg13g2/libs.tech/klayout/python/sg13g2_pycell_lib/ihp/npn13G2_code.py line 40.

[KrzysztofHerman]

@ThomasZecha you are right that for npn13G2_code.py it works correctly however try to modify line 51 in nmos_code.py
like this and go beyond the limits

        specs('ng',   defNG, 'Number of Gates', RangeConstraint(1, 5))

BTW the generated layout of nmos is wrong but this is another story.

[ThomasZecha]

The problem with
specs('ng', defNG, 'Number of Gates', RangeConstraint(1, 5))
is the wrong type of defNG. The type of defNG is string, which is not supported as RangeConstraint. Changing it to an integer or floating-point in the json-techfile fix it.

What's wrong with the nmos-layout?

[KrzysztofHerman]

@ThomasZecha so does it mean that this change from str->int, or in general value->numeric, implies API extension ?
As for the layout it was caused by inappropriate value of W which was calculated as nmos_defW/ng where ng=6. A good example how one can generate an invalid cell. What we need are checks (callbacks), which will verify if the parameters that one enter in the GUI are valid.

[ThomasZecha]

Yes, change from str->int, or in general value->numeric implies that the RangeConstraint will become effective in the Klayout PCell parameter value range-checking.

[sergeiandreyev]

we updated the size values, so that:
default = 400um
min = 150um

the 50x50 size is not allowed this way, but until we implement the checking in the code you will still be able to set the wrong values