Project workflow

Configure a Livt Project

Use livt.toml to record the project boundary and settings that should behave consistently on another machine.

Prerequisite: open a directory containing a Livt project in VS Code. The extension validates the manifest as soon as it discovers the project.

Keep project state separate

State	Purpose	Commit?
`livt.toml`	Authored project intent	Yes
`livt.lock`	Resolved dependency graph	Yes for reproducible applications
`.livt/`	Downloaded dependencies and tool state	No
Output directory	Generated HDL, reports, and metadata	No

Start with the project boundary

toml

[project]
name = "PacketController"
component = "Livt.Packet.ControllerTop"
path = "src"
outdir = "out"
profile = "debug"

[tests]
path = "tests"
components = ["PacketControllerTest"]

name identifies the project and package. component selects the default Livt entry component and may be omitted when it matches the project name. Paths are resolved from the project directory.

Configure build policy

toml

[build.debug]
warnings = ["all"]

[vhdl]
file_header = true
company = "Example Engineering GmbH"

Warning policy belongs to the source package that owns it. A command-line -W option can override warning selection for a deliberate audit.

Keep machine-specific tools local

The managed VS Code installation supplies Java and GHDL paths directly. Prefer that mechanism over committing an absolute developer path. Vendor paths may be configured in the manifest when the project deliberately standardizes an installation location.

toml

[simulator]
tool = "ghdl"

[vendor.vivado]
part = "your-selected-part"

Validate every change

Save livt.toml and run Validate Livt Project. Unsupported fields, malformed dependency values, missing source roots, and undiscovered test components are reported against the manifest.

Use the complete livt.toml reference when adding simulator, remote generation, or vendor settings.