Git Product home page Git Product logo

gf180mcu-pdk's Introduction

GlobalFoundries GF180MCU Open Source PDK

GitHub license - Apache 2.0 ReadTheDocs Badge - https://gf180mcu-pdk.rtfd.io Latest GitHub tag (including pre-releases) GitHub commits since latest release (v0.0.0)

The GF180MCU open source PDK is a collaboration between Google and GlobalFoundries to provide a fully open source process design kit (PDK) and related resources to enable the creation of designs manufacturable at GlobalFoundries's facility on their 0.18um 3.3V/6V MCU process technology.

The GF180MCU documentation can be found at <https://gf180mcu-pdk.rtfd.io>.

Google + GlobalFoundries Logo Image

Current Status -- Experimental Preview

Warning
Google and GlobalFoundries are currently treating the current content as an experimental preview / alpha release.

While the GF180MCU process node and the PDK from which this open source release was derived have been used to create many designs that have been successfully manufactured commercially in significant quantities, the open source PDK is not intended to be used for production settings at this current time. It should be usable for doing test chips and initial design verification (but this is not guaranteed).

Google, GlobalFoundries and our partners are currently doing internal validation and test designs, including silicon validation or the released data and plan to publish these results.

The PDK will be tagged with a production version when ready to do production design, see the "Versioning Information" section for a full description of the version numbering scheme.

To get notified about future new releases of the PDK, and other important news, please sign up on the gf180mcu-pdk-announce mailing list [join link].

See both the Known Issues section and the GF180MCU PDK GitHub issue list to get more detailed information around currently known issues.

Resources

The latest design resources can be viewed at the following locations:

GF180MCU Process Node

Prerequisites

At a minimum:

  • Git 2.35+
  • Python 3.6+

On Ubuntu, simply

apt install -y build-essential virtualenv python3

Building the documentation

To build documentation locally, you could use the following commands:

# Download the repository
git clone https://github.com/google/gf180mcu-pdk.git
cd gf180mcu-pdk/docs

# Create a Python virtual environment and install requirements into it.
virtualenv env --python=python3
. env/bin/activate
pip install -r requirements.txt

# Build the documentation
make html

Support

Like many open source projects there are multiple ways to get support on the GF180MCU PDK.

GlobalFoundries has created a Market Partner Ecosystem to be able to provide support from design through back end package and test. If you are interested in getting additional support through the ASIC development process, reach out to GlobalFoundries using the information in the Contacting GlobalFoundries section below.

There is also a users mailing list [join link] to allow like minded users of the PDK to provide support to each other.

Google does not provide external support for using the GlobalFoundries Open Source PDK and is distributing this repository on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the license section for the full terms.

About GlobalFoundries

GlobalFoundries is one of the world's leading semiconductor manufacturers and the only one with a truly global footprint.

GlobalFoundries is redefining innovation and semiconductor manufacturing by developing feature-rich process technology solutions that provide leadership performance in pervasive high growth markets. As a steadfast partner, with a unique mix of design, development and fabrication services, GF works collaboratively alongside our customers to bring a broad range of innovative products to market. With a global customer base, a talented and diverse workforce and an at-scale manufacturing footprint spanning three continents, GF is delivering a new era of more.

Contacting GlobalFoundries

Requests for more information about GF180MCU and other standard and customer foundry technologies can be submitted via this webform.

License

The GF180MCU PDK is released under the Apache 2.0 license.

The copyright details (which should also be found at the top of every file) are;

Copyright 2022 GlobalFoundries PDK Authors

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

gf180mcu-pdk's People

Contributors

cbalint13 avatar dependabot[bot] avatar donn avatar faragelsayed2 avatar mithro avatar mohanad0mohamed avatar proppy avatar quantamhd avatar restelli avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gf180mcu-pdk's Issues

Create corner tech lefs with updated via/layer resistances

@maliberty noticed that openrcx uses via resistances from the tech LEF. It does the same for layer resistances, even though that data is in the openrcx files. Longer term this should be addressed in openrcx, but for now this means our signoff STA isn't taking into account any variation in resistances.

@RTimothyEdwards fixed this on sky130 by creating multiple tech LEFs for each corner. We should do this for gf180 too.

Set up some type of CI for this repository

