feat: add IHP, SKY130, and GF180 PDK support

[setup99]

1. Changes in pdk.py (The Library & File Mapping) :

For every PDK, I added a dedicated PDK_...() function that acts as a dictionary of the factory's "parts list."

** Specific Cell Names: I mapped the unique naming conventions of each factory so the compiler knows which "brick" to pick:

• IHP: Uses sg13g2_ prefix (e.g., sg13g2_filltap).

• SkyWater: Uses sky130_fd_sc_hd__ prefix (e.g., sky130_fd_sc_hd__fill_1).

• GlobalFoundries: Uses gf180mcu_fd_sc_mcu7t5v0__ prefix.

** File Path Resolution: Added logic to find the three critical files required for every chip:

• Tech LEF: The "Rulebook" for the metal layers.

• StdCell LEF: The "Shapes" of the transistors.

• Liberty (.lib): The "Timing" (how fast the signals move).

2. Changes in parameters.py (The Geometric Blueprint) :

For every PDK, I created a _PARAMETERS_TEMPLATE that defines the "rules of the road" for drawing the chip.

**Track Pitches (The Grid): I extracted the exact spacing for the metal wires from the foundry technology files:

   * IHP: 420nm / 480nm tracks.

   * SKY130: 340nm / 460nm tracks.

   * GF180: 480nm / 560nm tracks.

   * This prevents "Design Rule Violations" (DRVs) where wires are too close together.

** Power Delivery Network (PDN): We added a professional power grid for every PDK:

   * Net Names: Standardized VDD/VSS for most, and VPWR/VGND specifically for SkyWater.

   * Power Stripes: Defined which heavy metal layers (usually Metal4 and Metal5) carry the main electricity across the chip.

** Layer Constraints:

   * Set the Bottom and Top routing layers (e.g., allowing routing only from Metal2 to Metal5 for IHP to save the bottom layer for cells).

** Utilization & Margins: Set safe default "density" levels (e.g., 65% for IHP, 40% for SkyWater) so the chips aren't too crowded to wire.

[Emin017]

@setup99 Could you rebase the code? This PR has some conflicts with #53.

[setup99]

Hello, I've solved the problem and I really hope your project includes all Open source pdks . and I've been following you for a while now. I think your project will be revolutionary in this field, wish you all the best.

[Emin017]

Please also add at least one test for the newly introduced PDKs in this PR to ensure that their integration works correctly and does not introduce functional issues.

[Emin017]

Will this LEF cause issues when using other PDKs?

[Emin017]

Please do not add extra spaces

[Emin017]

Please also rebase this branch, so we can trigger the ci check.

[Emin017]

Suggested change

	tech_path = "{}/prtech/techLEF/N551P6M.lef".format(resolved_root)
	tech_path = "{}/prtech/techLEF/N551P6M_ecos.lef".format(resolved_root)

[Emin017]

Suggested change

	tech_path = root / "prtech" / "techLEF" / "N551P6M.lef"
	tech_path = root / "prtech" / "techLEF" / "N551P6M_ecos.lef"

[Emin017]

Suggested change

[Emin017]

We may also need to add some pdk initialize step in ci configuration.

[Emin017]

You can use git amend and force push when you don't know what to write commit msg or the content is duplicated :)

[setup99]

@Emin017 Fair point 😄. In this case, though, I wasn't sure whether the issue was caused by my changes or by an existing problem. I'm still investigating it—the test_ics55_gcd test reaches the CTS stage, where a native dependency aborts the process and causes the GitHub Actions run to fail with exit code 134. Once I understand the root cause, I'll clean up the commits if needed.