Similar to google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu9t5v0#16

Expected Behavior

SITE definition for GF018hv5v_mcu_sc7 in the tech lefs

Actual Behavior

No SITE definition

Steps to Reproduce the Problem

Specifications

• Version:
• Platform:

The technology LEF files (for both standard cell libraries) all have the same value for CPERSQDIST for all metal layers. Cross-checked against a commercial tool, it was found that the given value is not equal to the actual CPERSQDIST for any metal layer (in fact, it is off by a factor of about 10x for metal 3).

The correct value needs to be determined for every metal layer.

Currently, min and max corners are being generated by open_pdks by substitution on the tech lef in the repository, which is assumed to be nominal. But at least the correct nominal corner values need to be present in the respository.

Expected Behavior

No Via resistance in tech lef

Actual Behavior

Via resistance in tech lef

Steps to Reproduce the Problem

Specifications

• Version:
• Platform:

Expected Behavior

All standard cells pass DRC

Actual Behavior

gf180mcu_fd_sc_mcu7t5v0_mux2_1 fails DRC with 2 of the following errors

Metal1 overlap of contact < 0.055um in one direction (CO.6)

Steps to Reproduce the Problem

1. Build a design that instantiates gf180mcu_fd_sc_mcu7t5v0_mux2_1 (I think it isn't used by synthesis automatically)
2. Observe DRC failures in Magic
3. Load the gf180mcu_fd_sc_mcu7t5v0_mux2_1 to find it is the culprit

Specifications

• Version: open_pdks 120b0bd69c745825a0b8b76f364043a1cd08bb6a
• Platform: Arch Linux

Actual Behavior

Currently most of the buffers are getting rendered as an empty line as below;

Expected Behavior

The buffer should be rendered more like this inverter;

Each of the standard cells should have a definition.json file similar to the skywater-pdk. See example at https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/blob/ac7fb61f06e6470b94e8afdf7c25268f62fbd7b1/cells/a2111o/definition.json

Expected Behavior

liberty be read by yosys

Actual Behavior

yosys rejects the liberty. see The-OpenROAD-Project/OpenLane#1535.

Steps to Reproduce the Problem

simply attempt to read any liberty with yosys

Specifications

• Version:
• Platform:

Further information:

I tracked down the problem to what yosys perceives as a syntax error:

        clear : !RN ;

Yosys is rejecting !RN as it is not wrapped in quotations. Usage of !RN in the liberty file in most places is wrapped with quotations. So it is logical to assume that having "!RN" instead of !RN is legal syntax. I also found *a reference* which states that *some* attributes must be wrapped in quotes.

Expected Behavior

Flip flop schematic rendering should look more like this;

This is likely because Yosys can't pull part or otherwise understand the UDP (user defined primitive) is actually a flip flop.

Actual Behavior

Flip flop schematic rendering looks like this;

Expected Behavior

The fill schematic is rendered correctly or manually overridden to make sense.

Actual Behavior

Fill appears to be rendered as some giant line?

https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/blob/69e8c5b9c2e105a46b78bed8b2236947ee30e338/cells/fill/gf180mcu_fd_sc_mcu7t5v0__fill.schematic.svg

See https://raw.githubusercontent.com/google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/69e8c5b9c2e105a46b78bed8b2236947ee30e338/cells/fill/gf180mcu_fd_sc_mcu7t5v0__fill.schematic.svg

If the intent was to follow the standard used by the sky130 PDK, then this is an epic fail. It needs correcting on multiple fronts.

For starters, the standard cell verilog modules make references to modules with a _func suffix but do not define such modules anywhere.

Unlike the sky130 PDK, the modules are not broken up into base modules (functional and behavioral) plus a single module for each gate strength variant that calls the base modules based on #ifdef blocks for FUNCTIONAL, BEHAVIORAL, and USE_POWER_PINS. The functional module is identical (and therefore redundant) for every gate strength. The functional modules are only unique between strength variants because the wires have been unnecessarily renamed to add the entire verilog module name as a prefix.

Each module does not have a surrounding #ifdef to prevent it from being defined multiple times if included multiple times.

There is an #ifdef FUNCTIONAL inside the behavioral verilog module (and not in the functional verilog module!).

Expected Behavior

Sending a pull request on this repository shows how it will affect the documentation around the standard cells found at https://gf180mcu-pdk.rtfd.io

This could be done by setting up a conf.py and Makefile under the docs directory with similar config as the gf180mcu-pdk repository but just including the standard cells library section of the documentation.

Another option would be to automatically send a pull request to gf180mcu-pdk repository with the submodule updated and copying the details into the pull request here.

Actual Behavior

A change has to be merged and then a dependabot pull request updates the gf180mcu-pdk repository which shows the changes.

CI on this repository should verify that the standard cells pass the GF180MCU DRC rules.

Example GitHub Action at https://github.com/google/skywater-pdk-actions/tree/main/run-drc-for-cell-gds-using-magic

The .spice netlist seems to contain a lot of gibberish. It turns out that the standard cells of gf180 contains a lot of extra labels, which is wrongfully extracted as pin labels.

Each of the standard cell should have a Verilog test bench which tests the functionality.

Similar to google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu9t5v0#14

Expected Behavior

Matching metal layer names between tech lef and cells lef

Actual Behavior

Miss-match in metal layer names (METAL1 vs Metal1)

Steps to Reproduce the Problem

Specifications

• Version:
• Platform: