---
title: "Build with Vivado, Quartus, Libero and Radiant"
---

# Build with Vivado, Quartus, Libero and Radiant

Vendor builds in batch mode from the Editor, flow steps and compilation stages, messages with suppression rules, DRC, methodology and Design Assistant waivers, power estimates, incremental and out-of-context runs, partitions, and licence failures.

The vendor's own engine runs every vendor step, in batch mode. The Editor writes the Tcl, runs the tool, and reads its messages and reports into Problems and the FPGA Implementation panel, as for the open flow.

**State: no build on this page has been run against Vivado, Quartus, Libero SoC or Radiant, and nothing has run on Windows.** Each capability is **kit shipped** (the generated Tcl is tested line by line, its control flow runs under `tclsh` 8.6 with stand-ins for the vendor's commands, and a verification kit runs the same scripts on a real installation) or **modelled**, as marked. Report parsers are tested on real vendor reports from public projects where the row says so. See [Vendor tools and verification kits](https://neuralinverse.com/docs/modules/hdl/vendor-tools/).

## Targets

A vendor target is a `targets` entry with the vendor's family:

| `family` | Tool | Also needs |
|---|---|---|
| `xilinx` | AMD Vivado | `device` (the part number, such as `xc7a35tcsg324-1`), XDC `constraints` |
| `intel` | Altera Quartus Prime | `chipFamily` (as Quartus names it, such as `Cyclone V`), SDC and `.qsf` `constraints` |
| `microchip` | Microchip Libero SoC | `chipFamily`, the part number as `device` (die, package, speed and range decoded from it), optionally `dieVoltage` and `programmer` |
| `lattice` | Lattice Radiant | Optionally `performanceGrade`, `synthesis` (`lse` by default, or Synplify Pro), `xcf` for programming, and a `radiant` block |

Vendor-specific options live in the target's `vivado`, `quartus`, `libero` and `radiant` blocks; see [Reference](https://neuralinverse.com/docs/modules/hdl/reference/#hdljson-keys).

## AMD Vivado

### Build and flow steps

**Build FPGA Target** runs the whole flow to the bitstream in one Vivado run. **Run Synthesis**, **Run Implementation** and **Generate Bitstream** run one step at a time, each from the checkpoint of the step before, so a synthesis-only check takes minutes. The panel's **Flow steps** table shows each step as done, out of date or not run; a missing earlier step is offered first, and an out-of-date one offers to run it first or anyway.

Extra `synth_design` options go in `neuralInverse.hdl.implementation.vivadoSynthesisArguments`. Named strategies from an imported `.xpr` are resolved by Vivado itself; per-step directives and `tcl.pre` and `tcl.post` hooks are in the target's `vivado.strategies`.

State: **kit shipped**.

### Messages

Every Vivado message is kept with its ID and severity:

- errors and warnings (and infos that are design-check violations) go to Problems at their source line, with the ID as the code;
- the report view filters by severity and ID;
- quick fixes **Suppress [ID]** and **Change Severity of [ID]** write a rule into `targets[].vivado.messageConfig`, emitted as `set_msg_config`, with how many messages each rule matched; message limits are reported.

State: **kit shipped**; parsers tested on real Vivado reports from 2017.3 to 2026.1.

### DRC and methodology

`report_drc` and `report_methodology` violations are listed by rule in the report view, and in Problems at their cells' source lines. Waivers in `targets[].vivado.waivers` (by rule or object, with a reason) are emitted as `create_waiver`; add one from a quick fix. A waiver that waived nothing, or whose objects were not found, is reported as stale and never widened.

State: **kit shipped**.

### Utilisation, clocks and power

The report view shows flat utilisation, hierarchical utilisation as a tree (LUT, FF, BRAM and DSP per instance), and clock utilisation (clock primitives with used, fixed and available counts).

After routing, `report_power` gives the total, dynamic and static power, the junction temperature, the power of each kind of resource and how confident Vivado is (low without switching activity). It runs inside a Tcl `catch`, so an estimate that cannot be made fails nothing. A target's `activity` names a testbench whose waveform becomes SAIF for `read_saif`; see [ASIC: power from simulation](https://neuralinverse.com/docs/modules/hdl/asic/#power-from-simulation) for how activity is worked out.

State: **kit shipped** (vectorless power); **modelled** (`read_saif`).

## Altera Quartus Prime

### Build and compilation stages

**Build FPGA Target** compiles the revision (`execute_flow -compile`). Each stage also runs on its own from the build's database:

- **Quartus: Start Analysis & Elaboration**
- **Quartus: Start Analysis & Synthesis** (`map` on Standard and Lite, `syn` on Pro)
- **Quartus: Start Fitter**
- **Quartus: Start Assembler**
- **Quartus: Start Timing Analysis**

Each stage shows as done, out of date or not run, with its prerequisites; running a stage again clears the stages after it.

The build writes the project fresh in the build folder, copies each IP and system there and generates it with `qsys-generate`. Generation messages appear in Problems on the `.ip`, `.qip` or `.qsys`. `quartus.edition` names the edition; a Pro project built with Standard (or the reverse) stops with a message.

![Quartus compilation stages run one at a time, with utilisation, power and messages by kind](https://neuralinverse.com/docs-images/modules/hdl/quartus-compile-stages.webp)

State: **kit shipped**.

### Power Analyzer

The build runs the Power Analyzer inside a Tcl `catch`. A target's `activity` gives it the testbench's activity as a VCD of the design instance; the report view shows the confidence breakdown, power by clock, hierarchy and supply, and a warning when no simulated nets matched. The build also asks for the Early Power Estimator file.

State: **kit shipped**; parser tested on a real power report of another design. The command options come from search results; the kit checks them on a real install.

### Design Assistant

Standard Edition targets run the Design Assistant in batch after the Fitter; for Pro, the signoff report is read. Rules go to Problems at their source node. **Quartus: Waive Design Assistant Violation...** (or **Waive** in the report) adds a waiver with a reason to `quartus.designAssistantWaivers` in `hdl.json`; the Editor applies these waivers to the report, and Quartus does not read them. Stale waivers are reported.

![Design Assistant rules after the Fitter, with Waive buttons and a waiver kept in hdl.json](https://neuralinverse.com/docs-images/modules/hdl/quartus-design-assistant.webp)

State: **kit shipped**; parsers tested on real Standard and Pro Design Assistant reports of other designs.

## Microchip Libero SoC

Targets with family `microchip` (PolarFire, PolarFire SoC, SmartFusion2, IGLOO2, RTG4) build with Libero SoC in batch mode: Synplify Pro, place and route, SmartTime timing, SmartPower power, the FlashPro Express job, STAPL and pin reports. Single steps run on the build's kept Libero project:

- **Libero: Synthesize**
- **Libero: Place and Route**
- **Libero: Verify Timing**
- **Libero: Generate Bitstream and Export Job**

Each is shown as done, out of date or not run. Libero's and Synplify's messages go to Problems. Which tools use each constraint file is set in the Constraint Manager (`libero.constraintTools`); see [Timing analysis and constraints](https://neuralinverse.com/docs/modules/hdl/timing/#libero-constraint-manager).

![Libero SoC flow steps for a PolarFire target run one at a time, with utilisation and clocks](https://neuralinverse.com/docs-images/modules/hdl/libero-flow-steps.webp)

State: **kit shipped**. The SmartTime summary and SmartPower layouts were written from documentation, not captured.

## Lattice Radiant

Targets with family `lattice` (CertusPro-NX, Certus-NX, CrossLink-NX, MachXO5-NX, Avant, iCE40 UltraPlus) build with Radiant: LSE or Synplify Pro (the target's `synthesis`), map, place and route, and Bitgen. Messages come from Radiant's output.

- **Strategy:** `radiant.strategyFile` names a `.sty` file (such as the team's) that the build's project starts from; `radiant.strategy` sets options by the keys of `prj_set_strategy_value` on top of it. The strategy and the placement seed can be varied in run management.
- **IP:** `radiant.ip` lists `.ipx` modules added to the build.

State: **kit shipped** (builds, a strategy run with a seed); reports modelled on a published real Radiant capture. Radiant gives no power estimate in the Editor.

## Incremental and out-of-context runs

| Option | What it does | State |
|---|---|---|
| `vivado.incremental` | Placement and routing start from the previous routed build, kept in `reference/`, or from a named checkpoint, with a directive. The build writes `report_incremental_reuse`; the panel shows the reuse table, the reference and each stage's timing. **Clear Reference** makes the next run start from scratch | **Kit shipped**; parser tested on a real Vivado 2019.1 report |
| `vivado.outOfContext` | Modules synthesised out of context once, their checkpoints reused in every instance until their sources, constraints or generics change. **Synthesize Out-of-Context Module Again** forces it | **Kit shipped** |
| `quartus.partitions` | Standard Edition partitions with netlist type and preservation, or Pro partitions with `.qdb` reuse and exports; the Fitter's preservation tables appear in the panel and the run history shows how much each build reused | **Kit shipped** (Standard); Pro block-based flow **modelled** |
| `quartus.rapidRecompile` | Turns on Rapid Recompile | **Kit shipped** |

## Licence failures

When a Vivado, Quartus, Libero or Radiant build fails at a FlexNet licence check, the message says which feature failed, where the tool looked and what to set. State: **modelled**.