Partial reconfiguration of FPGA on the fly

[SiliconWizard]

Has anyone tried/achieved something like that?
A partial reconfiguration of some FPGA "on the fly", ie. while it is operating, without requiring a full reset.
Could be via JTAG, either by an external device such as a MCU, or by the FPGA itself.

Is this possible? Just musing over that.

[asmi]

I didn't try it myself, but it's absolutely possible. Xilinx used to call this "partial reconfiguration", now I think it's called "dynamic function exchange" or something like that.  Just Google this phrase, and you will get plenty of information.

[SiliconWizard]

Indeed, they have a page on that: https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0017-vivado-partial-reconfiguration-hub.html
I'll have a look.

[asmi]

There are some really good videos on YT for that, check them out if you have some spare time. Basically the way this works is that you define an interface boundary which is both logical AND physical, and then you design a bunch of interchangeable modules which all have the same logical and physical layout at the boundary. Xilinx themselves used this trick to work around PCIE boot time limitations - basically the problem is that PCI Express specification demands that an endpoint device becomes responsive to a bus transactions within a fixed timeout after power up, and larger FPGAs just could not transfer bitstream fast enough from the storage, much less to actually boot in that time, so what they came up with is booting a super-barebones bitstream which is just enough to make a PCIE bus functional, and then booting the actual application bitstream either from another source, or over PCIE via driver - kinda like what most modern WiFi/BT chipsets are doing. They call it "Tandem Configuration". Here is a quicktake video about that:

[nctnico]

From my analysis it looks like some GW Instek scopes use partial reconfiguration to change the trigger engine in the Xilinx Zync FPGA.

[SiliconWizard]

From my analysis it looks like some GW Instek scopes use partial reconfiguration to change the trigger engine in the Xilinx Zync FPGA.

Are you sure? Given that the Zynq has an embedded ARM CPU, is it possible that it just reconfigures the whole FPGA part rather than just partially?

A partial reconfiguration is obviously more complex  than a complete reconfiguration via JTAG and would be justified only if 1/ you have no other programmable logic to reconfigure the FPGA, and/or 2/ the partial reconfiguration must be done very quickly, and/or 3/ the current state of some part of the FPGA must be retained (the last part could probably be emulated just after reconfiguring it though.)

[tom66]

You can completely reflash a Zynq via Linux in well under 1 second, the limitation more than anything is the speed you can read it from your memory device. GW are probably just completely reprogramming the device for different configurations.  I believe Rigol do that too.

[SiliconWizard]

You can completely reflash a Zynq via Linux in well under 1 second, the limitation more than anything is the speed you can read it from your memory device. GW are probably just completely reprogramming the device for different configurations.  I believe Rigol do that too.

I would think so too.

[ejeffrey]

Partial reconfiguration makes more sense on FPGAs that don't have a hard processor.  In that case you may need to use FPGA logic such as a soft processor or PCIe endpoint to load the configuration data.  I believe Amazon uses this for their FPGA AWS instances.  The FPGA has a base configuration in flash that implements the PCIe interface and includes a mechanism to load a partial reconfiguration for the users application.

[asmi]

I think PR would work great for oscilloscopes because they got many mutually-exclusive functions - for example various digital triggers or protocol analyzers. If you've got a single Zynq chip for everything, you can't reconfigure it entirely because there would need to be a block which outputs image on the screen (otherwise you would not show anything on the screen during reprogramming and startup), but I can totally see how some other parts of processing pipeline can be swapped around. This also allows to use smaller density devices then you would need if all functions would be implemented at the same time.

[SiliconWizard]

I think PR would work great for oscilloscopes because they got many mutually-exclusive functions - for example various digital triggers or protocol analyzers. If you've got a single Zynq chip for everything, you can't reconfigure it entirely because there would need to be a block which outputs image on the screen (otherwise you would not show anything on the screen during reprogramming and startup), but I can totally see how some other parts of processing pipeline can be swapped around. This also allows to use smaller density devices then you would need if all functions would be implemented at the same time.

