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
• generated VHDL is inspected for expected ports and state

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

Using LLMs and AI-Assisted Migration

Large language models can be useful during migration, especially when a project contains a large amount of repetitive VHDL or Verilog. They can help summarize modules, identify signal groups, propose Livt interfaces, draft wrapper components, and translate small, well-bounded pieces of behavior into Livt.

Use AI as an assistant, not as the source of truth. Hardware migration is about preserving behavior, timing assumptions, reset semantics, and integration contracts. Those details must be checked through review, simulation, and generated VHDL inspection.

A practical AI-assisted migration workflow looks like this:

1. Choose a narrow boundary, such as one FIFO, parser, register block, or protocol adapter.
2. Ask the model to summarize the existing HDL interface: clocks, resets, input signals, output signals, parameters, and expected handshakes.
3. Convert that summary into a Livt interface or component constructor.
4. Migrate behavior in small pieces, keeping names and protocol states close to the original design until tests are passing.
5. Write Livt tests that reproduce the existing HDL testbench scenarios.
6. Compare simulation behavior before replacing the original module.
7. Inspect the generated VHDL for reset behavior, port direction, state machines, and array or signal widths.

Good prompts are concrete. Instead of asking an AI to "convert this project to Livt", provide one module and ask for a limited output:

Summarize this VHDL entity as a Livt component boundary.
List the clock and reset signals, input signals, output signals,
internal state, and any handshake assumptions. Do not translate behavior yet.

Then proceed in smaller steps:

Propose a Livt interface for these AXI-lite read signals.
Use explicit `in` and `out` directions. Explain which side drives each field.

AI is most effective for migration when it reduces mechanical work while the developer remains responsible for hardware correctness. Treat every generated Livt fragment as a draft: compile it, test it, inspect the VHDL, and keep changes small enough that mismatches are easy to find.

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 generated VHDL
• 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 accelerate the mechanical parts, but hardware correctness still comes from review, simulation, and careful boundaries.