Vendor Integration

Livt projects can enter existing FPGA and ASIC toolchains while keeping the design boundary clear and reviewable.

Vendor integration is about keeping that handoff clean.

Build Artifacts

The normal flow is:

1. Write Livt source.
2. Build the project.
3. Review or archive build artifacts when needed.
4. Run simulation.
5. Hand the project output to the vendor flow for synthesis, implementation, or downstream integration.

Synthesis Boundaries

Keep synthesizable design code separate from test and simulation code. A source component should avoid simulation-only APIs unless it is explicitly not part of the synthesis path.

Good boundaries make vendor integration simpler:

• src/ contains design code
• tests/ contains test components and simulation scenarios
• top-level constructors expose clear physical signals
• interfaces group protocol signals
• top-level ports are easy to review

Top-Level Components

The top-level component is the bridge to the vendor project. Keep its constructor clear and hardware-facing:

component Top
{
    app: AppCore

    new(clk: clock, rst: reset, rx: in logic, tx: out logic)
    {
        this.context.clk = clk
        this.context.rst = rst
        this.app = new AppCore(rx, tx)
    }
}

Avoid hiding board-level signals deep inside the design. A reviewer should be able to open the top-level component and understand the external contract.

Vendor Wrappers

Many designs need to connect Livt code to vendor-specific primitives: PLLs, block RAMs, transceivers, IO buffers, clocking resources, or vendor IP.

The usual strategy is to wrap vendor-specific functionality behind a stable Livt interface:

interface IUartPins
{
    rx: in logic
    tx: out logic
}

The Livt design depends on the interface. The vendor-specific wrapper handles the details of the target device.

Constraints and Timing

Livt source does not replace timing constraints. Vendor flows still need clock definitions, pin assignments, IO standards, derived clocks, false paths, and other constraints.

Keep constraints versioned with the project. When a Livt interface or top-level port changes, check whether constraints must change too.

Inspecting Top-Level Ports

Before integrating into a vendor project, inspect the top-level ports:

• Are input and output directions correct?
• Are clock and reset ports named and connected as expected?
• Are interface signals grouped and named in a way the board-level design can review?
• Are public stored fields exposed intentionally?
• Are test-only components excluded from synthesis?

This inspection catches boundary mistakes early.

Deployment Considerations

Deployment is project-specific, but the pattern is consistent:

• build Livt
• run tests
• collect build artifacts
• create or update the vendor project
• run vendor synthesis and implementation
• archive reports and bitstreams

As the design matures, automate these steps in CI so hardware integration is repeatable.

Summary

Livt should fit into existing hardware flows, not replace them all at once. Keep build artifacts visible, maintain clean top-level boundaries, wrap vendor-specific blocks behind interfaces, and treat constraints as part of the design.