I have an FPGA system with JTAG connection, and for production I need to use JTAG to program the FPGA configuration flash, that is connected to the FPGA.
The JTAG connection is standard IEEE 1149.1 and the FPGA programming should be possible using standard IEEE 1532.
However, I have not been able to find a standard method for programming the FPGA configuration flash connected to the FPGA.
So, is there a standard way over JTAG to program flash connected to an FPGA?
The real issue is that there are many kinds of configuration flashes.
Run of the mill NOR flash (the 25xxx parts, usually) simply has no JTAG so no luck.
The so called 'platform flash' (at least Xilinx call it that way) is JTAG connected but the protocol is manufacturer dependent (in fact I don't know if someone else does that other than Xilinx). Also IMHO platform flash is too expensive for what it does.
The usual way at least on Altera is just to load via JTAG a temporary bitstream on the FPGA that talks on the SPI to the NOR memory. Not standard unless you call 'standard' for a family of FPGA.
In short: there is no standard way since there is no standard flash with a JTAG port
At least for Xilinx, the flash programming happens in two stages:
Your JTAG host will need to have awareness of this flow, including the driver to properly access the flash.
In reality it’s probably easier to just provide a PC that has Vivado (or whatever tool) lab version installed for this process. Or, pre-program your device before soldering it onto your board. (From experience this method is the most cost-efficient for production.)
Another option is to use a SPI programmer directly attached to the flash pins.
Your system should if possible provide a means to reprogram in the field using an embedded SPI controller. This can save you from having to recall the board if you have to reprogram the bitstream. This will be faster than using JTAG if your system has a decently-speedy interface such as USB or PCI Express.
SVF or XSVF, generated by the FPGA tools and executed by your boundary scan tools is about as "standard" as you're going to get. But I think this applies to flashing just about anything over JTAG; JTAG doesn't standardize much of anything beyond boundary scan, so any device with nonvolatile memory is going to have its own method for accessing that memory for programming.
The problem is that there are many confounding factors involved here, and it's going to be very device and configuration dependent.
Some FPGAs with integrated flash may be able to be programmed relatively directly via JTAG, if they provide direct access to the configuration flash over JTAG. This kind of device is probably the most straightforward in this respect, but this type of device isn't particularly common and you're probably going to have to use SVF/XSVF or similar anyway if your boundary scan software doesn't know how to talk to the FPGA.
The much more common case is an FPGA with external configuration flash, and for a variety of reasons most FPGAs do not provide direct access to the config flash from JTAG. Instead, the flash is almost invariably programmed "indirectly" by loading a design onto the FPGA that provides a bridge between the JTAG interface and the flash chip. So in this case, it becomes a two-step process: configure the FPGA via JTAG, then write the config flash. I think most FPGA tools will be able to export SVF/XSVF with the raw JTAG commands to do this. Another factor to consider is hardware security components, such as the secure device manager (SDM) on Intel FPGAs, may make the flashing process significantly more complicated.
Another potential option may be program the flash via boundary scan. I think some software is capable of essentially bit banging the flash interface via the boundary scan registers. It's incredibly slow, but it does bypass the need to load a configuration onto the FPGA to connect the JTAG chain to the flash interface. I think openocd may support this for several kinds of flash chips, effectively independent of the device it's connected to, so long as it supports JTAG boundary scan in those pins.
Another potential thing to consider, though: is JTAG really the most appropriate method? For example, it can take Vivado quite a long time to write to a config flash via indirect JTAG due to the limited speed of the JTAG scan chain. It might be much faster to, say, load an initial design via JTAG, then perform the actual flashing through some other interface (PCIe, Ethernet, USB, etc.). If you have some infrastructure for updating the flash in the field, it could make sense to take advantage of that during the initial flashing of the board - for instance, load the design onto the FPGA via JTAG, but then use some other interface (PCIe, USB, Ethernet, etc.) for the actual flashing.
