updates to sky130 cell lists

[jeras]

I am working on porting sky130 LP SCL and noticed no_synth.cells lists seem unmaintained.

• the HD SCL contains duplicates, the reasons for excluding cells are not documented (I at least understand excluding scan cells from synthesis),
• no_synth lists for HDLL/HS/MS/LS seem to be just copies of the one for HD wit search/rename, but the libraries do not contain the same set of cells, so current lists could contain non existing cell s and miss cell that should be listed.

The commits in this pull request are trivial should make no functional changes (so no regressions), they are just a preparation for further changes.

1. removed duplicates,
2. sorted *.cells lists,
3. added sorted lists of all cells in each SCL.
   The idea behind 2, 3 is to make future list updates easier, since being able to compare the sorted lists using a side by side diff tool.

[RTimothyEdwards]

@mole99 : Can you please take a look at this at your convenience?

Should we be reviewing what's in all the exclude lists? The exclude lists were created long ago and I have no idea whether updates to openROAD and openlane/librelane have made much of the contents unnecessary.

[mole99]

We might need to clean the entire exclude lists and run it through the LibreLane CI to see which cells pose issues.

This will likely not catch all the issues, as some may only occur under certain circumstances. So we unfortunately need to rely on LibreLane users to report any remaining issues. But I think it's still worth doing this properly.

I'm not sure if it's possible to add comments to the cell lists using, e.g., #. If not, we should definitely add that feature to LibreLane so that we know why cells were excluded.

[mole99]

These changes look fine to me. Thank you for the cleanup, and I'm looking forward to future list updates.

[jeras]

Setting up a LibreLane CI should probably be the first step before making risky changes.
It could start with something simple (one example with HD SCL) and be later extended to other SCLs and improved coverage, so we can be sure PDK changes are actually tested.

According to information from old forum posts (from about 2021~2024)
*_1 cells were excluded due to connectivity issues.
While I did not find any details, I understand those as either DRC errors or being entirely unable to connect the cell.
The posts are also looking forward to when OpenROAD would fix those issues.

According to announcements LibreLane 3 uses an updated version of OpenROAD, so hopefully at least some of those issues were solved.

I did run a test using the semi last open_pdks release and the LibreLane tutorial example mp32.
The build passed without DRC issues, but this is not a project with proper signoff checks.

I have created a draft document where I investigate why cells are used excluded in no_synth.cells (toward the document end):
https://github.com/jeras/open_pdks/blob/jeras_test/sky130/librelane/README.md
Currently it contains my limited understanding of things.
After extending it and fixing the obvious errors, I can create a pull request.

In addition to broad cell exclusions other problematic areas are technology mapping and clock gating. There is also power gating and DFT, bot those lack so much tool support I will ignore them for now.
So about technology mapping:

• only 2 LATCH cells are mapped out of about 10 latch cell types,
• only MUX2 and MUX4 are mapped, leaving MUX2I, MUX4, MUX8, MUX16 cells unused,
• HA (half added cells are not used), should be a good choice for counters/timers,
• the tristate buffer is mapped the inverter is not,
• ...
  I will investigate clock gating to see if it could be enabled by default in the SCLs.

[mole99]

LibreLane already has a CI with a selection of designs.

You can find the designs here: https://github.com/librelane/librelane-ci-designs
And the test sets here: https://github.com/librelane/librelane/blob/main/.github/test_sets/test_sets.yml

My suggestion would be to edit the exclude lists and run the tests from the CI locally.

---

Regarding the *_1 cells, that could very well be the case. OpenROAD and its detailed router have seen quite some improvements since then.

Yes, you can see the OpenROAD version in use here: https://github.com/librelane/librelane/blob/1e4f4d5bf9d2693798b12dc0c1cd0337ad266a0d/nix/openroad.nix#L45

---

The document is great. However, if there's no information as to why a cell was excluded, I would lean towards removing it from the list anyways. We will find out later on if there are any issues, or not if the original issue has been resolved in the meantime.

---

Power gating is still an open topic.
In terms of clock gating, LibreLane now has a Yosys pass: librelane/librelane#726
Donn is currently working on Difetto, a LibreLane flow for DFT.

Mapping more of the supported cells would be good in general.
For the latches you can refer to this Yosys documentation: https://yosyshq.readthedocs.io/projects/yosys/en/latest/cell/gate_reg_latch.html#latch-cells

[mole99]

@jeras Regarding clock gating, this works for sky130:

Add this to the PDK config:

