We provide custom firmware development, verification and systems integration services for AMD FPGAs and adaptive SoCs.
From a single IP block to a complete control, data-acquisition or processing system, we work alongside your team — with CI/CD infrastructure to automate builds, testing and releases.
Automated builds and tests give your team traceable results for each change.
A scope that fits your projectSupport for an individual task or a complete system.
Work in your repositoryYour team can follow development and access the code, tests and build process.
Clear acceptance criteriaAgreed milestones supported by test results.
How we can help
Get support with a specific development challenge or a complete FPGA system. We work with your team across firmware development, verification, automation and integration, with a scope that fits your project.
Turn your requirements into firmware for control, data acquisition and processing. We develop new designs or extend existing ones, with interfaces, timing and resource constraints considered throughout.
Give your team clear evidence that design changes behave as intended. We develop automated tests that check functionality, measure coverage and report results directly into code review.
Reduce manual work in building, testing and releasing firmware. We automate your development workflow and hardware tests, with results traceable to the code that produced them.
Bring firmware, software and target hardware together into a working system. We support board bring-up, system testing and handover so your team can build, operate and maintain it.
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
A repeatable way to run your tests locally and in CI, using VUnit or a Python-driven flow with cocotb
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 · GHDL
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
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
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
Build and simulation runners configured for your tools, workloads and available infrastructure
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
Technical detail: deployment approaches
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.
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
A repository structure that lets your team reuse IP and reproduce builds across projects
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
Further case studies covering board bring-up, hardware-in-the-loop rigs and cluster-based labs are being prepared.
Projects
Selected projects: the challenge our customer faced, what changed for their team and what we delivered.
Year
Project
Key technologies
Areas
2026
Automated checks for shared FPGA firmwareATLAS Experiment at CERN, for Stanford University. Changes to shared firmware affected two dependent designs. Automated verification and compatibility checks give reviewers test results and coverage before merging, with failures reproducible on their own workstations.
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
Customer challenge
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 changed for the team
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.
What we delivered
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.
Technical detail
The readout IP in the parent design (simplified). Eleven Buffer instances in four SLRs capture algorithm outputs. The Funnel reads them through the NoC and GtTids sends the data out on the GTYP transceivers. Red lines show the latency-critical path. This path includes the reception of the synchronization data and its distribution to the Buffers. The dashed line shows the simplified loop through the external Central Trigger Processor back to the GEP. The data readout (yellow) is not on the critical path.
Each Buffer must keep its data for approximately 10 microseconds (µs). This time starts when the earliest input data arrives. It includes the transmission of the trigger inputs to the Central Trigger Processor and the reception of the trigger decision. It stops when GtTids has distributed the decision to the Buffers and the data readout can start.
How we work
We agree the scope, deliverables and acceptance criteria with you. Work takes place in your repository, with code, tests and build instructions available to your team throughout the project.
A defined project
Deliver a specific IP block, verification environment, pipeline or integrated system against agreed acceptance criteria.
Ongoing engineering support
Extend your team’s capacity to maintain designs, add functionality and keep the development workflow current.
From prototype to deployment
Establish the design on your target hardware, then develop the testing and release process needed for ongoing use.
Discuss your project
Tell us what you are building, where you need support and any constraints or deadlines. We’ll help you identify a practical next step.
MHRL Sàrl Route du Grand-Lancy 81 CH-1212 Grand-Lancy Switzerland