MHRL FPGA firmware, verification and CI/CD

MHRL designs control, data-acquisition and processing firmware for AMD FPGAs and adaptive SoCs. Our development process includes self-checking verification testbenches and CI/CD infrastructure that takes every commit through linting, simulation, implementation and hardware-in-the-loop testing — with the results reported directly into code review.

See project case studies Explore our services

Every stage traceable to a commit. Rollback with a single button.

Xilinx and AMD devicesPL, PS and NoC integration from Zynq-7000 through Versal Premium

UVM, cocotb and self-checking testbencheswith coverage reported on every merge request

GitLab CI, Kubernetes, Argo CDpipelines that run on your runners or ours

Presented at CERN SoC workshops2021, 2022, 2023, 2025 · ATLAS Global Trigger Meeting, 2026

What we do

Four areas, usually combined. Each page shows typical deliverables and projects that demonstrate them in practice.

Firmware for FPGAs and adaptive SoCs

RTL and block designs for data acquisition and processing on Zynq, MPSoC, RFSoC and Versal, including PetaLinux and Yocto board support.

VHDL / SystemVerilog RTL, AXI and NoC integration
Boot, segmented configuration and PL reprogramming
Version-traceable builds with Hog

Firmware development

Simulation and verification

Self-checking testbenches that run on your workstation and in CI, with code coverage, linting and test ranking feeding straight into code review.

UVM agents, scoreboards and sequences
Riviera-PRO, Questa, GHDL, cocotb
Cobertura coverage overlays on merge requests

Verification

CI/CD, DevOps and GitOps infrastructure

Pipelines and lab infrastructure for building firmware and verifying, validating and measuring it on real hardware, from a single workstation to a k3s cluster with FPGA boards as nodes.

GitLab CI runners for Vivado, PetaLinux and simulators
Netboot, power control and JTAG automation
Kubernetes on arm64/amd64, Argo CD reconciliation

CI/CD and GitOps

FPGA systems integration

Firmware, verification and infrastructure delivered as one reproducible system: a target board that boots an image built from it, a pipeline that tests on it, and a release process that carries the evidence with it.

Board bring-up and hardware-in-the-loop test rigs
One pipeline from lint to hardware test, with rollback
Handover to your team with a working pipeline

Systems integration

Recent work

Selected projects. Further case studies are being prepared.

Services

We take on firmware, verification and infrastructure separately or as a whole. Most engagements start in one area and grow into the pipeline that ties them together.

Firmware for FPGAs and adaptive SoCs

RTL, block design, boot and Linux for AMD FPGAs and adaptive SoCs.

Simulation and verification

Self-checking testbenches, coverage and lint integrated into code review.

CI/CD, DevOps and GitOps infrastructure

Runners, lab automation and Kubernetes clusters with FPGA boards as nodes.

FPGA systems integration

All three delivered as one reproducible, tested system.

Services

Simulation and verification with self-checking testbenches

A testbench that only produces waveforms still leaves the pass/fail decision to a reviewer. We design and implement self-checking, simulation-based verification environments that determine pass or fail automatically, measure coverage and report the evidence directly into code review.

What you get

Verification plan derived from the specification, with agreed pass criteria per block and interface
Industry-standard verification environments (UVM, UVVM or OSVVM): agents (driver, monitor, sequencer), scoreboards, reference models and constrained-random sequences
VUnit as the test runner and management engine, also for UVM testbenches; cocotb for teams that prefer a Python-driven flow
Self-checking testbenches that run identically in the simulator GUI, in batch and in CI
Code and functional coverage tied back to the verification plan and reported with every run
Linting and automatic documentation of the design and the testbench
Test ranking so licence-limited simulator time goes to the tests that matter first

Simulators: Riviera-PRO · QuestaSim / ModelSim
Methodologies: UVM · UVVM · OSVVM · cocotb
Test management: VUnit
Lint and docs: Sigasi-based linting and automatic documentation generation
Coverage: Code and functional coverage collected in ACDB and UCDB formats

Projects in this area

Services

Firmware development for FPGAs and adaptive SoCs

Control, data-acquisition and processing designs for Xilinx and AMD devices from Virtex-E through UltraScale+, Zynq and Versal, delivered with a repeatable build flow, boot support, Linux image and version traceability.

What you get