Create OpenRCX enablement

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Specifications

  • Version:
  • Platform:

PDK should have a make timing equivalent

Expected Behavior

make timing generates liberty headers and creates the liberty libraries (as it does in the sky130 open PDK)

Actual Behavior

There is no make timing, and there are no liberty file headers.

Probably it is close to sufficient to just copy the timing script from sky130 PDK and add the build recipe to the Makefile. There is probably some process-dependent stuff in the script that needs to be modified.

@mithro

Wrong commands in LEF file

Expected Behavior

The LEF files should be conforming to the fileformat specification

Actual Behavior

There are wrong commands in the LEF files:
grafik

Broken zero size schematic images

A bunch of the schematic images appear to be zero size files. They can be found with find -name *.png -empty | sort

It seems to be mostly buffers and flipflops?

./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/BUFZ_X12_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/BUFZ_X16_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/BUFZ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/BUFZ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/BUFZ_X3_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/BUFZ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/BUFZ_X8_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNRNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNRNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNRNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNRSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNRSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNRSNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFNSNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFRNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFRNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFRNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFRSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFRSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFRSNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/DFFSNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/ENDCAP_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILLCAP_X16_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILLCAP_X32_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILLCAP_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILLCAP_X64_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILLCAP_X8_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILLTIE_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILL_X16_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILL_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILL_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILL_X32_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILL_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILL_X64_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/FILL_X8_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/HOLD_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/ICGTN_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/ICGTN_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/ICGTN_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/ICGTP_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/ICGTP_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/ICGTP_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/INVZ_X12_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/INVZ_X16_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/INVZ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/INVZ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/INVZ_X3_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/INVZ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/INVZ_X8_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATRNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATRNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATRNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATRSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATRSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATRSNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/LATSNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFRNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFRNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFRNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFRSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFRSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFRSNQ_X4_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFSNQ_X1_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFSNQ_X2_sch.png
./digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/sc9_sch/SDFFSNQ_X4_sch.png

CLASS core confusion

Expected Behavior

I would expect 9t cells to have a different CLASS than 7t cells, since they have a different size and therefore need to be placed in a different grid. E.g. Sky130 is using "unithd" for the high-density cells (similar to 7t) and "unit" for the low-density cells (similar to 9t)
I am not sure, which behaviour is the best way to do it.

Actual Behavior

Both 9t cells and 7t cells are using CLASS core, which might cause confusion of cells from both libraries are used in a design.

Move the standard cell documentation into the standard cell library repositories

Resistor Model issue

Expected Behavior

ppolyf_u_2k_6p0 has a sheet resistance of 2k/square.

Actual Behavior

The resistance is much lower than this (68 ohm).
This is also true for the other ppolyf resistors. Also the modelling of the parasitic capacitance
is not compatible with ngspice.

Steps to Reproduce the Problem

* Netlist

Vin top GND 1
XR1 GND top GND ppolyf_u_2k_6p0 r_length=1e-6 r_width=1e-6 m=1

.control
op
let ires=-1*vin#branch
let res=1/ires
print res
.endc

.inc design.ngspice
.lib sm141064.ngspice res_typical

.GLOBAL GND
.end

Standard cell reference missing for DLATCH in gf180 PDK

Expected Behavior

  1. The latch cells can be found in the PDK by Yosys+ABC.
  2. The synthesis, floorplan, placement, and routing steps can be successfully completed by OpenLane with GF180 PDK.

Actual Behavior

  1. ABC can't find latch cells in GF180 PDK and you can find cells named "$DLTACH_N" in synthesis report.
  2. Floorplanning failed for module "$DLTACH_N" not found in "merged.nom.lef", and check whether EXTRA_LEFS is set appropriately.

Steps to Reproduce the Problem

  1. git clone https://github.com/0616ygh/rioschip2.git
  2. cd rioschip2
  3. source env.sh
  4. make setup
  5. cd openlane
  6. make green

Specifications

  • OpenLane Version: OpenLane daae2154590cf20e0c20b77e3fc02b6526ad09af
  • PDK Version: open_pdks 0059588eebfc704681dc2368bd1d33d96281d10f
  • Platform: Ubuntu 20.04
    a

Missing design rules?

This page should be an index of design rules:
https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07.html

