The first step is to identify the partially reconfigurable modules (PRMs) in our top-level design. For each of these modules, we must define the interfaces in terms of input and output signals. In our case, we have identified a single PRM, named the demodulator. The following coding describes the demodulator interface:

Given 'n' number of PRMs we need in the current design, the next step is to generate the 'n' PRM netlist files using the XST tools. The output of XST consists of the NGC files. The NGC is a netlist that contains both logical data and constraints. At the end, we have to generate 'n' NGC files. In the event that we will use those NGC files in a partial-reconfiguration project, is necessary to ensure that the IOBUF is disabled.

For our project, we have two NGC files: a 1k and a 2k demodulator. The difference between the two modules is that one has the numerically controlled oscillator (NCO) set at around 1 kHz and the other at around 2 kHz.

Now that we have the two NGC files to use in our system, we have to create a design that will host the PRMs. Using XPS, we build up a system-on-a-chip (SoC), instantiating all the needed modules and controllers via the XPS menu. Additionally, we have to create a black-box IP that will host our PRM modules, previously created by the XST tool. To do that, we can use the option “Create and Import Peripheral Wizard” available in XPS.

In our case, we created a black-box module, named FSKDemodulator, using the appropriate options. The wizard process generates two VHDL files, FSKDemodulator.vhd and User_logic.vhd. The FSKDemodul¬ator.vhd is the top level associated with our PRM modules (demodulator) at the programmable-system level. This file defines the interface of the PRM module with the programmable-system components such as the Peripheral Local Bus (PLB) v4.6. The User_logic.vhd represents the user logic function, and it includes the instance of the PRM module. Once the programmable-system design has been completed, we can generate the NGC file for this configuration.

Using XPS, we defined the programmable-system as well as the general system architecture. It’s important to note that we defined all the PRMs as a black box in XPS.

Using PlanAhead we can merge the outputs and NGC files coming from the two processes, XST and XPS, in order to have just a few PRM bitstreams and a default bitstream. A top-level implementation will be defined and built up using the NGC file from XPS and one of the NGC files from XST. The designer then needs to add a partial-reconfiguration region to the design and must specify the NGC file associated with it. The last step is to promote this configuration in order to make this implementation the default system implementation that will load into the system at startup.

The output of this process will be the default bitstream. To build the PRMs’ bitstream files, we must reopen PlanAhead and, starting from scratch, check the option “PR project” in order to import all the NGC files. PlanAhead will generate a distinct bitstream for each of those PRMs. In our case, it outputs two PRM bitstreams, one for demodulator1k and the other for demodulator2k.

For debug purposes, we suggest creating 'n' (number of PRMs) different static implementations, one for each PRM. In this case the designer will have 'n' static full implementations, each of which will perform the function of the nth PRM statically attached to the FPGA. In our opinion, this is a good compromise between debug needs and development complexity.

The last step is to download the generated bitstream into our target device. You can program the device using the IMPACT tool as well as the command-line data2mem and the Xilinx Microprocessor Debugger (XMD) tool, in case you need to store the bitstream and System ACE file in a CompactFlash. In our case, we opted to program the device by command-line methods, since the ML507 Xilinx board has a CompactFlash on it and the System ACE manages the CompactFlash as a boot device.

Transformable devicesCompared with static reconfiguration, the technique of partial dynamic reconfiguration is extremely efficient in terms of the time it takes for reconfiguration to occur. Although the time is related to the physical dimensions of the PRMs, if these modules can be smaller than the full bitstream by even one gain factor, that implies a time of reconfiguration of tens vs. hundreds of milliseconds. The use of PDR brings FPGA system design to another level, giving the designer an opportunity to drastically reduce the power consumption and the cost of a whole system.

In the context of the EU’s pSHIELD research project, where design criteria such as security, privacy and dependability are the main factors, we found the PDR technique extremely useful. The possibility of changing a cryptographic algorithm or communication protocol on the fly while keeping the other functionality alive was a big advantage. With this approach, we think that the FPGA is going to usher in a new era in electronic design. We are envisioning systems that can change their functionality and adapt themselves to a specific scenario or threat. In short, we are thinking of a world made up of transformable devices.

About the authorsFabio Giovagnini is a Software Manager at Aurion S.r.l., SESM S.C.A.R.L. Fabio can be contacted at fabio.giovagnini@gmail.com

Antonio Di Marzo is an Embedded System Dept. Manager at SESM S.C.A.R.L. Antonio can be contacted at adimarzo@sesm.it

If you found this article to be of interest, visit Programmable Logic Designline where – in addition to my Max's Cool Beans blogs – you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).

Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).