Adoption

Migrating to Livt

A gradual migration path for existing HDL designs, with clear boundaries, legacy wrappers, and behavior-preserving tests.

Migration does not need to be a rewrite. The safest path is usually gradual: choose a boundary, wrap existing HDL when needed, move one behavior at a time, and keep simulation results comparable.

Livt is most useful when it improves structure and testability without forcing a team to discard working hardware.

Read the Existing Design First

Before translating code, understand the design:

  • What are the top-level ports?
  • Which clocks and resets exist?
  • Where is state stored?
  • Which modules are protocol boundaries?
  • Which modules are reusable?
  • Which testbenches already describe expected behavior?
  • Which vendor primitives or reusable IP blocks are required?

The first migration artifact should often be a short design map, not new code.

Choose Migration Boundaries

Good first migration targets are small and well-tested:

  • byte classifiers
  • packet header parsers
  • register blocks
  • simple FIFOs
  • protocol adapters
  • wrappers around existing modules

Avoid starting with the entire top level. A top-level rewrite mixes too many concerns: IO, constraints, vendor IP, reset behavior, and application logic.

Wrapping Legacy Modules

Existing VHDL or Verilog can be kept behind a Livt-facing boundary. Define the interface you want new Livt code to use, then wrap the legacy implementation.

livt 
interface IByteSource
{
    fn HasData() bool
    fn Read() byte
}

The wrapper can hide legacy signal naming and expose a cleaner Livt contract. This lets new code use Livt style while old code remains in place.

Replacing Boilerplate Gradually

Good migration removes repetition first:

  • duplicated constants
  • repeated signal bundles
  • hand-written testbench setup
  • protocol field extraction
  • register map boilerplate

These areas are usually easy to test and provide quick value.

Preserve Behavior

Migration is successful only if behavior is preserved. For each migrated component, keep at least one of these checks:

  • original HDL testbench still passes
  • equivalent Livt test passes
  • old and new simulations produce matching outputs
  • integration artifacts are inspected for expected ports and behavior

Do not rely on visual similarity between source files. Hardware behavior is the contract.

AI-Assisted Migration

AI agents can help draft migration plans, propose component boundaries, and create initial Livt code from existing HDL, HLS/C, or prototype sources. The migration result should still be reviewed, tested, and simulated before it replaces existing behavior.

For the complete workflow with coding agents, the Livt agent context, Eccelerators Labs, package publishing, and AI-assisted migration examples, see AI-Assisted Development.

Migration Checklist

For each migrated component:

  • define the boundary
  • write or preserve tests
  • migrate one behavior at a time
  • compare old and new behavior
  • inspect integration artifacts
  • update integration code
  • document timing or reset assumptions

Summary

Migrate gradually. Wrap legacy modules, extract stable interfaces, replace boilerplate first, and protect every step with tests. AI can help with drafts and migration planning, but hardware correctness still comes from review, simulation, and careful boundaries.