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?

Another consideration is that it may be necessary to always have some form of data processing occurring, even if that processing does not provide the optimal solution in terms of bandwidth or latency or... whatever. In this case, one option would be to create two dynamically reconfigurable modules and to multiplex between them. This way, one module could be performing the data processing while the other module was being dynamically reconfigured.

Here's another possible scenario. It's very common to have some sort of data processing function that reads in data, does something to it, and stores the result in memory. It's also very common to have a chain of such functions as illustrated in figure 10.

Figure 10: It's very common to have some sort of data processing function that reads in data, does something to it, and stores the result in memory.

In some cases, it may be applicable to have all of the stages present and operating all of the time in a pipeline-type implementation. In other applications, however, it is only necessary to be performing one data processing task at any particular time. In such a case, it would be possible to create the design using a single data processing module and a single block of RAM as illustrated in figure 11.

Figure 11: It would be possible to create the design using a single data processing module and a single block of RAM.

The idea would be to use the first data processing function to perform some action on the data and store the result in the RAM. Then we would use partial dynamic reconfiguration to swap in a new data processing function. This new function would read the data out of the RAM, do whatever it has to do, and store the results back in the RAM. And so on and so forth...

One very important consideration is that today's design tools are not as geared up to supporting partial dynamic configuration as you might hope. In particular, it can be more than a tad tricky to simulate and verify the actual reconfiguration process itself.

Partial dynamic reconfiguration and the Zynq SoC FPGA

Finally, for this column, let's turn our attention to the Zynq SoC FPGA. As you will recall, this little beauty boasts a full hard core implementation of a dual ARM Cortex-A9 microcontroller sub-system augmented with a large quantity of traditional programmable fabric and a substantial number of general-purpose input/output (GPIO) pins.

When the circuit board is powered up, the Zynq's hard ARM Cortex-A9 microcontroller sub-system is automatically ready to rock-and-roll. Furthermore, in most usage scenarios, it is this processor sub-system that is in charge of loading the traditional FPGA fabric, and it performs this using its own dedicated PCAP (Processor Configuration Access Port) as illustrated in figure 12.

Figure 12: It is the processor sub-system that is in charge of loading the traditional FPGA fabric, and it performs this using its own dedicated PCAP.

Now, the main ARM Cortex-A9 processor and its PCAP could also be used to perform dynamic partial reconfiguration. Alternatively, although I've not shown it here, there is also a standard ICAP as part of the programmable fabric. This means that we could use the ARM Cortex-A9 microcontroller sub-system and its PCAP to perform the initial load, and then use user control logic (maybe even a soft core processor) and the ICAP to perform any subsequent partial dynamic reconfiguration functions, while leaving the main processor free to perform other tasks.

Well, that's it for the moment. I know I've only scratched the surface of this subject, but this is quite a lot to wrap one's brain around. There are all sorts of related topics we can consider, such as the use of dynamic partial reconfiguration in creating radiation-tolerant designs, but that's a discussion for another day. In the meantime, do you have any questions with regard to the points presented here?

About the author
Clive "Max" Maxfield is the Editorial Director of Embedded.com and the Embedded Systems Conferences (ESC). Max is also editor of the EE Times Programmable Logic and EE Life Designlines. Max is six feet tall, outrageously handsome, English, and proud of it. In addition to being a hero, trendsetter, and leader of fashion, he is widely regarded as an expert in all aspects of electronics (at least by his mother). Max received his BSc in Control Engineering in 1980 from Sheffield Hallam University in Sheffield, UK. He began his career as a designer of central processing units (CPUs) for mainframe computers. Over the years, Max has designed everything from silicon chips to circuit boards, and from brainwave amplifiers to steampunk "Display-O-Meters." He has also been at the forefront of Electronic Design Automation (EDA) for more than 20 years. Max is the author and/or co-author of a number of books, including Designus Maximus Unleashed (banned in Alabama), Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), EDA: Where Electronics Begins, FPGAs: Instant Access, and How Computers Do Math.


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



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