Migrating to Livt

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 generated 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.

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 boundaries are reviewed for expected ports and state

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

A Small Migration Slice

For a byte classifier, begin with observable behavior rather than line-by-line translation:

Turn the rows into assertions, compare them with the existing HDL testbench, and replace the old instance only after the isolated behavior agrees.

AI-Assisted Migration

AI agents can help with migration planning, boundary discovery, first drafts, and test scaffolding. They are especially useful when a project contains repetitive HDL, HLS/C, or prototype code that needs to be reshaped into clear Livt components.

Keep the Migration chapter focused on the engineering path: choose a boundary, preserve behavior, write tests, and migrate gradually. For the full workflow with coding agents, the Livt agent context, Eccelerators Labs, package publishing, and AI-assisted migration examples, see chapter 17, 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
• review the integration boundary
• update integration code
• document timing or reset assumptions

Also compare generated ports, latency in cycles, reset polarity and values, numeric width and signedness, and vendor constraints. Value-level tests alone do not prove that an integration contract stayed unchanged.

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.