Cheap in-system FGPA programming

[asmi]

Xilinx provides an appnote (XAPP583) with sample code on how to boot their FPGAs using MCU. Practically if bitstream doesn't require often updates, I'd just implement it the standard way - put it on QSPI flash, and whenever I needed to update it - I would program FPGA to become a bridge of sorts between AP and FPGA, and write it to flash indirectly via said FPGA. Kinda like what Xilinx and Digilent programmers are doing when programming flash from within Vivado.

[technix]

Sure, hence all the "ifs" in my last paragraph. I just think it would be the faster option if it's possible. One additional thing is that yes, MachXO2/3 and iCE40 support SPI slave configuration, but (correct me if I'm wrong) I don't think the Xilinx parts do. So it would also all depend on the FPGA you select.

Xilinx and Intel parts all supports SPI slave mode, at least recent ones like Spartan 6 and above.

One last remark and, really obvious one, but we don't know what the FPGA is going to be used for. In the system, it may be required to be fully operational after a short while and BEFORE the SoC would have ended its booting and gotten a chance to upload the bitstream to the FPGA. Of course in that case, unless you're using a very lightweight OS which boots blazingly fast or you are using it bare metal, using an FPGA with embedded Flash (or using an external Flash IC) would be the only viable option. The SoC could then just update the Flash content if needed.

If the SoC intends to run Linux, the FPGA can be initialized within u-boot. u-boot being a bootloader means it does not require much to start up, and it also means that FPGA would be reliably booted up before kernel loads.

[legacy]

I have here a Blackfin board made by NOVA System, it also has a tiny FPGA on it. The DSP loads a customized version of u-boot, which is able to (upload a file from the network in order to) "program" the flash from which the FPGA does boot. Once programmed, it sends a reset signal to both chips, and the DSP and FPGA bootstrap singularly and in parallel.

p.s.
Note there are three SPI-flash chips on the PCB. The first is used for the bootstrapping of the DSP, the second is used for the booting of the FPGA, and the third is used as "fail-safe".

SPI-flash0: DSP firmware, u-boot + RTOS
SPI-flash1: FPGA bitstream
SPI-flash2: DSP fail-safe, u-boot stable version
(default configuration)

u-boot is able to program both the DSP's flash and the FPGA's flash, and there is a "fail-safe" procedure, so you accidentally reprograming the DSP's flash with the wrong file, you can always set a jumper to swap the first and the third SPI-flash.

'SPI-flash0: DSP fail-safe, u-boot stable version
SPI-flash1: FPGA's bitstream
'SPI-flash2: DSP firmware, u-boot + RTOS <----------- garbage, it needs to be reprogrammed!
(with the "fail-safe juper" set)

edit:
typos

[Harvs]

Hi all,

Obviously I missed a bunch of discussion here after the thread was dormant for a while.

The application is pretty straightforward.  The FPGA is just coordinating time sync'd sampling from multiple ADCs, packetizing it, then streaming that into the SoC via SPI and DMA on the SoC.  No fast on-time requirements.

The ICE40 fills the design requirements very well, and given it can have the bitstream loaded over SPI with the FPGA as a slave, I can't see any better way of doing it.  As Mike pointed out, keeping the SoC software and FPGA bitstream together makes update management a breese.

Interesting discussion though.

[technix]

As Mike pointed out, keeping the SoC software and FPGA bitstream together makes update management a breese.

If you wired up the FPGA allowing the SoC to reset and reinitialize it using a GPIO pin, you can even hot-patch the bitstream.

A UNIX-like OS like Linux allows software be updated without the whole system being rebooted as long as the kernel and maybe libc is not touched (with recent kernels libc hot patching is possible, even kernel hot patching is doable to some extent.) With that GPIO pin your software can reset the FPGA upon launch, upload the bitstream and do its thing. Since the FPGA is reset whenever the software launches, the software update can immediately take effect without a full system reboot whenever your software relaunches. If you decoupled the user interface from the software that actually interfaces the FPGA, updates can be a seamless experience.

[SiliconWizard]

Sure, hence all the "ifs" in my last paragraph. I just think it would be the faster option if it's possible. One additional thing is that yes, MachXO2/3 and iCE40 support SPI slave configuration, but (correct me if I'm wrong) I don't think the Xilinx parts do. So it would also all depend on the FPGA you select.

Xilinx and Intel parts all supports SPI slave mode, at least recent ones like Spartan 6 and above.

OK thanks for the info. Never had to use this on Xilinx parts and was not sure it was even supported. That's good to know!

One last remark and, really obvious one, but we don't know what the FPGA is going to be used for. In the system, it may be required to be fully operational after a short while and BEFORE the SoC would have ended its booting and gotten a chance to upload the bitstream to the FPGA. Of course in that case, unless you're using a very lightweight OS which boots blazingly fast or you are using it bare metal, using an FPGA with embedded Flash (or using an external Flash IC) would be the only viable option. The SoC could then just update the Flash content if needed.

If the SoC intends to run Linux, the FPGA can be initialized within u-boot. u-boot being a bootloader means it does not require much to start up, and it also means that FPGA would be reliably booted up before kernel loads.

Interesting. I suppose that would entail having to meddle with u-boot? Or is it easily configurable? I don't know much about how u-boot works.

[technix]

Interesting. I suppose that would entail having to meddle with u-boot? Or is it easily configurable? I don't know much about how u-boot works.

Unless you are using kernel drivers for FPGA components, it is usually a better idea to defer FPGA configuration until you have a userland environment on SoC.

