Sky130: Add lib to contain all logic libraries, add hd low leakage logic library

[ubfx]

This is my attempt at starting to move in more Sky130 logic libraries (low leakage, high speed, low speed, etc).

I figured there's so much infrastructure built on top of the current sky130hd library that we shouldn't change it straight away, but on the other hand, we have to start somewhere moving in the other logic libs. This patch adds a new library sky130sc, sc for standard cells, which could become the umbrella library for all sky130 logic libraries (hd, hdll, hs, ...) at some point, just like gf180mcu is for gf180. But for now, it can coexist with the tried and tested sky130hd.

The idea would be to add a temporary/development target (skywater130_demo_devel or so) to siliconcompiler which would allow us to add some testing without touching the good old skywater130_demo. (Also, we need a target for the lambdalib generating step).

For now, the new sky130sc setup will load the existing sky130hd, but also the newly added sky130hdll (high density low leakage). A few notes on the sky130hdll:

1. All files were taken from open_pdks, as described in the Readme, but there are some small changes to lefs and libs:
   • Add a dummy cut layer between pwell and li1 to make Cadence accept the LEF. (-> https://github.com/RTimothyEdwards/open_pdks/issues/435)
   • Replace illegal floats with ints in libs to make Cadence accept the lib (-> https://github.com/efabless/skywater-pdk-libs-sky130_fd_sc_hdll/pull/7)
     2. The lambdalib was "generated" by substituting _hd__ for _hdll__ for now. When we have the siliconcompiler target, we should be able to just generate it normally.
     3. Yosys techmapping files were produced the same way.

I know patching the LEFs and libs is not ideal, but I assume there will be some more patches necessary until we get all of the different logic libraries working. And maybe I will be able to upstream some of these patches with open_pdks until then. I would suggest doing a more thorough review of all necessary patches when we get all of the libraries working.

[gadfort]

@ubfx to generate the lambdalib information just use: https://github.com/siliconcompiler/lambdapdk/blob/main/scripts/generate_lamdbalib.py

If you just want to do some testing, you can always create a temporary target on a branch here:

... sky130_dev.py
(copy in regular setup or import it and call it)
chip.use(sky130sc)
chip.set('asic', 'logiclib', '...')

And use it like:

sc -target lambdapdk.sky130.target.sky130_dev

or

from lambdapdk.sky130.target import sky130_dev

...
  chip.load_target(sky130_dev)
...

If you want to check against a broader set of designs you can also try out: https://github.com/siliconcompiler/scgallery

[ubfx]

I tested the new lib locally on yosys+OpenROAD and Cadence on a few designs, but thought we would probably want to some in-tree testing (on CI) before moving the main target over to the new lib. Especially since all the tests on siliconcompiler just use the hd library currently.

Are you against having two targets in-tree for a transitionary period?

[gadfort]

@ubfx I would prefer to no have a temporary target in SC. We could switch the target in SC to point to this file instead (and remove the old file), if the default behavior is the hd lib nothing should change and that would make it possible to do some testing without adding a target.

[gadfort]

Please add the new module to:

• https://github.com/siliconcompiler/lambdapdk/blob/main/tests/test_lambda.py
• https://github.com/siliconcompiler/lambdapdk/blob/main/tests/test_paths.py

[gadfort]

@ubfx looks great, just need to redo the lambdalib generation since the files have references to the half and full adders.

[ubfx]

@ubfx looks great, just need to redo the lambdalib generation since the files have references to the half and full adders.

For the ICGC and the p-latch, I'm now getting something like this:

module la_latq(d, clk, q);
  input clk;
  wire clk;
  input d;
  wire d;
  output q;
  wire q;
  \$_DLATCH_P_  q_reg /* _0_ */ (
    .D(d),
    .E(clk),
    .Q(q)
  );
endmodule

Should I add a techmapping of DLATCH_P to an inverter + the negative-gate latch?

[gadfort]

@ubfx yeah, I think that would be correct.