Write already-built hardware artifacts to a board. Project creation, IP configuration, synthesis, implementation and bitstream generation are covered in Project creation and builds.

SRAM versus Flash

Choose an action under HARD Options → Program:

Action	Destination	After power loss	Use
SRAM	Volatile FPGA configuration memory	Configuration is lost	Quickly test a new design on the board.
FLASH	Nonvolatile configuration memory	Image remains and loads according to the board's boot mode	Run automatically after power-up.

Before programming

1. Verify a successful build, the correct device/top/constraints and current artifacts.
2. Power the board, connect a supported programming/JTAG interface and check tool/driver detection.
3. With Remote SSH, the board and tools must be accessible to the remote host or a configured reachable hardware service.
4. With multiple boards or targets, identify the intended hardware before proceeding.

Xilinx SRAM programming

The video demonstrates HARD Options → Program → SRAM with JTAG status readback, followed by configuring flash in .vscode/property.json and the Program → FLASH workflow:

1. Check toolChain: "xilinx", the actual device and Vivado path.
2. Verify <prjName.PL>.bit in the workspace root belongs to the current successful build. The current flow uses this file rather than searching arbitrary output directories.
3. Select HARD Options → Program → SRAM.
4. In Output → Digital-IDE Hardware, confirm hardware/program: completed and independent JTAG status readback (DONE=1, INIT_B=1, CRC_ERROR=0), then check LEDs, UART or other expected behavior separately.

The current flow enumerates targets through Vivado hardware services and matches the configured device prefix. A prefix cannot distinguish multiple boards with identical devices; establish the intended target and connection scope first.

See the Xilinx full-flow demonstration for stage-by-stage log checks and post-programming DONE, INIT_B and CRC readback.

Xilinx Flash programming

Describe the board's configuration memory

Set flash in .vscode/property.json to specify the board's configuration memory chip (distinct from the FPGA device):

{
  "flash": {
    "part": "w25q128fv-spi-x1_x2_x4",
    "interface": "SPIx4",
    "sizeMB": 16,
    "format": "mcs",
    "verify": true
  }
}

Use an actual chip identifier supported by Vivado get_cfgmem_parts. Match interface to board wiring. Capacity is in MBytes: 128 Mbit is 16 MB. See the field reference.

Part names depend on the device family. The w25q128fv-spi-x1_x2_x4 example is an SPI configuration memory for PL-only devices such as Artix-7; Zynq-7000 uses QSPI parts, for example w25q128fv-qspi-x4-single for xc7z010. List the parts supported by your device with get_cfgmem_parts -of_objects [get_parts <device>] in the Vivado Tcl console.

Program and test boot

1. Validate the current bitstream through SRAM programming first.
2. Save the board's Flash configuration and select HARD Options → Program → FLASH.
3. Wait for the Hardware programFlash completed notification; Output shows the memory part, interface, generated .mcs/.bin image and verification result.
4. Set the board's boot mode switches/jumpers to Flash boot and power-cycle the board to verify automatic startup.

Zynq cannot boot the PL alone from flash

On Zynq-7000 / ZynqMP the PS boots first and the FSBL then loads the PL bitstream, so writing only the .bit to QSPI does not boot the design. Build the processor-specific FSBL in SOFT Options (Zynq FSBL for Zynq-7000, Zynq MP FSBL for ZynqMP), package the FSBL and .bit (plus any application ELF) into BOOT.bin with bootgen, write it to QSPI, and set the boot mode to QSPI.

Efinix programming

Confirm the mode using Project creation and builds:

Mode	Current behavior
Original Efinity installation	Extension Launch/Refresh generates vendor project/interface files. Continue builds and programming in original Efinity; extension SRAM/FLASH actions are not implemented in this mode.
Self-contained package	Supports Titanium series devices over DIDE high-speed JTAG for in-extension Program → SRAM and Program → FLASH.

For package mode:

1. Clear the original installation path, set digital-ide.prj.efinix.package.path to a valid self-contained package, and build the current design.
2. Default outputs are under prj/efinity/outflow/. SRAM uses <name>.bit. FLASH uses <name>.hex plus the matching .bit for SRAM restoration.
3. Connect supported DIDE high-speed JTAG and test Program → SRAM.
4. Select Program → FLASH. The flow reads IDCODE, selects the official loader from the package, programs and fully verifies SPI Active Flash, then restores SRAM. Resolve missing or mismatched loaders before continuing.
5. Check task status and power-cycle with the board's intended boot mode.

This flow does not use Xilinx flash.part, MCS or get_cfgmem_parts. Keep the vendors' images, memory configuration and pin constraints separate.

Troubleshooting

Symptom	Check
No hardware target	Power, cables, drivers, hardware services and which host has the board connection.
Missing bitstream	Current artifact, prjName.PL, expected filename and output directory.
Programming succeeds but behavior is wrong	Top module, clock/reset polarity, pin location and voltage constraints in XDC/SDC.
SRAM works but boot fails after power loss	Actual Flash programming result, image and boot-mode selection.
Unsupported Efinity action	Original/package mode, supported device family and JTAG connection.

Project builds · Configuration reference · SDK · ILA/VIO debugging