If you really want to do that, you need a u-boot driver that would write contents from a given memory address and length to the FPGA over some mechanism, for example SPI. Then existing u-boot mechanism allows you to load the bitstream file from a storage device, and invoke this driver to configure the FPGA. Research u-boot source code before coding your own though as that might have already been implemented.

[SiliconWizard]

OK thanks. Not something I would want to bother with I guess, unless I absolutely had to.

If I needed the FPGA to be ready early, I would just use a Flash chip I think, and just add means to reprogram the flash for updates...

[technix]

If I needed the FPGA to be ready early, I would just use a Flash chip I think, and just add means to reprogram the flash for updates...

You actually have a race hazard if FPGA and SoC boots individually: the SoC have little to no clue when would the FPGA actually finish loading the bitstream and booted, and should FPGA boot failed SoC would have little means to recover it. If you use SoC to bring up the FPGA, SoC code knows exactly when the FPGA is ready.

[mikeselectricstuff]

If I needed the FPGA to be ready early, I would just use a Flash chip I think, and just add means to reprogram the flash for updates...

You actually have a race hazard if FPGA and SoC boots individually: the SoC have little to no clue when would the FPGA actually finish loading the bitstream and booted, and should FPGA boot failed SoC would have little means to recover it. If you use SoC to bring up the FPGA, SoC code knows exactly when the FPGA is ready.

The SoC could have  an input to monitor the FPGA config state - you could have a system which normally boots the FPGA from flash to get some early functionality , and can be subsequently soft- reloaded  for the main functionality and/or the flash updated when the system has started

[legacy]

The SoC could have  an input to monitor the FPGA config state - you could have a system which normally boots the FPGA from flash to get some early functionality , and can be subsequently soft- reloaded  for the main functionality and/or the flash updated when the system has started

The DSP on the NOVA's board bootstrap an RTOS. Sure, the DSP and the FPGA do bootstrap singularly and in parallel, but there is a pin between the FPGA and the DSP; it's called "ready", and it means the FPGA has completed its initialization and it's running correctly. When the FPGA is power up the pin is down, and it only goes high only when the FPGA will complete the bootstrap and the finite state machine will have completed its early cycle. Here is where the HDL code plays its rules about initializing things. Besides, there are two latches programmed in the FPGA to tell about the hardware status. These is used by the "probe" functions in the kernel drivers.

Linux is more complex than an RTOS, but there is no problem at all 

[technix]

The SoC could have  an input to monitor the FPGA config state - you could have a system which normally boots the FPGA from flash to get some early functionality , and can be subsequently soft- reloaded  for the main functionality and/or the flash updated when the system has started

The DSP on the NOVA's board bootstrap an RTOS. Sure, the DSP and the FPGA do bootstrap singularly and in parallel, but there is a pin between the FPGA and the DSP; it's called "ready", and it means the FPGA has completed its initialization and it's running correctly. When the FPGA is power up the pin is down, and it only goes high only when the FPGA will complete the bootstrap and the finite state machine will have completed its early cycle. Here is where the HDL code plays its rules about initializing things. Besides, there are two latches programmed in the FPGA to tell about the hardware status. These is used by the "probe" functions in the kernel drivers.

Linux is more complex than an RTOS, but there is no problem at all 

READY pin provide no mechanism for recovering from a failed boot on the FPGA though. Any kind of slave port, be it JTAG or SPI, removes that point of failure as the SoC can recover the FPGA.

[NorthGuy]

Emulating 100 MHz QSPI flash is not an easy task. Real QSPI flash costs less than a dollar.

[SiliconWizard]

READY pin provide no mechanism for recovering from a failed boot on the FPGA though. Any kind of slave port, be it JTAG or SPI, removes that point of failure as the SoC can recover the FPGA.

So? Most circuits involvings FPGAs are designed like that. How often does an FPGA config from external flash fails? Not a huge point of concern. As long as you can detect the failure.

And as I suggested above, the simplest, fastest (configuration time wise) approach overall and still most flexible would be to use an external SPI/QSPI flash AND still implement JTAG.
The host can monitor the Config ready pin. If it doesn't show a ready state after a given time-out, the host can then reflash it through JTAG and/or proceed to some other automated testing.

So as I said before, if config time was critical, I personally would favor this approach for large bitstreams. For the smaller FPGAs, SPI slave would be probably adequate. Then again, as the OP suggested using MachXO3, if again it should be ready in a very short time, I would just buy the flash version, and implement reprogramming for updates through JTAG probably.

Again it's all in the requirements and use cases!
If, OTOH, config time is not critical, but you needed to be able to reconfigure the FPGA very often (maybe even "on the fly" depending on the system's state), obviously the SPI or JTAG only approach would be favored. Can also be a mix of both, and you can certainly do both with my suggestion of external (or internal if supported) flash + JTAG, and mikeselectricstuff's suggestion to monitor the config ready pin is definitely a good idea.

[technix]

Emulating 100 MHz QSPI flash is not an easy task. Real QSPI flash costs less than a dollar.

But I can DMA data from SoC memory to hardware SPI and have it piped out at ~120MHz if my SoC allows it. Ever heard of sendfile(2), can determine how to DMA files all within kernel mode?

[legacy]

READY pin provide no mechanism for recovering from a failed boot on the FPGA though. Any kind of slave port, be it JTAG or SPI, removes that point of failure as the SoC can recover the FPGA.

If the SPI-flash is programmed with the right bitstream, failed boots can only happen if there is an hardware problem, and there is anything the SOC can do to recover it in this case. The SOC can only issue a reset to the FPGA via GPIO, this will force the FPGA to reboot.