misc/open_pdks: add gf180mcuc variant

[proppy]

This add a new subpackages including the C variant (5-metal backend stack) of https://github.com/google/gf180mcu-pdk.

In order to support fully OpenLane, additional patches from efabless's fork of open_pdks should probably be included:
RTimothyEdwards/open_pdks@master...efabless:open_pdks:master

[proppy]

rebased and ready for review.

@QuantamHD @mithro

[proppy]

@PiotrZierhoffer @ajelinski it seems that conda-build-prepare doesn't like open_pdks subpackages: it drops the outputs (litex-hub/conda-build-prepare#7) and goes into an infinite recursion:
https://pipelines.actions.githubusercontent.com/serviceHosts/b1561d4a-c200-469d-96ed-a5c4b56e2e69/_apis/pipelines/1/runs/1607/signedlogcontent/100?urlExpires=2022-09-08T08%3A17%3A19.4576764Z&urlSigningMethod=HMACV1&urlSignature=JeSfPNM5T6Ps7%2B1lthwjlO2ui%2FjMONeXD804i%2FY0vBI%3D

2022-09-08T07:23:42.3113866Z RecursionError: maximum recursion depth exceeded in comparison

Is there a way to workaround this, should we create two separate packages instead?

[proppy]

@QuantamHD @PiotrZierhoffer @ajelinski PTAL, splitted the packages to workaround litex-hub/conda-build-prepare#7

[QuantamHD]

Lgtm, but I have no merge access

[proppy]

Lgtm, but I have no merge access

@QuantamHD There was a typo in the workflows that prevented it from running, fixed with 5580f69

[proppy]

@PiotrZierhoffer @ajelinski do you have some clue about why open_pdks-linux-gf180mcuc CI builds are being skipped?

[proppy]

@QuantamHD @mithro @hzeller can you review? This could help to speed up gf180mcu testing.

[QuantamHD]

What do you need help with in this case?

[proppy]

@QuantamHD reviewing this PR, so that we can merge and get a packages published by the CI

[ajelinski]

@PiotrZierhoffer @ajelinski do you have some clue about why open_pdks-linux-gf180mcuc CI builds are being skipped?

It seems there's not enough space for this job to succeed.
I rerun it and the workflow summary (https://github.com/hdl/conda-eda/actions/runs/3020315356) shows such an error:

Unhandled exception. System.IO.IOException: No space left on device : '/home/runner/runners/2.296.2/_diag/Worker_20220920-143109-utc.log'

Not sure if that's helpful but the last lines I saw in the log during building were:

  $SRC_DIR/common/preproc.py -DTECHNAME=gf180mcuC -DREVISION=1.0.334-0-g82d61e2 -DMETALS5 -DMIM -DTHICKMET0P9 -DHRPOLY1K -DSTAGING_PATH=$SRC_DIR/gf180mcu -DMAGIC_CURRENT=libs.tech/magic -DOPEN_PDKS_COMMIT=82d61e2c9c265c0f0e994233cd2d024c90adb45f -DFD_SC_MCU9T5V0_COMMIT=16154d5495bd351e390343115ae6f8d1275e8003 -DFD_SC_MCU7T5V0_COMMIT=0b28b8d0f0a027a83b97a232e5ab667d7c37792b -DFD_PR_COMMIT=e1b4e187900370103bf9b8a22bb8625f883368ef -DFD_IO_COMMIT=bcaa40aaf6cf04d6e9cb143d0e5b0de9429e53ab -DFD_IP_SRAM_COMMIT=9c411928870ce15226228fa52ddb6ecc0ea4ffbe -DMAGIC_COMMIT=7905e15ae3b66ed26349fb701b475ef93b566de5 -DMAGIC_VERSION=8.3.324 -DOPEN_PDKS_VERSION=1.0.334 gf180mcu.json \
  	$SRC_DIR/gf180mcu/gf180mcuC/.config/nodeinfo.json
  make[2]: Leaving directory '$SRC_DIR/gf180mcu'
  make tools-C
  make[2]: Entering directory '$SRC_DIR/gf180mcu'
  mkdir -p $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout
  mkdir -p $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout
  rm -rf $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/drc
  rm -rf $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/lvs
  rm -rf $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/tech
  rm -rf $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/pymacros
  mkdir $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/drc
  mkdir $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/lvs
  mkdir $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/tech
  mkdir $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/pymacros
  cp -rp $SRC_DIR/gf180mcu-pdk/gf180mcu_fd_pr/rules/klayout/drc/* \
  	$SRC_DIR/gf180mcu/gf180mcuC/libs.tech/klayout/drc
  mkdir -p $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/openlane
  mkdir -p $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/openlane
  rm -rf $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/openlane/gf180mcu_fd_sc_mcu7t5v0
  rm -rf $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/openlane/gf180mcu_fd_sc_mcu9t5v0
  mkdir $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/openlane/gf180mcu_fd_sc_mcu7t5v0
  mkdir $SRC_DIR/gf180mcu/gf180mcuC/libs.tech/openlane/gf180mcu_fd_sc_mcu9t5v0

BTW sorry for such a late response. I was OOO last week.

[proppy]

@ajelinski is there a workaround? (maybe https://github.com/marketplace/actions/maximize-build-disk-space? or dedicated workers?)

I'd like to be able to leverage published build of the package to ease gf180mcuc testing.

[PiotrZierhoffer]

@proppy We discussed this internally and having a GCP custom runner seems to be the best option. We'll see into setting this up

[proppy]

@PiotrZierhoffer any news on getting this set up?

[proppy]

@xobs fyi: rebased this, let's see if it builds now that we have custom runners!

[xobs]

Looks reasonable to me. I look forward to trying this on some of my designs using the Conda workflow.