Added a generator for constant bias-voltage generator.

[Sud-ana]

Added Layout for a constant bias voltage generator using two NMOS devices with same thresholds.
DRC, LVS, PEX is not setup for this instance.

[Sud-ana]

@msaligane / reviewers :
I have created a draft PR for the reference generator. Could I ask how do I select a nmos of different threshold voltage for eg. like the lvt/svt devices or otherwise as the primitive fet.py doesn't have any such argument when choosing the devices.
def nmos( pdk, width: float = 3, fingers: Optional[int] = 1, multipliers: Optional[int] = 1, with_tie: bool = True, with_dummy: Union[bool, tuple[bool, bool]] = True, with_dnwell: bool = True, with_substrate_tap: bool = True, length: Optional[float] = None, sd_route_topmet: str = "met2", gate_route_topmet: str = "met2", sd_route_left: bool = True, rmult: Optional[int] = None, sd_rmult: int=1, gate_rmult: int=1, interfinger_rmult: int=1, tie_layers: tuple[str,str] = ("met2","met1"), substrate_tap_layers: tuple[str,str] = ("met2","met1"), dummy_routes: bool=True )
Also the DRC/LVS/PEX is not done yet, so they are in draft state.

[chetanyagoyal]

@msaligane / reviewers : I have created a draft PR for the reference generator. Could I ask how do I select a nmos of different threshold voltage for eg. like the lvt/svt devices or otherwise as the primitive fet.py doesn't have any such argument when choosing the devices. def nmos( pdk, width: float = 3, fingers: Optional[int] = 1, multipliers: Optional[int] = 1, with_tie: bool = True, with_dummy: Union[bool, tuple[bool, bool]] = True, with_dnwell: bool = True, with_substrate_tap: bool = True, length: Optional[float] = None, sd_route_topmet: str = "met2", gate_route_topmet: str = "met2", sd_route_left: bool = True, rmult: Optional[int] = None, sd_rmult: int=1, gate_rmult: int=1, interfinger_rmult: int=1, tie_layers: tuple[str,str] = ("met2","met1"), substrate_tap_layers: tuple[str,str] = ("met2","met1"), dummy_routes: bool=True ) Also the DRC/LVS/PEX is not done yet, so they are in draft state.

The threshold voltage and other device specific parameters are a property of the tech file you use. You can find the various platform files available to you in common/platforms and select the one you would like to use. That part does not have to do with glayout code as it is pdk agnostic

[chetanyagoyal]

Please attach a screenshot of the klayout gds so we can how it looks, also run drc and lvs as instructed in the contributor docs

[Sud-ana]

Thanks @chetanyagoyal .
The layout from klayout gds is attached here.

.

Regarding DRC, I see an error when building with gf180 through the gf180_mapped pdk. The error is as below .
ERROR: Unable to open file: /usr/bin/miniconda3/lib/python3.10/site-packages/glayout/flow/pdk/gf180_mapped//gf180mcu_drc.lydrc (errno=2)
When I looked at the gf180mcu_drc.lydrc the file, it seems the DRC is not setup like the sky130 and is probably empty. Does it mean the drc rules are not setup for the GF180 or is the path concatenation incorrect due to which it is having a second escape / as in gf180_mapped**//**gf180mcu_drc.lydrc ?

[Sud-ana]

I tried with magic drc instead of KLayout and I have the following report with a violation for metal-2 and deep n-well. Hence the above error is a path concat error for the KLayout DRC rather than the gf180_drc file path.