The design rules are very difficult to find. They are only accessible through an expandable left menu like so:
image
There should be an entry point page that has a list of design layers so that you can click to a specific set of design rules much like the other sky130 PDK:
https://antmicro-skywater-pdk-docs.readthedocs.io/en/latest/rules.html

MOSFET Multipliers not accounted for, in SPICE Simulation

Expected Behavior

For a MOSFET, when m=2 is specified in the SPICE Netlist, the drain current in saturation must be almost twice compared to m=1
In the given SPICE netlist I(VD2) must be twice I(VD1)

Actual Behavior

I(VD2) and I(VD1) are almost the same. This means the drain current remains the same irrespective of the value of m.

Steps to Reproduce the Problem

SPICE Netlist

** sch_path: /home/nataraj/projects/designmyic/cad/gf180mcu_invoke/xschem/sch_lib/nmos_3p3_test.sch
**.subckt nmos_3p3_test
XM1 D G GND GND nmos_3p3 L=1u W=1u nf=1 ad='int((nf+1)/2) * W/nf * 0.18u' as='int((nf+2)/2) * W/nf * 0.18u' pd='2int((nf+1)/2) * (W/nf + 0.18u)' ps='2int((nf+2)/2) * (W/nf + 0.18u)' nrd='0.18u / W' nrs='0.18u / W' sa=0 sb=0 sd=0 m=1

XM2 D2 G GND GND nmos_3p3 L=1u W=1u nf=2 ad='int((nf+1)/2) * W/nf * 0.18u' as='int((nf+2)/2) * W/nf * 0.18u' pd='2int((nf+1)/2) * (W/nf + 0.18u)' ps='2int((nf+2)/2) * (W/nf + 0.18u)' nrd='0.18u / W' nrs='0.18u / W' sa=0 sb=0 sd=0 m=2

V1 G GND 2
.save i(v1)
VD1 D GND 3.3
.save i(vd1)
VD2 D2 GND 3.3
.save i(vd2)
**** begin user architecture code

.include /home/nataraj/projects/designmyic/cad/pdk/share/pdk/gf180mcuC/libs.tech/ngspice/design.spice
.lib /home/nataraj/projects/designmyic/cad/pdk/share/pdk/gf180mcuC/libs.tech/ngspice/sm141064.spice typical

.control
save all
op
print i(vd1)
print i(vd2)
.endc

**** end user architecture code
**.ends
.GLOBAL GND
.end

Specifications

  • Version: GF180MCU PDK Installed using Open PDK Version 1.0.348
  • Simulator: ngspice version 37
  • Platform: Ubuntu 22.04.5

Update the names of files under `docs/analog/model_parameters/LV/tables_clear`

The names of the files under docs/analog/model_parameters/LV/tables_clear should probably match primitive naming?

It might actually just be that the formatting of these file names need to match the other ones in this file? The files which made me think where the following;

  • docs/analog/model_parameters/LV/tables_clear/19_mos_3p3.csv
  • docs/analog/model_parameters/LV/tables_clear/21_mos_6p0.csv
  • docs/analog/model_parameters/LV/tables_clear/22_mos_6p0_1.csv
  • docs/analog/model_parameters/LV/tables_clear/21_mos_6p0_2.csv

git clone not downloading submdoules

Expected Behavior

git clone https://github.com/google/gf180mcu-pdk.git
should download all submodules automatically.

Actual Behavior

I am getting empty directory after clone gf180mcu-pdk/libraries/gf180mcu_fd_sc_mcu7t5v0/latest

Steps to Reproduce the Problem

Specifications

  • Version:
  • Platform: Centos 07

Public DRM does not render correctly, is hard to navigate

Expected Behavior

I want to discover the layout rules in human-readable form without knowing the rule numbers up front.

Actual Behavior

When I land on the readthedocs.io web page, the menu entries do not have any menus suggesting sub-entries or any depth.

image

I click through them and by sheer luck end up something that says "Design Manual", under Physical Verification. An arrow has now appeared next to that menu entry but I don't notice it at all.

image

I see in the list in the right pane 7.0 Layout Rule Description, so I click that.

I am now here. There is nothing clickable. Where do I go?

image

With the help of others I have learned that if I now expand the menu item, I can see all the relevant sub-documents. But I had to get two people to help me.