System decomposition into functional building blocks with defined interfaces and responsibilities
RTL in the language of your choice (VHDL, Verilog or SystemVerilog), with custom or standard interfaces between blocks (AXI, Avalon)
Vivado Block Design where it suits the project, typically for processing-system, memory and transceiver subsystems, integrated with your RTL
Timing-driven methodology, with resource utilisation and power consumption tracked from the first synthesis run to the final implementation
Automated and repeatable process for Vivado project generation, Git-based revision control and the release cycle
For SoC devices, PetaLinux or Yocto-based board support, including netboot

FPGA devices: Virtex-E · Virtex-II Pro · Virtex-5 / 6 / 7 · Virtex UltraScale / UltraScale+
SoC devices: Zynq-7000 · Zynq UltraScale+ MPSoC / RFSoC · Kria K26 · Versal Gen 1 and Gen 2
Electronic Design Automation (EDA) tools: ISE · PlanAhead · Vivado · Vitis · Vitis HLS · PetaLinux · Yocto
Quick prototyping: Multiple Xilinx and AMD development and evaluation kits available in-house

Projects in this area

Case studies for this area are being prepared. The readout IP project shows the firmware build and pipeline side in the meantime.

Services

CI/CD, DevOps and GitOps infrastructure for firmware

Infrastructure that lets a firmware team build, verify, validate and run measurements on real hardware from a git push, whether that is one workstation with a dev board or a Kubernetes cluster where the FPGA boards are worker nodes.

What you get

CI runners on x86 and arm64 with shell, container or Kubernetes executors, tagged and sized separately for implementation, PetaLinux, simulation and programming jobs
Kubernetes clusters where FPGA boards are worker nodes, with a private container registry and Argo CD reconciling lab services and deployments from Git
Hardware-in-the-loop stages: Ethernet-controlled power delivery, JTAG programming and netboot services driven from the pipeline
Measurement in the pipeline: power supplies, multimeters and oscilloscopes controlled from CI jobs, with readings attached to the run
Pipeline stages for lint, simulation with coverage, implementation across several tool versions, and PetaLinux or Yocto image builds
Results delivered into code review: test summaries and coverage on the merge request, status badges, and documentation published with every merge
Traceability end to end: every bitstream, image and report carries the commit it was built from

Stack: GitLab CE / EE · GitHub · Harbor · Argo CD · Kubernetes (k3s)
Backend: x86 and arm64 runners with shell, container or Kubernetes executors · EDA containers
Reporting: JUnit · Cobertura XML overlaid on merge requests · badges · GitLab Pages
Lab hardware: Ethernet-controlled power delivery units (PDU), power supplies, multimeters and oscilloscopes, accessible directly from CI jobs and pipelines

Push or pull: two ways to reach the hardware

Both flows run the same lint, simulation, implementation and hardware-in-the-loop stages. They differ in what puts a build on the board: the pipeline itself, or a change to the desired state in Git.

DevOps: the pipeline pushes. One run builds the artefacts and, in its final stages, programs and tests the board. Simple, and the right start for one board and one team.

GitOps: a reconciler pulls. CI stops at the registry. Deploying is a merge to the deployment repository; a reconciler alongside the hardware notices the change, fetches the artefacts and runs the rig. Rollback is a revert, and many boards can follow one repository.

Projects in this area

Case studies for this area are being prepared. The readout IP project shows the firmware build and pipeline side in the meantime.

Services

FPGA systems integration

Firmware, verification and infrastructure delivered as one system: a repository your team can clone, a target board that boots an image built from it, a pipeline that builds, verifies and tests on that board from a git push, and releases that carry their own evidence.

What you get

One repository layout: firmware IP as Git submodules reused across higher-level designs, with build, simulation and pipeline scripts alongside the RTL
Board bring-up on the target adaptive SoC: boot flow (SD card, JTAG, netboot), PetaLinux or Yocto image, and PL reconfiguration after Linux is up
Hardware-in-the-loop test rig: power control, programming and tests that confirm the image running on the board is the commit the pipeline built
One pipeline from lint to hardware test, with merge gating on its results and redeployment of any earlier release to the board as a routine operation
Releases with evidence attached: version, test, coverage and resource badges per tool version, floorplan and connectivity visualisations, documentation published with every merge
Lab infrastructure sized to the team, from one workstation with a development kit to a Kubernetes cluster where the boards are worker nodes and services are reconciled from Git
Handover: your engineers own the repository, the rig and the pipeline, with documentation and a ranked test list left behind

