google / globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0 Goto Github PK
View Code? Open in Web Editor NEW7 track standard cells for GF180MCU provided by GlobalFoundries.
Home Page: https://gf180mcu-pdk.rtfd.io
License: Apache License 2.0
7 track standard cells for GF180MCU provided by GlobalFoundries.
Home Page: https://gf180mcu-pdk.rtfd.io
License: Apache License 2.0
All standard cells pass DRC
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)
gf180mcu_fd_sc_mcu7t5v0_mux2_1
(I think it isn't used by synthesis automatically)gf180mcu_fd_sc_mcu7t5v0_mux2_1
to find it is the culpritopen_pdks 120b0bd69c745825a0b8b76f364043a1cd08bb6a
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
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!).
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.
A change has to be merged and then a dependabot pull request updates the gf180mcu-pdk repository which shows the changes.
Similar to google/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu9t5v0#14
Matching metal layer names between tech lef and cells lef
Miss-match in metal layer names (METAL1 vs Metal1)
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.
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
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#16
SITE definition for GF018hv5v_mcu_sc7
in the tech lefs
No SITE definition
No Via resistance in tech lef
Via resistance in tech lef
The fill schematic is rendered correctly or manually overridden to make sense.
Fill appears to be rendered as some giant line?
liberty be read by yosys
yosys rejects the liberty. see The-OpenROAD-Project/OpenLane#1535.
simply attempt to read any liberty with yosys
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.