`Defaulting to stale magic_commands.tcl

Magic 8.3 revision 464 - Compiled on Sat Mar 9 23:18:29 UTC 2024.
Starting magic under Tcl interpreter
Using the terminal as the console.
Using NULL graphics device.
Processing system .magicrc file
Sourcing design .magicrc for technology gf180mcuC ...
10 Magic internal units = 1 Lambda
Input style import: scaleFactor=10, multiplier=2
The following types are not handled by extraction and will be treated as non-electrical types:
obsactive mvobsactive filldiff fillpoly m1hole obsm1 fillm1 obsv1 m2hole obsm2 fillm2 obsv2 m3hole obsm3 fillm3 m4hole obsm4 fillm4 m5hole obsm5 fillm5 glass fillblock lvstext obscomment
Scaled tech values by 10 / 1 to match internal grid scaling
Loading gf180mcuC Device Generator Menu ...
Loading "/tmp/tmp5jxwt8tp/magic_commands.tcl" from command line.
Warning: Calma reading is not undoable! I hope that's OK.
Library written using GDS-II Release 6.0
Library name: library
Reading "Unnamed_8cd675c4".
Reading "Unnamed_03e7bda0".
Reading "Unnamed_1ad2f0e8".
Reading "straight_route_ffa8ab96".
Reading "c_route_28456f76".
Reading "Unnamed_b0c57e62$1".
Reading "Unnamed_b0c57e62$1".
Reading "straight_route_ffa8ab96".
Reading "c_route_28456f76".
Reading "Unnamed_03e7bda0".
Reading "Unnamed_1ad2f0e8".
[INFO]: Loading Unnamed_8cd675c4

Loading DRC CIF style.
[INFO]: DONE with /tmp/tmp5jxwt8tp/Unnamed_8cd675c4.rpt

Using technology "gf180mcuC", version 1.0.471-1-gd8bfd6f

Soft errors:
Error while reading cell "Unnamed_8cd675c4" (byte position 378): Cell "Unnamed_b0c57e62$1" was already defined in this file.
Error while reading cell "Unnamed_8cd675c4" (byte position 378): Ignoring duplicate definition
Error while reading cell "Unnamed_8cd675c4" (byte position 35750): Cell "straight_route_ffa8ab96" was already defined in this file.
Error while reading cell "Unnamed_8cd675c4" (byte position 35750): Ignoring duplicate definition
Error while reading cell "Unnamed_8cd675c4" (byte position 35866): Cell "c_route_28456f76" was already defined in this file.
Error while reading cell "Unnamed_8cd675c4" (byte position 35866): Ignoring duplicate definition
Error while reading cell "Unnamed_8cd675c4" (byte position 36622): Cell "Unnamed_03e7bda0" was already defined in this file.
Error while reading cell "Unnamed_8cd675c4" (byte position 36622): Ignoring duplicate definition
Error while reading cell "Unnamed_8cd675c4" (byte position 58354): Cell "Unnamed_1ad2f0e8" was already defined in this file.
Error while reading cell "Unnamed_8cd675c4" (byte position 58354): Ignoring duplicate definition

Unnamed_8cd675c4 count:

---

Metal2 spacing < 0.28um (M2.2a)

---

-15.760um 1.495um -15.260um 1.525um

-14.900um 1.495um -14.120um 1.525um

-0.820um 1.495um -0.320um 1.525um

-15.260um 1.495um -14.980um 1.525um

-0.320um 1.495um -0.040um 1.525um

0.040um 1.495um 0.820um 1.525um

---

Deep N-well spacing < 2.5um (DN.2a)

---

-7.320um -6.395um -5.120um 0.000um

-7.320um 0.000um -5.120um 6.395um

---

DRC is clean: {'result_str': 'magic drc script passed\nErrors found in DRC report', 'subproc_code': 0}
`

[chetanyagoyal]

I tried with magic drc instead of KLayout and I have the following report with a violation for metal-2 and deep n-well. Hence the above error is a path concat error for the KLayout DRC rather than the gf180_drc file path.

`Defaulting to stale magic_commands.tcl

Magic 8.3 revision 464 - Compiled on Sat Mar 9 23:18:29 UTC 2024. Starting magic under Tcl interpreter Using the terminal as the console. Using NULL graphics device. Processing system .magicrc file Sourcing design .magicrc for technology gf180mcuC ... 10 Magic internal units = 1 Lambda Input style import: scaleFactor=10, multiplier=2 The following types are not handled by extraction and will be treated as non-electrical types: obsactive mvobsactive filldiff fillpoly m1hole obsm1 fillm1 obsv1 m2hole obsm2 fillm2 obsv2 m3hole obsm3 fillm3 m4hole obsm4 fillm4 m5hole obsm5 fillm5 glass fillblock lvstext obscomment Scaled tech values by 10 / 1 to match internal grid scaling Loading gf180mcuC Device Generator Menu ... Loading "/tmp/tmp5jxwt8tp/magic_commands.tcl" from command line. Warning: Calma reading is not undoable! I hope that's OK. Library written using GDS-II Release 6.0 Library name: library Reading "Unnamed_8cd675c4". Reading "Unnamed_03e7bda0". Reading "Unnamed_1ad2f0e8". Reading "straight_route_ffa8ab96". Reading "c_route_28456f76". Reading "Unnamed_b0c57e62$1". Reading "Unnamed_b0c57e62$1". Reading "straight_route_ffa8ab96". Reading "c_route_28456f76". Reading "Unnamed_03e7bda0". Reading "Unnamed_1ad2f0e8". [INFO]: Loading Unnamed_8cd675c4

Loading DRC CIF style. [INFO]: DONE with /tmp/tmp5jxwt8tp/Unnamed_8cd675c4.rpt

Using technology "gf180mcuC", version 1.0.471-1-gd8bfd6f

Soft errors: Error while reading cell "Unnamed_8cd675c4" (byte position 378): Cell "Unnamed_b0c57e62$1" was already defined in this file. Error while reading cell "Unnamed_8cd675c4" (byte position 378): Ignoring duplicate definition Error while reading cell "Unnamed_8cd675c4" (byte position 35750): Cell "straight_route_ffa8ab96" was already defined in this file. Error while reading cell "Unnamed_8cd675c4" (byte position 35750): Ignoring duplicate definition Error while reading cell "Unnamed_8cd675c4" (byte position 35866): Cell "c_route_28456f76" was already defined in this file. Error while reading cell "Unnamed_8cd675c4" (byte position 35866): Ignoring duplicate definition Error while reading cell "Unnamed_8cd675c4" (byte position 36622): Cell "Unnamed_03e7bda0" was already defined in this file. Error while reading cell "Unnamed_8cd675c4" (byte position 36622): Ignoring duplicate definition Error while reading cell "Unnamed_8cd675c4" (byte position 58354): Cell "Unnamed_1ad2f0e8" was already defined in this file. Error while reading cell "Unnamed_8cd675c4" (byte position 58354): Ignoring duplicate definition

Unnamed_8cd675c4 count:

Metal2 spacing < 0.28um (M2.2a)

-15.760um 1.495um -15.260um 1.525um

-14.900um 1.495um -14.120um 1.525um

-0.820um 1.495um -0.320um 1.525um

-15.260um 1.495um -14.980um 1.525um

-0.320um 1.495um -0.040um 1.525um

0.040um 1.495um 0.820um 1.525um

Deep N-well spacing < 2.5um (DN.2a)

-7.320um -6.395um -5.120um 0.000um

-7.320um 0.000um -5.120um 6.395um

DRC is clean: {'result_str': 'magic drc script passed\nErrors found in DRC report', 'subproc_code': 0} `

the deep n-well spacing issue can be fixed by manually placing one continuous deep n-well that covers both fets, rather than each fet's dnwell separately

you can see where exactly the metal spacing error is occuring by running drc in klayout

[chetanyagoyal]

Thanks @chetanyagoyal . The layout from klayout gds is attached here.

.

Regarding DRC, I see an error when building with gf180 through the gf180_mapped pdk. The error is as below . ERROR: Unable to open file: /usr/bin/miniconda3/lib/python3.10/site-packages/glayout/flow/pdk/gf180_mapped//gf180mcu_drc.lydrc (errno=2) When I looked at the gf180mcu_drc.lydrc the file, it seems the DRC is not setup like the sky130 and is probably empty. Does it mean the drc rules are not setup for the GF180 or is the path concatenation incorrect due to which it is having a second escape / as in gf180_mapped**//**gf180mcu_drc.lydrc ?

