idea-fasoc / openfasoc Goto Github PK
View Code? Open in Web Editor NEWFully Open Source FASOC generators built on top of open-source EDA tools
Home Page: https://openfasoc.readthedocs.io
License: Apache License 2.0
Fully Open Source FASOC generators built on top of open-source EDA tools
Home Page: https://openfasoc.readthedocs.io
License: Apache License 2.0
Run prePEX simulations on LDO generators based upon the simulation parameters mentioned in this document : https://docs.google.com/document/d/1WM2s7kAZDHakeOLUuvOx2q-YmuZw8De3YkUJe4TygyY/edit#heading=h.qdifo995vil5
As described in google/skywater-pdk#415 (comment), one of the issues of sky130osu is the drc error of their gds.
So, sky130osu is currently not supported in cryo-gen
List of possible updates -
make install
, make update
, make clean_install
The power rail cannot extend to the power ring in this screenshot:
Below is the zoom-in screenshot:
The right end of the power rail does not align with the boundary of the core domain.
The distance L in the screenshot below is not the multiple of site_width. This will cause the left side of the right core row does not align with the multiple of site_width and then cause the issue above.
@joamatab I am trying to install python dependencies using make install
but I am getting this below error. Do you have any idea on this?
Collecting gdsfactory==5.1.1 (from -r requirements.txt (line 5))
Could not find a version that satisfies the requirement gdsfactory==5.1.1 (from -r requirements.txt (line 5)) (from versions: 1.1.1, 1.1.3, 1.1.5, 1.1.6, 1.1.8, 1.1.9, 1.2.2, 1.3.2, 1.4.0, 1.4.2, 1.4.3, 2.0.0, 2.0.2, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6, 2.2.8, 2.2.9, 2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.4.1, 2.4.2, 2.4.3, 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8, 2.4.9)
No matching distribution found for gdsfactory==5.1.1 (from -r requirements.txt (line 5))
I did not face this issue on Ubuntu.. I checked the python version which is 3.6.
The header cells in the tempsense have connections similar to a power gating cell, we should try to implement it this way and see if the routing becomes easier (especially for VIN)
Generated files such as .log
, .rpt
, .odb
in flow/
, work/
, and simulations/run/
are not gitignored for the following generators:
simulations/run/
is not gitignored.It would be good to setup a CI system which automatically publishes some IP to a repository as part of the skywater-pdk.
Once you have it all working, we can probably create a https://foss-eda-tools.googlesource.com/skywater-pdk/ip/sky130_fasoc_ip_tempsensor/ repository.
As of now, the LDO area is fixed and PLACE_DENSITY variable is changed based on number of PT_UNIT_CELLS. The area should be automated based on number of PT_UNIT_CELLS.
When running temp_sense_genCollab.ipynb, the whole repo is getting copied again in the docs/notebook/
folder. This notebook also uses auxiliary files (aux_files/) that are already present in the repo cloned originally by the user.
We should assume that the user has cloned OpenFASoC, has successfully installed all dependencies and is running the notebook inside the clone, just like it is done in notebooks from Python projects (example). The installation docs already has a section for the user to test its installation (which could be improved).
Thus:
Header cells are large enough that manual placement with the customPlace_east
procedure makes them overlap with the tap cells in the design, failing placement checks (and thus, the flow).
(overlapping tap cell highlighted)
This happens when manual placement is done before tapcell
is called and also after.
Hi, I have installed this repository following getting-started.rst
.Then I came to the directory of OpenFASOC/openfasoc/generators/ldo-gen
, and I entered the command make
but I got an error as followed:
File "./tools/ldo_gen.py", line 292, in <module>
coefLength = len(jsonModel["Iload,max"][str(vin)])
KeyError: '1.8'
make: *** [Makefile:2: sky130hvl_ldo_verilog] Error 1
How can I solve this problem?
Also, I want to know how to generate DLDO from RTL to GDSII, just like your demo shows on the website. However, I have no idea about the usage of ldo-gen.
Hope for answers.Thanks
For some types of LVS errors, netgen
does not exit with return code 1
and the temp-sense-gen still says that "LVS is clean!" when it is not.
Here I highlight the line printed by netgen that's attesting the LVS error. Notice how at the end of the generator run it still says that there was no error.
That is also the reason why sometimes the temp-sense-gen CI doesn't fail even with some LVS mismatches.
Command line log: https://pastebin.com/gjZJYzwK
I installed all dependencies (except klayout) from https://github.com/hdl/conda-eda repositories, then the required Python packages using make install
from OpenFASOC's root directory. Running the temp-sense-gen with make sky130hd_temp
fails and outputs this warning:
FileNotFoundError: [Errno 2] No such file or directory: 'tools/../flow/results/sky130hd/tempsense/6_final.gds'
When checking the results/sky130hd/tempsense
folder, only these files were created:
1_1_yosys.v 2_1_floorplan.def 2_4_floorplan_macro.def 2_floorplan.def
1_synth.sdc 2_2_floorplan_io.def 2_5_floorplan_tapcell.def 2_floorplan.sdc
1_synth.v 2_3_floorplan_tdms.def 2_6_floorplan_pdn.def 2_floorplan.v
I hope this is somewhat useful. My guess is that it has something to do with the installed version of OpenROAD
Lower metal layers have higher resistivity, so we should ignore them for power routing
The LDO needs a reference voltage (not provided/generated). Given that there is no open-source VREF IP, the generated LDO cannot be used out of the box.
To be updated:
https://github.com/idea-fasoc/OpenFASOC/tree/main/openfasoc/generators/ldo-gen
Please follow: https://openfasoc.readthedocs.io/en/latest/flow-tempsense.html
Verilog files generated from the scripts shouldn't be uploaded to git, only the templates should.
For example, this is currently happening in temp-sense-gen: under temp-sense-gen/src/, TEMP_ANALOG_hv.nl.v
, TEMP_ANALOG_lv.nl.v
and counter.v
are uploaded to GitHub, though they are generated files. Take a look:
In TEMP_ANALOG_hv.nl.v
:
Lines 29-35 depend on the number of HEADER cells chosen, which is an input of the generator.
For temp-sense-gen, this is an easy fix I can make. But does it also happen in other generators?
According to this, the LDO generator cannot generate 1.8V LDO needed to power digital macros implemented using sky130 SCLs (e.g., hd, hell, ...)
Prevent installer script from installing latest tools without referring to the confirmed version numbers from versions.txt
and conda_versions.txt
which are generated by the CI.
Let the installer script refer to these files before installing the tools for OpenFASOC.
LDO generator doesn't dump/copy any final gds file, spice file, drc and lvs reports similar to tempSense generator. Dumping out the simulation png files is a good thing (which the ldo gen alone is doing among all the generators). Can we implement the same thing for tempSense generator too?
I think it is a good idea to follow a order/pattern for all the outputs/results/reports/templates/structures across all the generators.
At the moment the placement of PT_UNIT_CELLS is random in the secondary voltage domain
When using NDR rule with custom via in OpenROAD, I found the issue that the added vias are not actually used/connected during detail routing. And it reports the error below. Basically I think the adding custom vias into NDR rule doesn't do anything.
Below are the output of issue and attached pre_global_route.txt at the bottom is the scrpit that produce this issue:
Error: pg_VIN 2 pin not visited #guides = 24
Error: checkConnectivity break, net pg_VIN
Objs not visited:
frPathSeg: begin (96830 22950 ) end ( 96830 23290 ) layerNum 4
beginStyle: 1
endStyle: 1
frPathSeg: begin (96830 22780 ) end ( 96830 22950 ) layerNum 6
beginStyle: 1
endStyle: 1
frPathSeg: begin (96830 22780 ) end ( 97750 22780 ) layerNum 8
beginStyle: 1
endStyle: 1
frPathSeg: begin (97750 22780 ) end ( 99820 22780 ) layerNum 8
beginStyle: 1
endStyle: 0
frPathSeg: begin (82110 20740 ) end ( 84870 20740 ) layerNum 8
beginStyle: 1
endStyle: 1
frPathSeg: begin (84870 20740 ) end ( 86940 20740 ) layerNum 8
beginStyle: 1
endStyle: 0
frPathSeg: begin (82110 20740 ) end ( 82110 22950 ) layerNum 6
beginStyle: 1
endStyle: 1
frPathSeg: begin (72910 22950 ) end ( 82110 22950 ) layerNum 4
beginStyle: 1
endStyle: 1
frPathSeg: begin (91770 22100 ) end ( 91770 23290 ) layerNum 6
beginStyle: 1
endStyle: 1
frPathSeg: begin (86940 22100 ) end ( 91770 22100 ) layerNum 8
beginStyle: 1
endStyle: 1
frPathSeg: begin (86940 20740 ) end ( 86940 22100 ) layerNum 8
beginStyle: 0
endStyle: 1
frPathSeg: begin (91770 23290 ) end ( 96830 23290 ) layerNum 4
beginStyle: 1
endStyle: 1
frPathSeg: begin (71300 49300 ) end ( 72910 49300 ) layerNum 8
beginStyle: 1
endStyle: 1
frPathSeg: begin (72910 22950 ) end ( 72910 49300 ) layerNum 6
beginStyle: 1
endStyle: 1
frVia: at ( 96830 22950 )
VIA DEF:
VIA L1M1_PR DEFAULT
RECT -85 -85 85 85
RECT -85 -85 85 85
RECT -145 -115 145 115
frVia: at ( 96830 22780 )
VIA DEF:
VIA M2M3_PR DEFAULT
RECT -140 -185 140 185
RECT -100 -100 100 100
RECT -165 -165 165 165
frVia: at ( 82110 20740 )
VIA DEF:
VIA M2M3_PR DEFAULT
RECT -140 -185 140 185
RECT -100 -100 100 100
RECT -165 -165 165 165
frVia: at ( 82110 22950 )
VIA DEF:
VIA L1M1_PR DEFAULT
RECT -85 -85 85 85
RECT -85 -85 85 85
RECT -145 -115 145 115
frVia: at ( 72910 22950 )
VIA DEF:
VIA L1M1_PR DEFAULT
RECT -85 -85 85 85
RECT -85 -85 85 85
RECT -145 -115 145 115
frVia: at ( 91770 23290 )
VIA DEF:
VIA L1M1_PR DEFAULT
RECT -85 -85 85 85
RECT -85 -85 85 85
RECT -145 -115 145 115
frVia: at ( 91770 22100 )
VIA DEF:
VIA M2M3_PR DEFAULT
RECT -140 -185 140 185
RECT -100 -100 100 100
RECT -165 -165 165 165
frVia: at ( 72910 49300 )
VIA DEF:
VIA M2M3_PR DEFAULT
RECT -140 -185 140 185
RECT -100 -100 100 100
RECT -165 -165 165 165
frVia: at ( 71300 49300 )
VIA DEF:
VIA M3M4_PR DEFAULT
RECT -190 -160 190 160
RECT -100 -100 100 100
RECT -165 -165 165 165
INSTTERM: (INST/CELL/TERM/NET) temp_analog_1.a_header_2 HEADER VIN pg_VIN
pre_global_route.txt
Perhaps not a big issue, but the repo is >800M...seems excessive. Might be worth a large file clean (saw a large mp4 in there for example): repos/OpenFASOC/tapeouts/mpw-1/testsetup/MeasResults/SanityCheckDemo.mp4
Give a brief overview of how it works on the tempsense, as an example. For instance, it generates a verilog file, then runs a slightly modified version of the openroad-flow-scripts flow (to accommodate for the 2nd voltage domain etc.)
Let's create a Google Docs file to review before submitting code.
At the moment all 5 decaps are connected to VREF net.
related to gdsfactory/gdsfactory#610
@lulu9312 Currently the processing part after simulations are not modular. I can't reuse it for regression without depending on different variables and functions inside the processing.py script. Can you please keep everything inside one script so that the entire processing part is handled by just running that script?
Please refer to temp-sense generator for clear understanding.
https://github.com/The-OpenROAD-Project/OpenROAD/pull/2289/files
To do:
This README is linked from https://github.com/google/skywater-pdk-sky130-raw-data/tree/main/docs/sky130-testtile-open
How it looks currently:
The net must be widened and must connect to the ring in multiple spots, so that its resistance is not too large, and to reduce process variation
Related: The-OpenROAD-Project/OpenROAD#2209
More details of this problem can be found in #[3067] (The-OpenROAD-Project/OpenROAD#3067). Basically we seeing some weird behavior of the OpenROAD routing while using sroute command and ndr rules. During the connection from a cell to the power ring, there is a sudden change of wire width even though at the same layer. Also at some of the via cut, there is extra wire added which is way more than enough.
Build basic CI flow (smoke test) for OpenFASOC and enable OpenFASOC as a regression testcase for skywater-pdk
@mithro pointed me to #11 where matlab based tests seems to be a lot of calculation and plotting to validate the design, I'm curious if you've considered using https://jupyter.org/ as an alternative (maybe thru https://github.com/mwouts/jupytext to make it source control friendly).
Note sure how easy it would be to replication the various calculation in Python, but Jupyter also have support for Octave (GNU/Matlab) https://github.com/Calysto/octave_kernel and Julia https://github.com/JuliaLang/IJulia.jl
As described in #2209 and #2349, in the design that involves multiple voltage domains, there is no routes from standard cell to another voltage domain that is generated by pdngen. We address this issue and created an issue in OpenROAD #3050
Qianxu and I from the openfasoc team created a PR #3043 to address this issue. Currently, it is able to connect the standard cells to power rings. See details in OpenROAD #3050
Proposed Command:
All of these commands should be called before global route.
dbGPpins : create [dbBlock] [dbTech] [source net name] [number of connection points] [position]
odb::createConnection [ord::get_db_block] [new net name] [instance name] [iterm on power ring to check the connections]
Currently this command creates custom connections from a specific cell to the power ring before global route.
temp sense generator exmaple with 1 PGpin on power ring VIN (More example in #3050
odb::createPGpins [ord::get_db_block] [ord::get_db_tech] "VIN" 1 "default"
odb::p2proute [ord::get_db_block] "pg_VIN" "temp_analog_1.a_header_0" "VIN"
odb::p2proute [ord::get_db_block] "pg_VIN" "temp_analog_1.a_header_1" "VIN"
odb::p2proute [ord::get_db_block] "pg_VIN" "temp_analog_1.a_header_2" "VIN"
Future Work:
klayout-pypi expose a subset of klayout Python API (klayout.db
, klayout.tl
and klayout.rdb
) packaged as a standalone python module distributed on https://pypi.org/project/klayout/.
Depending on it (even optionally) rather than the CLI, could simplify the process of install dependencies for OpenFASOC, we should explore if the subset of klayout functionality used by the generators can be provided by the bare python API.
list the currently working generators on the front page
The Klayout should extract all four terminals of the NFET layout when running LVS
No body terminal shows in the extracted netlist from klayout
This can lead to potential latch-up. Cadence flagged this as a soft check error.
In order to be able to orchestrate generation from other python codebase (or jupyter notebooks) it would be nice if OpenFASOC exposed a python interface over the main generators flows that can be import
ed, https://github.com/idea-fasoc/OpenFASOC/blob/main/generators/temp-sense-gen/tools/temp-sense-gen.py
Note: https://github.com/idea-fasoc/OpenFASOC/blob/main/generators/temp-sense-gen/tools/TEMP_netlist.py seems to already exposes functions some lower level function that could be imported, but it seems that there is a fair amount of work also done from the outer scripts.
During the first step (install all tools and dependencies), colab fails to pip install gdstk as shown below:
Collecting gdstk
Downloading gdstk-0.9.37.tar.gz (509 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 509.2/509.2 kB 13.1 MB/s eta 0:00:00
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: numpy in /usr/local/lib/python3.9/dist-packages (from gdstk) (1.22.4)
Building wheels for collected packages: gdstk
error: subprocess-exited-with-error
× Building wheel for gdstk (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
Building wheel for gdstk (pyproject.toml) ... error
ERROR: Failed building wheel for gdstk
Failed to build gdstk
ERROR: Could not build wheels for gdstk, which is required to install pyproject.toml-based projects`
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.