Continuous Integration & Delivery

Continuous integration makes hardware development repeatable. Every change should be built and tested in the same way, with results that the team can trust.

For Livt projects, CI usually starts with compilation and simulation. Larger projects may also run synthesis, linting, documentation checks, package validation, and vendor implementation jobs.

What CI Should Check

A useful Livt CI pipeline answers a few basic questions:

• Does the project build?
• Do all Livt tests pass?
• Did generated VHDL change unexpectedly?
• Do package APIs still compile for users?
• Does synthesis still succeed for important targets?
• Are timing or resource reports moving in the wrong direction?

Start with build and test. Add heavier vendor jobs when the project is ready.

Build Job

The first job should compile the project:

livt build

This catches syntax errors, type errors, missing files, and generation failures. It is usually fast enough to run on every change.

Test Job

The second job should run simulations:

livt test

Tests should be deterministic. Avoid tests that depend on local paths, manual setup, or timing outside the simulator.

Generated VHDL as an Artifact

Generated VHDL is useful evidence. CI can archive it as a build artifact so reviewers can inspect changes when needed.

For stable releases, keeping generated VHDL alongside reports can help reproduce what was sent into a vendor flow.

Vendor Jobs

Vendor tools may be slower, licensed, or tied to specific machines. It is still valuable to automate them when possible:

• synthesis for the top-level design
• implementation for release candidates
• timing report extraction
• resource usage tracking
• bitstream or netlist generation

Not every branch needs the full vendor flow. A common pattern is to run Livt builds and simulations on every change, then run vendor implementation nightly or before release.

Regression Suites

As the design grows, tests should be grouped by cost:

• fast unit tests for every change
• integration simulations for merge requests
• long-running simulations on a schedule
• vendor implementation for release gates

This keeps feedback fast without losing deeper coverage.

Team Workflow

CI works best when it supports review:

• Require tests before merging.
• Keep test output readable.
• Name tests after behavior.
• Archive generated VHDL and reports.
• Track resource and timing changes over time.

Hardware bugs are expensive when found late. CI moves feedback earlier.

Delivery

Delivery means producing something another stage can consume: a package, a VHDL drop, a vendor project, a bitstream, or documentation.

A release should record:

• Livt source revision
• generated VHDL artifacts
• test results
• synthesis or implementation reports
• known limitations
• package versions

This makes hardware releases auditable.

Summary

Start CI with livt build and livt test. Add generated VHDL artifacts, package checks, and vendor jobs as the project matures. The goal is simple: every hardware change should be reproducible, testable, and reviewable.