Continuous Integration (CI)

Note

At the moment, there is no triggering mechanism set up between different GitHub repositories. All the workflows in this repo are triggered by push events, CRON jobs, or manually.

Status

Base, Simulation and Linting

Synthesis, PnR and Prog

Formal

ASIC

All-in-one

'doc workflow Status'

'apicula workflow Status'

'boolector workflow Status'

'irsim workflow Status'

'formal workflow Status'

'base workflow Status'

'arachne-pnr workflow Status'

'cvc workflow Status'

'klayout workflow Status'

'sim workflow Status'

'ghdl workflow Status'

'ghdl-yosys-plugin workflow Status'

'pono workflow Status'

'magic workflow Status'

'impl workflow Status'

'gtkwave workflow Status'

'icestorm workflow Status'

'superprove workflow Status'

'netgen workflow Status'

'prog workflow Status'

'iverilog workflow Status'

'nextpnr workflow Status'

'sby workflow Status'

'openroad workflow Status'

'nvc workflow Status'

'openfpgaloader workflow Status'

'yices2 workflow Status'

'verible workflow Status'

'prjoxide workflow Status'

'z3 workflow Status'

'verilator workflow Status'

'prjtrellis workflow Status'

'xschem workflow Status'

'f4pga workflow Status'

'xyce workflow Status'

'vtr workflow Status'

'yosys workflow Status'

Structure

The continuous integration in this repository is based on commands pull and build provided by the Python utils (see pyHDLC Reference); so, contributors can execute exactly the same commands locally, for debugging and development. However, there are several layers of complexity around those commands, in order to precisely decide which images to build in each workflow/job execution.

Structure of the Continuous Integration (CI)

Fig. 12 Structure of the Continuous Integration (CI) in this repository.

As shown in Fig. 12, the following wrappers are used:

Tip

In pyTooling/Actions: Context, details about Action and Workflow kinds supported in GitHub Actions are explained. See also Workflow syntax for GitHub Actions.

  • build-test-release is a local Composite Action with three steps, including setup, pulling/building/testing and releasing.

  • Common is a Reusable Workflow with two jobs. The first job, named matrix, uses pyHDLC jobs to generate a list of tasks to be used in the second job, named jobs (see docs.github.com: Workflow syntax for GitHub Actions » jobs.<job_id>.outputs). Then, the Composite Action is used in each of the dynamically generated jobs.

  • Dispatch is a Dispatchable Workflow, which calls the Reusable Workflow. In practice, Dispatch documents the internal triggering interface, but it is not used explicitly. There are dozens of workflows (one per tool or group) which are equivalent to Dispatch with some hardcoded inputs. Those are triggered through scheduled (CRON) events, by pushes, by Pull Requests or manually.

Since most of the complexity of the orchestration is defined in the YAML configuration file used by pyHDLC, reading YAML Configuration File is strongly recommended. As shown in Fig. 12, data from the configuration file is used in the Reusable Workflow Common and in the build step of the Composite Action build-test-release.