Build with Vivado, Quartus, Libero and Radiant

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.

Targets

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

Vendor-specific options live in the target's vivado, quartus, libero and radiant blocks; see Reference.

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

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

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.

Libero SoC flow steps for a PolarFire target run one at a time, with utilisation and clocks

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

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.