image

  • Version: Google Chrome 104.0.5112.101, 64-bit
  • Platform: Debian 11.4

"View" and "Edit" links in documentation don't work

Expected Behavior

On a page such as https://gf180mcu-pdk.readthedocs.io/en/latest/IPs/SRAM/gf180mcu_fd_ip_sram/cells/gf180mcu_fd_ip_sram__sram512x8m8wm1/gf180mcu_fd_ip_sram__sram512x8m8wm1.html there is a box in the lower-right corner that says v: latest. Clicking on this produces a window with options including View and Edit.

Presumably these links should allow one to view or edit the documentation, however they do not.

image

Actual Behavior

Clicking on the link goes to a nonexistent page. For example: https://github.com/google/gf180mcu-pdk/blob/main/docs/IPs/SRAM/gf180mcu_fd_ip_sram/cells/gf180mcu_fd_ip_sram__sram512x8m8wm1/gf180mcu_fd_ip_sram__sram512x8m8wm1.rst

Steps to Reproduce the Problem

  1. Go to a cell documentation page such as https://gf180mcu-pdk.readthedocs.io/en/latest/IPs/SRAM/gf180mcu_fd_ip_sram/cells/gf180mcu_fd_ip_sram__sram512x8m8wm1/gf180mcu_fd_ip_sram__sram512x8m8wm1.html
  2. Click View or Edit

Specifications

  • Version: v:latest
  • Platform: Readthedocs

Fix default language in sphinx configuration

The following warning is produced when building the docs;

WARNING: Invalid configuration value found: 'language = None'. Update your configuration to a valid langauge code. Falling back to 'en' (English).

Part of #20

Add robot to update common files in all submodules

There are a bunch of things which need to be applied to all the submodules of the gf180mcu-pdk. We should set up a robot which makes sure these files are kept in sync and deployed.

For the F4PGA project their where students at BYU who were working on setting up something like this.

Incorrect Cell LEF used to generate the Standard Cells

Expected Behavior

The standard cell lef layer names should match the layers defined in the tech LEF.

Actual Behavior

The TLEF layer names are named "Metal1", "Metal2"..., but the cell LEFs use an all caps naming convention, "METAL1", "METAL2".

It looks like the wrong cell LEF was used to extract the cell definitions. In the upstream PDK there are two cell lef files one ending in _oa the ending in _mw. The _oa lef file has the all caps naming convention. We should be using the _mw which has the correct layer names.

image

sdff* cells are not parseable by yosys

Expected Behavior

sdff* liberty files should be parseable by yosys.

Actual Behavior

ERROR: Syntax error in liberty file on line 4303.

Steps to Reproduce the Problem

yosys -p "read_liberty cells/sdffsnq/gf180mcu_fd_sc_mcu7t5v0__sdffsnq_4__tt_025C_1v80.lib"

The issue is in the test_cell() stanzas, the clear and preset statements are not quoted, eg:

        preset : !SETN ;

Adding quotes fixes it, and the liberty spec suggests they are required:

        preset : "!SETN" ;

CLASS options wrong in LEF files

Expected Behavior

The LEF files should have lines like "CLASS core ;" where the CLASS parameter has just one option which defines the class.

Actual Behavior

Several LEF files have several options like e.g.
CLASS core ;
CLASS core gf180mcu_fd_sc_mcu9t5v0__tiehIGH ;
CLASS core gf180mcu_fd_sc_mcu9t5v0__tielOW ;
CLASS core SPACER ;
CLASS core WELLTAP ;
CLASS gf180mcu_fd_sc_mcu9t5v0__endcap PRE ;
which is definitely wrong according to the LEF fileformat specification

Link to the slack community in the docs is outdated

Expected Behavior

Docs should point to https://open-source-silicon.dev/

Actual Behavior

Docs point to https://join.skywater.tools/

Steps to Reproduce the Problem

  1. Go to https://gf180mcu-pdk.readthedocs.io/en/latest/index.html
  2. Click on the "๐Ÿ—จ๏ธ Chat" link in the top nav
  3. See
    <li class="md-tabs__item"><a href="https://join.skywater.tools/" class="md-tabs__link"><i class="md-icon">chat_bubble</i> Chat</a></li>

Specifications

  • Version: latest
  • Platform: all

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.