You can find the gf180mcu files in the gf180mcuC/share/pdk directory in your miniconda3 folder
from there you can manually find model files and drc scripts in the magic subfolder

[Sud-ana]

the deep n-well spacing issue can be fixed by manually placing one continuous deep n-well that covers both fets, rather than each fet's dnwell separately

Thank you for this information. I did a manual resizing to overlap the deep n-well to resolve this error.

you can see where exactly the metal spacing error is occuring by running drc in layout

Unsure about it, so will find out. From the co-ordinates of the error, it seems this error is from the Metal2 spacing from the Drain of the nmos pcell. Do I need to setup a manual DRC macro/script in Klayout GUI to locate the source of the violation or do need to use the Klayout DRC generator function {pdk}.drc(component, report_pat) as shown in the contribution document ?

[Sud-ana]

@chetanyagoyal The Metal2 spacing violation is within the nmos p-cell. Please help me understand how to confirm if these need to be less than 0.28u and be waived or need to be modified within the pcell through a separate PR.

[chetanyagoyal]

the deep n-well spacing issue can be fixed by manually placing one continuous deep n-well that covers both fets, rather than each fet's dnwell separately

Thank you for this information. I did a manual resizing to overlap the deep n-well to resolve this error.

you can see where exactly the metal spacing error is occuring by running drc in layout

Unsure about it, so will find out. From the co-ordinates of the error, it seems this error is from the Metal2 spacing from the Drain of the nmos pcell. Do I need to setup a manual DRC macro/script in Klayout GUI to locate the source of the violation or do need to use the Klayout DRC generator function {pdk}.drc(component, report_pat) as shown in the contribution document ?

If you click on the error in klayout, it should highlight the exact defaulting rectangle/section with a black box afair. You can use the default DRC script in klayout

[chetanyagoyal]

There is no point to turning on both dummies here, this doesnt contribute to the symmetricity of the design

[chetanyagoyal]

Additionally, your design is not parameterisable with transistor sizing and other properties

[Sud-ana]

Thank you @chetanyagoyal for highlighting it.
I had retained dummies to maintain good symmetry for the threshold voltages. In this case, would it be better to have dummies on far extremes i.e. east of M2 and west of M1 for the flattened component or none at all ?

Regarding parameterizing, sure this isn't. Will it be useful to bring the multiplier and fingers of the fet argument at a minimum to parameterize or will it need all the nmos arguments ?

[chetanyagoyal]

@chetanyagoyal The Metal2 spacing violation is within the nmos p-cell. Please help me understand how to confirm if these need to be less than 0.28u and be waived or need to be modified within the pcell through a separate PR.

the pcell seems to be fine, the error is from your side, possibly with the way routing or movement is done

[Sud-ana]

I've generated the cell with skywater PDK and it doesn't have any DRC errors. On running DRC, I see the result as:
{'result_str': 'magic drc script passed\nNo errors found in DRC report', 'subproc_code': 0}

[Sud-ana]

Reviewers: The constant bias voltage generator cell can't be modified further as the glayout only supports one kind of nfet/pfet but the voltage generator needs different types of fets to functionally achieve a reference voltage level.
I've used this branch to generate a Cascode which is generated for pfet/nfet type devices and runs clean .

[msaligane]

@chetanyagoyal ?

[chetanyagoyal]

@chetanyagoyal ?

I can't re-review this yet because there are quite a few changes yet to be made. @Sud-ana If you are looking for different types of FETs completely (like JFETs or even BJTs) you are correct in saying that GLayout doesn't support them. However, if you are looking for different variations of the the MOSFETs under a PDK (such as low voltage, high voltage, power fets), the GLayout API abstracts out the need for designing for different models. You are supposed to create an API agnostic pcell, which incorporates the actual pdk when the gds is written out (or netlists are extracted)

You'll find in sky130_mapped_pdk.py, a bunch of settings for the gds writer, try using that for your application.

I have also noticed that you have not yet parameterised the pcell function, please do this