Closed proppy closed 1 year ago
rebased and ready for review.
@QuantamHD @mithro
@PiotrZierhoffer @ajelinski it seems that conda-build-prepare doesn't like open_pdks
subpackages: it drops the outputs
(https://github.com/litex-hub/conda-build-prepare/issues/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?
@QuantamHD @PiotrZierhoffer @ajelinski PTAL, splitted the packages to workaround https://github.com/litex-hub/conda-build-prepare/issues/7
Lgtm, but I have no merge access
Lgtm, but I have no merge access
@QuantamHD There was a typo in the workflows that prevented it from running, fixed with https://github.com/hdl/conda-eda/pull/238/commits/5580f692f7eef16b34edb97e6f92719b1badaef8
@PiotrZierhoffer @ajelinski do you have some clue about why open_pdks-linux-gf180mcuc
CI builds are being skipped?
@QuantamHD @mithro @hzeller can you review? This could help to speed up gf180mcu testing.
What do you need help with in this case?
@QuantamHD reviewing this PR, so that we can merge and get a packages published by the CI
@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.
@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.
@proppy We discussed this internally and having a GCP custom runner seems to be the best option. We'll see into setting this up
@PiotrZierhoffer any news on getting this set up?
@xobs fyi: rebased this, let's see if it builds now that we have custom runners!
Looks reasonable to me. I look forward to trying this on some of my designs using the Conda workflow.
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: https://github.com/RTimothyEdwards/open_pdks/compare/master...efabless:open_pdks:master