Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > FPGAs/PLDs
?
?
FPGAs/PLDs??

The MCU guy's guide to FPGAs: Configuration

Posted: 15 Jun 2015 ?? ?Print Version ?Bookmark and Share

Keywords:MCU? FPGA? programmable logic? one-time programmable? antifuse?

Irrespective of the configuration mode used (serial, parallel, FPGA as master or slave, JTAG), the configuration bitstream ends up being fed into the Configuration Engine, which is in charge of loading the configuration data into the FPGA's configuration cells.

Dynamic partial reconfiguration
We often talk about how one of the major advantages of SRAM-based FPGAs is the fact that they can be configured and reconfigured to perform whatever tasks we wish, unlike fixed-function devices like ASICs/ASSPs/SoCs, whose algorithms are effectively "frozen in silicon." Thus far, however, we've really not explored just how powerful SRAM-based reconfiguration technology can be. As usual, of course, there's more to this than initially meets the eye, and it's easy to become confused, so I hope you won't mind if I take this step-by-step as follows...

Full-chip configuration
Let's start right at the beginning. The typical design flow is that we use some technique to capture our design intent. We then simulate the design to check that it does what we want it to do. Next, we run the design through logic synthesis, then place-and-route, and eventually we end up with a configuration file. Later, when we power up the circuit board, we load the configuration bitstream from the configuration file into the FPGA.

For the moment, let's assume that our FPGA does not contain a hard core processor. In this case, as we discussed earlier, there are a number of ways in which we can load the configuration bitstream into the FPGA. Furthermore, as you may recall, the configuration engine is a small function that is implemented as a hard core on the FPGA as illustrated in figure 6.

Figure 6: The configuration engine is a small function that is implemented as a hard core on the FPGA.

Irrespective of the configuration mode used (serial or parallel, FPGA as master or slave, or JTAG), the configuration bitstream ends up being fed into the configuration engine, which is in charge of loading the configuration data into the FPGA's configuration cells. In particular, observe that!in the case of full-chip configuration!the FPGA can be instructed to act as the "master" or the "slave" (the significance of this point will become apparent shortly).

Full-chip reconfiguration
In many cases, once we've powered up the board and loaded a configuration into the FPGA, that's all we have to do!we simply leave the FPGA running and "doing its thing." In some cases, however, we might decide to re-load the FPGA with a completely different configuration. As one example of this, upon power up we might first load the FPGA with a configuration that performs self-test and perhaps some amount of board-level test. Once we are satisfied that everything is as it should be, we can reload the FPGA with a completely different configuration.

To a large extent, we can treat this type of situation as comprising a number of completely separate designs that are developed and verified in isolation!it just so happens that these multiple designs end up running in the same physical device. The point I'm making here is that full-chip reconfiguration does not really require any extra features or capabilities in the design tools.

Static partial reconfiguration
To be fair, I really have to note that the term "static partial reconfiguration" is not in common usage!in fact, to be completely honest, it's pretty much a term I made up just a few moments ago. What I'm trying to convey here is that it is possible to place the FPGA into a reset state, hold it there (this would be the "static" part), swap out a portion of the design, and then allow the FPGA to continue on its way.

Dynamic partial reconfiguration
This is where things start to become very exciting. The idea is that we leave the FPGA running while we are performing the partial reconfiguration. We don't clear the device or put it into a reset mode, and we don't disrupt any of its contents (apart from the portion we're reconfiguring, of course).

However, this does mean that that it's up to the designer to ensure that we stop using the portion of the FPGA that's being reconfigured while it's being reconfigured. We can visualise this as being the FPGA equivalent of a "hot swap" capability.

Partial reconfiguration using traditional techniques
Now, I'm not saying that this is a good idea, but it is certainly possible to perform partial reconfiguration using traditional configuration techniques, as illustrated in the image below. The important point to note here is that!in the case of partial reconfiguration!the FPGA can act only as a "slave" (not as a "master"). The reason for this is that when undergoing configuration in in its "master" mode, the FPGA cannot stop itself from performing certain operations that would not be friendly to a partial reconfiguration scenario.

Figure 7: Partial reconfiguration.


?First Page?Previous Page 1???2???3???4???5?Next Page?Last Page



Article Comments - The MCU guy's guide to FPGAs: Config...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top