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:

1. The notebooks don't have to re-install everything at the beginning.
2. Any file used by the notebook should be taken directly from the repository itself (and not re-copy it).

Build basic CI flow (smoke test) for OpenFASOC and enable OpenFASOC as a regression testcase for skywater-pdk

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.

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.

@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 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.

There's a lot of unused area in both voltage domains:

According to this, the LDO generator cannot generate 1.8V LDO needed to power digital macros implemented using sky130 SCLs (e.g., hd, hell, ...)

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.

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.

Following #43 and #38. Goal is to improve the experience of new users

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.

This README is linked from https://github.com/google/skywater-pdk-sky130-raw-data/tree/main/docs/sky130-testtile-open

To be updated:

• Add README to:

https://github.com/idea-fasoc/OpenFASOC/tree/main/openfasoc/generators/ldo-gen

• Add Flow Doc. here: https://openfasoc.readthedocs.io/en/latest/flow-ldo.html

Please follow: https://openfasoc.readthedocs.io/en/latest/flow-tempsense.html

• Include Notebook submitted to code-a-chip to the doc.

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 imported, 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.

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.

List of possible updates -

• make it more user-friendly by printing out more comments while installing the dependencies
• cover corner-cases with the prerequisite packages installation based on the OS
• given an option to update dependencies with the same script
• probably build a Makefile having targets like make install, make update, make clean_install
• investigate better installation techniques

Description

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

Suggested Solution

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:

1. set_routing_layers [-power minLayerName maxLayerName] for power connection.
2. Additional ndr rules [-multicut via]. May need further modification in detail router.

https://github.com/The-OpenROAD-Project/OpenROAD/pull/2289/files

To do:

• Modify pdngen to pdn.tcl #81
• Fix route not getting created from header cells to VIN
• Check if LVS is now not giving mismatches

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

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).

(header cell highlighted)

(overlapping tap cell highlighted)

This happens when manual placement is done before tapcell is called and also after.

At the moment all 5 decaps are connected to VREF net.

@saicharan0112

I tried to run (sudo) source ./Dependencies.sh on instance-4 and got this error message. It still doesn't work even with the -u option.

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

@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.

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

@lulu9312

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)

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.

For example:

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.

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.

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

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

Description

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.

At the moment the placement of PT_UNIT_CELLS is random in the secondary voltage domain

https://github.com/idea-fasoc/OpenFASOC/tree/main/openfasoc/generators/temp-sense-gen/flow
https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow

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?

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`

@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.

related to gdsfactory/gdsfactory#610

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

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

Related: The-OpenROAD-Project/OpenROAD#2183 The-OpenROAD-Project/OpenROAD#2209

Lower metal layers have higher resistivity, so we should ignore them for power routing

Generated files such as .log, .rpt, .odb in flow/, work/, and simulations/run/ are not gitignored for the following generators:

1. LDO: No files are gitignored
2. Temperature Sensor: simulations/run/ is not gitignored.

Expected Behavior

The Klayout should extract all four terminals of the NFET layout when running LVS

Actual Behavior

No body terminal shows in the extracted netlist from klayout

Reproducing process

• The layout of 1 PFET and 1NFET

• Extraction result from Klayout, note the lack of “NBODY”. Instead, Klayout assumes that all NFET bodies are tied to the global ground node.

Affect

This can lead to potential latch-up. Cadence flagged this as a soft check error.

list the currently working generators on the front page