set ::env(SYNTH_CLOCKGATE_POSEDGE_ICG) "sky130_fd_sc_hd__dlclkp_1/GATE/CLK/GCLK"

And in your design enable clock gating via:

SYNTH_CLOCKGATE_MIN_WIDTH: 4

However, I haven't simulated a design with it yet.

[RTimothyEdwards]

Looks good to me.

[RTimothyEdwards]

Pulled and merged to opencircuitdesign.com. Github mirror will update overnight.

[jeras]

Thanks @mole99 for the details on clock gating. I was going to try the same, but right now my main problem is setting up automated checks. While I got the LibreLane CI to run on my branch I have the following issues:

• some to the 93 test designs fail, but not consistently, the same seems to be happening on the upstream LibreLane CI,
• I would like to test open_pdks updates from my fork, but I can't figure out a practical way to do this, the LibreLane CI only seems to handle published binary releases of open_pdks well. Is it even doable without significant changes to the LibreLane CI?

[jeras]

Thanks @RTimothyEdwards with this and the config.tcl variable changes, I will now prepare the LP (low power) configuration pull request.

[jeras]

I started cleaning up no_synth.cells and drc_excludes.cells for sky130. I am writing a report, since I will have to wait for an issue to be fixed in Libre Lane before continuing.

A GOOD thing is that since LibreLane 2.0.0b17 cell lists can contain comments and wildcards:
https://github.com/librelane/librelane/blob/main/librelane/common/misc.py#L400-L422
This means future lists could be short and commented, therefore reviewable.

The BAD is that LibreLane is mishandling this, so I am unable to test exclusion lists:
librelane/librelane#941

The SLIGHTLY ANNOYING part is there are more deprecated variables, in the PDK TCL configuration file.
For example the file name drc_exclude.cells and variable DRC_EXCLUDE_CELL_LIST to me seems to mean the listed cells are ignored during DRC checking (kind of like SRAM bit cells). The new LibreLane variable name PNR_EXCLUDED_CELL_FILE better conveys the functionality as the the list of cells excluded from use during the PNR steps (like cell strength resizing).

So I would like to make some renames here. The IHP 130 library is already using some of the new variable names for cell exclude lists (but still some deprecated names elsewhere).

[mole99]

@jeras

• some to the 93 test designs fail, but not consistently, the same seems to be happening on the upstream LibreLane CI,

Yes, sorry about that. When LibreLane 3.0 was released, the submodules hadn't been updated. The dev branch of the submodules should have been merged into main, and LibreLane main should have been updated. I'll ping Donn about it.

That said, the CI for LibreLane dev is clean. That's where feature development should happen.

• I would like to test open_pdks updates from my fork, but I can't figure out a practical way to do this, the LibreLane CI only seems to handle published binary releases of open_pdks well. Is it even doable without significant changes to the LibreLane CI?

If you invoke LibreLane without any extra arguments:

librelane config.yaml

It will manage the PDK by itself, i.e. it will use Ciel to download the pinned PDK release.

However, you can specify that you are managing the PDK yourself. This is done via:

librelane config.yaml --pdk sky130A --pdk-root path/to/pdk_root --manual-pdk

or

PDK=sky130A PDK_ROOT=path/to/pdk_root librelane config.yaml --manual-pdk

Usually PDK_ROOT is ~/ciel, but you can compile your own open_pdks fork and point to it.
You would have to adjust the CI workflow slightly to use your own PDK, but I think you can also run all of the CI designs locally.

Is that what you were asking? If you'd like, you can join FOSSi Chat (https://fossi-chat.org) and I can explain more clearly. There are also dedicated rooms for LibreLane and the open-source PDKs.

[mole99]

Thanks for working on the clean-up.

It's unfortunate to hear that LibreLane mishandles SYNTH_EXCLUDED_CELL_FILE. However, that area of LibreLane is not my expertise. Are you suggesting we filter scl_lib_list before adding it to the blackbox_models?

Yes, using the latest name for a variable is always preferred.
If you make some changes to the IHP PDK, you can ping me on the PR for a review.

[jeras]

@mole99 thanks for the CI and tests submodule clarifications. For now I am using ciel build ... to test my changes, but without a CI it can be difficult to do a clean and exhaustive test.

Regarding the handling of SYNTH_EXCLUDED_CELL_FILE by LibreLane, my understanding is too limited to make any suggestions, I will wait for a reply to the issue report.

[mole99]

You're welcome! Yes, I agree with that.

Well, the reply will likely come from either me or Donn. I'm currently rather busy, though, so it might take me a while to look into this more closely.