TT04 github action feature requests

[dlmiles]

GDS

• Ability to retain logs on failure for download. They can be quite big 50 to 250Mb so maybe like now they should not be the default but use an option. This option would be a tick box to the manual 'workflow_dispatch' configuration.
• Ability to select ALL files for download (as in src/** run/**) again via tick box to 'workflow_dispatch' tick box.
• Maybe include in the file name the action run job ID which is usually a small integer like 1234. So help file management and ambiguity of which sequence when you have downloaded to inspect as those logs are handled/downloaded/stored..
• Maybe use the naming "GDS-failure-logs-job1234" to clearly indicate the data set is for a failure scenario.

yosys warnings

• Ability to have the tt-support-tools/project.py --print-warnings be performed on success and failure, to attempt to post-process the data. Maybe it should print a BLOCK CAPITAL WARNING AT THE TOP AND BOTTOM OF THE OUTPUT that indicate the run did not complete and the log data will be partial and best effort to collate.
• So the project.py need to detect the run did not complete to print warnings, also be coded maybe as a best effort to print what it can or print a message indicating a log file was missing, not failing on missing files when it is a failure GDS run, exit status working as now for a success GDS run, etc...

gatelevel

• Use *.vcd and maybe *.fst wildcards for all files that match in download artifact, not the single specific file. This might encourage multiple tests generating multiple VCDs.
• Emit VCD artifacts on GL test failure (so the VCD can be compared) to local testing.

sby / formal

• Provide a skeleton example for formal to add to workflow.
• Allow easy way to disable it, maybe by renaming of removing the configuration file, and having the action print out a message explaining why it was skipped (and what action the user needs to take to get it working again).

wavedrom support

• Consider hooking wavedrom support into the cocotb example for 'test' and 'gatelevel'.
• Export the *.json output with VCD data in artifact.
• Publish the wavedrom/*.json on the gh-pages to allow browsing wave.
• Might need to use wavedrom plugin to handle really large data sources files to scroll more elegantly the timeline.

[mattvenn]

thanks!

[dlmiles]

• Push your own docker image to GHCR to halve GDS action total build time (for some participants with less complex designs).

Apparently even free open-source accounts on github can push docker images to the GHCR (GH content repository) this is a docker image storage repository. I had always thought this was only available to paid GH accounts previously but another OSS project I am involved with has recently setup images successfully.

So this would mean (in theory) it is possible for you to create an action, that only you need to run, that performs the slower task of building the docker image and installing OpenLANE/PDK/oss-cad-suite and anything else you might need all in one image.
You can then push this to GHCR and github will store and host it and provide you a reference to use it.

Then in the action runners you provide in the tt99-submission-template repository scripts, you pull this (your) image directly and in the next step immediately build the GDS. Without having to wait for any additional download/installation tasks to occur. If you built it with oss-cad-suite in there as well, the gatelevel testing can also run using that image as well.

This may halve the online process/waiting for participants with simpler projects by using a shared pre-built docker image (with all the tools needed already loaded).

You can still update the docker image, and test, and then retag to a label (usually 'latest') that the participants project's then start to use at the next build. This might manually happen for oss-cad-suite which might be updated weekly, even if OpenLANE and PDK is likely to be a fixed version due to eFabless submission requirements.