Typical scope: One IP block or a full acquisition and processing path · from one to multiple target boards · your GitLab or GitHub
Target platforms: Zynq-7000 · Zynq UltraScale+ MPSoC / RFSoC · Kria · Versal
Lab: Development kits · Ethernet-controlled PDUs · JTAG, UART and Ethernet dongles · instruments reachable from CI jobs · boards as k3s nodes where useful
Engagement: Fixed-scope milestones or retained support

Projects in this area

Further case studies covering board bring-up, hardware-in-the-loop rigs and cluster-based labs are being prepared.

Projects

Case studies in the form we use internally: the problem, what we built and the outcome. Further projects presented at CERN SoC workshops (2021–2025) are being written up.

Year	Project	Key technologies	Areas
2026	Automated verification and code review for shared readout IPATLAS Experiment at CERN, for Stanford University — Sigasi-CLI lint, UVM in Riviera-PRO, coverage on MR, OOC synthesis, docs, badges	Versal Premium · Virtex UltraScale+ · Riviera-PRO · Sigasi-CLI	VerificationCI/CDIntegration

Projects

Automated verification and code review for shared readout IP

Making a shared firmware IP safe to merge: every contribution is linted, simulated with coverage, synthesised out-of-context on three Vivado versions and documented before a reviewer opens it.

2026ATLAS Experiment at CERNFirmware · Verification · CI/CD · Integration

Problem

The readout IP (Buffer, Funnel and a GtTids transmit path) is maintained as a Git submodule and instantiated in two higher-level firmware repositories. The two parent designs use different instantiation modes, while team members work with different Vivado versions. Changes arrived faster than reviewers could evaluate them, and a broken merge would propagate into both parent designs. The goal was to let the pipeline establish whether a contribution is mergeable, so that review time goes to design questions rather than to re-running checks.

What we built

Every stage runs in EDA containers pulled from a container registry; the same scripts run on a developer workstation.

Firmware

Readout IP maintained as a Git submodule; Hog-based builds embed the commit, tag and build time into the design.
Out-of-context synthesis in both instantiation modes used by the parent designs, on Vivado 2024.2, 2025.2 and 2026.1, with resource reports per version.
Floorplan and NoC connectivity visualisations generated per build for review.

Verification

UVM verification environments in Riviera-PRO, with agents, sequencers and scoreboards for Buffer, Funnel and the GtTids LTI path.
Tests ranked so that licence-limited simulator time goes to the most valuable tests first.
Code coverage collected in ACDB and exported as Cobertura, overlaid on the diff in GitLab and in VS Code.

Pipeline and review

Sigasi-CLI linting as a Git pre-commit hook and as a CI stage; findings appear as code-quality annotations on the merge request.
JUnit test summaries, coverage and lint findings surfaced directly in code review; documentation and full coverage reports published to GitLab Pages on every merge.
Repository automation: release, coverage, test and resource badges; automatic MR messages; rebase notifications to other open MRs after a merge.

Outcome

Review inputLint findings, test status and coverage are on the merge request before a reviewer opens it.

Merge decisionsReviewers make merge decisions from pipeline results rather than by re-running checks; automatic merge on an agreed green pipeline is the next step.

PortabilitySame scripts for GUI, batch and CI; a failure in the pipeline is reproducible on a workstation.

CompatibilityRegressions across three Vivado versions and two instantiation modes are caught before they reach the parent designs.

Presented at the ATLAS Global Trigger Meeting, 2 September 2026.

How we work

Small, senior and hands-on. Work lives in your repository from day one, and every milestone ships with the pipeline that proves it.

Fixed-scope milestones

From a complete FPGA system to an IP block, verification environment or pipeline stage, each milestone has agreed acceptance criteria. Good for a first engagement or a bounded problem.

Retained support

A monthly allocation for a team that already has a development flow and needs it maintained, extended or kept current as tools evolve.

Proof of concept to production

We start with one board and one pipeline, then scale the setup into the lab infrastructure and release process your project needs.

Talk to us

Need support with FPGA firmware, verification, CI/CD or systems integration? Get in touch.

MHRL Sàrl
Route du Grand-Lancy 81
CH-1212 Grand-Lancy
Switzerland

Useful to include in a first message: target device family, simulator and Vivado versions in use, whether you host GitLab or GitHub, and whether the target hardware can be installed in a lab we can access remotely.