Serial Vector Format (SVF) is a plain-text file format that describes the JTAG operations needed to program or configure a device, expressed as a sequence of shift and control commands independent of any specific host adapter or tool. An SVF file can be replayed by any compliant SVF player to drive a JTAG chain, provided the player is given a chain configuration that matches the assumptions embedded in the file.
In practice
SVF files are most commonly produced by FPGA vendor tools (Xilinx ISE/Vivado, Intel Quartus, Lattice Diamond, etc.) as an intermediate or portable output format for device programming. A user exports an SVF from their toolchain and then plays it back using a JTAG adapter's built-in SVF player, a standalone utility such as OpenOCD, or a custom test fixture. This decouples the programming step from any proprietary cable driver, which is useful in production and automated test environments.
In practice, SVF is widely used for FPGA configuration (loading a bitstream into a device like a Xilinx Spartan or Lattice ECP5) and for programming on-board flash or CPLDs via JTAG boundary scan. Because the format describes raw JTAG vectors, it is also used in board bring-up and automated test scenarios where a small script must initialize or verify logic without launching a full IDE.
One common pitfall is clock frequency handling: SVF files encode timing through a FREQUENCY directive, but many SVF players silently ignore it or apply a fixed TCK rate. Always verify the player's actual TCK frequency against the device's maximum rated JTAG speed, particularly for voltage-sensitive or frequency-sensitive flash programming sequences. A second pitfall is chain topology: SVF files are typically generated assuming a specific IR length for every device in the JTAG chain. If the actual chain does not match what was assumed when the SVF was generated, IR and DR lengths will be mismatched, which can corrupt addressing and cause programming failures; however, some players allow bypass lengths to be adjusted at playback time without regenerating the file.
SVF is a text format and can be inspected with any editor, which makes it useful for debugging JTAG issues. Each operation is human-readable (SIR, SDR, RUNTEST, etc.), so an engineer can manually trace which state the TAP controller is being driven to and what data is being shifted. XSVF (Xilinx SVF) is a binary, compressed variant of SVF developed by Xilinx for resource-constrained embedded players; the two formats are not the same and cannot be used interchangeably without conversion, though tools exist to translate between them.
Frequently asked
What is the difference between SVF and XSVF?
SVF is an ASCII text format defined by the
JTAG group and supported across multiple vendors and tools. XSVF is a binary, byte-packed variant developed by Xilinx to reduce file size and simplify parsing on embedded microcontrollers with limited RAM and flash. XSVF players are simpler to implement in firmware, but the format is Xilinx-specific and not interchangeable with SVF without conversion.
Can SVF files be used to program any JTAG-accessible device?
SVF can describe
JTAG operations for any TAP-compliant device, including FPGAs, CPLDs, flash memories, and microcontrollers with JTAG ports. However, the SVF file is generated by the vendor tool for a specific device and chain configuration, so it is not portable across different devices or chain topologies without regeneration.
How do I play back an SVF file in an embedded or production environment?
OpenOCD includes a built-in SVF player and supports a wide range of
JTAG adapters (FTDI-based, J-Link, CMSIS-DAP, etc.). Some JTAG adapters (such as Digilent and Lattice programmers) include their own SVF player utilities. For fully embedded in-system programming, an MCU can implement a minimal SVF or XSVF parser in firmware, using a GPIO-bitbanged or
SPI-bridged JTAG interface to drive the target.
Why does SVF programming sometimes fail when extra devices are in the JTAG chain?
SVF files encode the total IR length of all bypass devices assumed to be in the chain. Each device not targeted must be accounted for by shifting the correct number of bypass bits. If the actual chain contains more or fewer devices than assumed when the SVF was generated, IR and DR lengths will be mismatched, causing the TAP controller to enter wrong states or shift data to the wrong device. Regenerate the SVF with the correct chain description, or use a tool that lets you specify IR bypass lengths at playback time.
Is SVF suitable for high-volume production programming?
SVF is used in production, but it has limitations. The format is verbose and uncompressed, so large
FPGA bitstreams produce large SVF files. Playback speed depends on the SVF player implementation and the host TCK rate; some players process vectors slowly due to text parsing overhead. For high-throughput production lines, vendors often provide binary formats (Xilinx BIT/BIN, Intel RBF/JIC, Lattice JED/JEDEC) paired with dedicated programming hardware that is faster than a general-purpose SVF player.
Differentiators vs similar concepts
SVF is often confused with XSVF (Xilinx SVF). SVF is a vendor-neutral ASCII format; XSVF is a Xilinx-specific binary variant optimized for embedded players with constrained resources. SVF is also distinct from device-specific programming image formats such as Xilinx .bit/.bin, Intel .rbf/.jic, or Lattice .jed files: those formats contain only the configuration or programming data, while SVF encodes the full
JTAG transaction sequence (
state machine navigation, IR/DR shifts, wait times) needed to deliver that data to the device.