Yep. Requiring some part of the FPGA to run at all times without any interruption (even if it's relatively short), along with minimizing the device size is indeed one reason for doing that and the use case I had in mind.

[asmi]

Yep. Requiring some part of the FPGA to run at all times without any interruption (even if it's relatively short), along with minimizing the device size is indeed one reason for doing that and the use case I had in mind.

This used to be a premium feature only available with paid Vivado licenses, but a few years ago Xilinx made it available with free license as well. I personally think it's a super-cool feature, even if with niche uses, because it takes full advantage of FPGA volatility. Some hardware blocks of 7 series FPGAs have what they call a DRP - "dynamic reconfiguration port", which is CPU-style bus (clock, address, read/write enable, data in/data out) that allows changing behavior of those blocks at runtime. For example, you can reprogram PLL at runtime to change it's output frequency using that port, or change behavior of MGT blocks. Unfortunately, this function is almost entirely undocumented, you would have to scavenge information across many different application notes, but to be fair they've got examples and appnotes for many typical usage scenarios.

[helius]

FPGAs can also be "dynamic" in the sense of selecting a function or LUT on the basis of a signal input and reselecting at a high clock frequency. The ABAX2 from defunct Tabula was of that type (they called it "3D FPGA" with time as the "3rd dimension").

[Forty-Bot]

If you've got a single Zynq chip for everything, you can't reconfigure it entirely because there would need to be a block which outputs image on the screen

The PS side typically handles graphics, so you should be fine when reconfiguring the PL.

[asmi]

The PS side typically handles graphics, so you should be fine when reconfiguring the PL.

PS side can't possibly handle graphics as there is no hardware in Zynq for video output.

[mascotte]

I wrote a PhD thesis on that (long time ago, targeting Virtex-4)  I used partial reconfiguration to implement modular redundancy for mitigating radiation-induced errors in the configuration memory (space application). Once a failure was detected in one of the partitions, the partition was reconfigured on the fly. It works really well and can be really fast (using e.g. the parallel SelectMAP interface), you just have to make sure that your partition is isolated from the rest of your design during reconfiguration, as the newly written configuration bits become directly active and therefore the partition outputs are unstable during this period.

[Forty-Bot]

The PS side typically handles graphics, so you should be fine when reconfiguring the PL.

PS side can't possibly handle graphics as there is no hardware in Zynq for video output.

Hm, I am used to ZynqMP, which does have PS graphics.

[nctnico]

From my analysis it looks like some GW Instek scopes use partial reconfiguration to change the trigger engine in the Xilinx Zync FPGA.

Are you sure? Given that the Zynq has an embedded ARM CPU, is it possible that it just reconfigures the whole FPGA part rather than just partially?

I can't acces the info right now (no time to figure out how to mount/read the UBI firmware image) but from memory I recall there are several small FPGA configuration files with the various trigger modes. So I'm 75% sure it does a partial configuration.

[SiliconWizard]

If the FPGA SoC doesn't have a dedicated video processor as asmi pointed out, then yes in all likelihood video is handled by the FPGA and thus interrupting it would interrupt the display, which in itself would be a good reason for doing a partial reconfiguration. Having the scope screen go blank every time you change some parameter would really not look good.

[nctnico]

It looks like the Xilinx marketing term you are looking for is 'dynamic reconfiguration'.

Don't know if you have found this, but it looks like it should answer your questions.
https://docs.xilinx.com/r/en-US/ug909-vivado-partial-reconfiguration/Effective-Approaches-for-Implementation

All in all it looks like you can reconfigure an FPGA on-the-fly (as I would expect because the configuration bitstream has addresses inside that tell where the data should go) where the 'core logic' remains running and only a module is being changed.

[SiliconWizard]

It looks like the Xilinx marketing term you are looking for is 'dynamic reconfiguration'.

Don't know if you have found this, but it looks like it should answer your questions.
https://docs.xilinx.com/r/en-US/ug909-vivado-partial-reconfiguration/Effective-Approaches-for-Implementation

Have you read the 2nd and 3rd posts in this thread?

[nctnico]

It looks like the Xilinx marketing term you are looking for is 'dynamic reconfiguration'.

Don't know if you have found this, but it looks like it should answer your questions.
https://docs.xilinx.com/r/en-US/ug909-vivado-partial-reconfiguration/Effective-Approaches-for-Implementation

Have you read the 2nd and 3rd posts in this thread?

No (was away for a while) but then why still question if it is possible without interruption? The page tells you it can be done without interrupting the rest of the logic 

[SiliconWizard]

It looks like the Xilinx marketing term you are looking for is 'dynamic reconfiguration'.

Don't know if you have found this, but it looks like it should answer your questions.
https://docs.xilinx.com/r/en-US/ug909-vivado-partial-reconfiguration/Effective-Approaches-for-Implementation

Have you read the 2nd and 3rd posts in this thread?

No (was away for a while) but then why still question if it is possible without interruption? The page tells you it can be done without interrupting the rest of the logic 

Have you really read any of what I wrote?
 

[colorado.rob]

Has anyone tried/achieved something like that?
A partial reconfiguration of some FPGA "on the fly", ie. while it is operating, without requiring a full reset.
Could be via JTAG, either by an external device such as a MCU, or by the FPGA itself.

Is this possible? Just musing over that.

Yes. It is possible. I have done it with Zynq via MCU. Certainly possible. It is trivial to do and well documented for Pynq.

https://pynq.readthedocs.io/en/v2.4/pynq_overlays/partial_reconfiguration.html

I tried it out on a trivial project. It worked. I did not have any real need for it because it was easier to just swap out complete bitstreams on Pynq.

[colorado.rob]

Has anyone tried/achieved something like that?
A partial reconfiguration of some FPGA "on the fly", ie. while it is operating, without requiring a full reset.
Could be via JTAG, either by an external device such as a MCU, or by the FPGA itself.

Is this possible? Just musing over that.

Yes. It is possible. I have done it with Zynq via MCU. Certainly possible. It is trivial to do and well documented for Pynq.

https://pynq.readthedocs.io/en/v2.4/pynq_overlays/partial_reconfiguration.html

I tried it out on a trivial project. It worked. I did not have any real need for it because it was easier to just swap out complete bitstreams on Pynq.

And to your point about "without interruption", yes, if you have "blinky" running in the FPGA (outside the partial reconfig area), it will continue to run while doing partial reconfig.