UPaRC—Ultra-Fast Power-aware ReconfigurationController

Robin Bonamy, Hung-Manh Pham, Sebastien Pillement, and Daniel ChilletUniversity of Rennes 1 – CAIRN IRISA/INRIA,

6 rue de KerampontF-22300 Lannion

firstname.lastname@irisa.fr

Abstract—Dynamically reconfigurable architectures,which can offer high performance, are increasingly usedin different domains. High-speed reconfiguration pro-cess can be carried out by operating at high frequencybut can also augment the power consumption. Thus theeffort on increasing performance by accelerating the re-configuration should take into account power consump-tion constraints. In this paper, we present an ultra-fast power-aware reconfiguration controller (UPaRC)to boost the reconfiguration throughput up to 1.433GB/s. UPaRC can not only enhance the system perfor-mance, but also auto-adapt to various performance andconsumption conditions. This could enlarge the range ofapplications and optimize for each selected applicationduring run-time. An investigation of reconfigurationbandwidths at different frequencies and with differentbitstream sizes are experimentally quantified and pre-sented. The power consumption measurements are alsorealized to emphasize energy-efficiency of UPaRC overstate-of-the-art reconfiguration controllers—up to 45times more efficient.

Index Terms—dynamic partial reconfiguration, rapidreconfiguration speed, power consumption, ICAP

I. Introduction

Reconfigurable architectures like FPGAs are well knownto be able to design flexible, high-performance systemswith high scalability at low development cost. Partialreconfiguration, the feature to modify on-the-fly a partof the circuit without interrupting the rest, enhances yetthe above advantages while offering a more energy-efficientsolution thanks to hardware resources sharing [1]. Theauto-adaptation using partial reconfiguration is usuallyhandled by a reconfiguration controller which loads thepartial bitstream to the reconfiguration port to modifythe functionality of a part on the FPGA. That requires acontroller to drive the reconfiguration process. This partialmodification does not affect the rest of the circuit butthe area to be modified is inactive during reconfiguration.A long inactive period of a part inside a system maybe prohibited in certain applications especially in high-performance or fault-tolerant systems. Thus the reconfigu-ration controller should provide high reconfiguration speedto accelerate the hardware adaptation.

978-3-9810801-8-6/DATE12/ c©2012 EDAA

One possible solution is to increase the operation fre-quency of the reconfiguration controller, but power con-sumption increases along with the frequency which iscontrary to actual efforts on power reduction. Moreover,power consumption is a key parameter in embedded sys-tems and should be considered during the design stage.Disregarding this parameter can lead to problems in pro-duction such as over-heating, power supply overload or asignificant autonomy reduction. These events may affectthe whole system stability or reduce the device lifespan[2].

Furthermore, each application has an optimized condi-tion of operation in terms of performance, power consump-tion, etc. depending on applications, the environment,and user constraints, so the need of an energy-efficientcontroller, which is able to handle the reconfigurationprocess at very high speed and auto-adapt to variouspower consumption constraints, is also becoming essential.

In this paper, an ultra-fast power-aware reconfigurationcontroller—UPaRC incorporated with a dynamic clockgenerator is presented. On the one hand, the reconfigu-ration controller can operate at ultimate frequency (up to362.5 MHz) that provides an extreme high reconfigurationthroughput. On the other hand, the dynamic clock gener-ator varies the operation frequency of the reconfigurationcontroller to adapt to various performance and powerconsumption constraints.

The paper is organized as follows: next section intro-duces related works. Section III details the architectureof UPaRC, Section IV gives the implementations andthe comparison with some other controllers. Section Vemphasizes the advantages of proposed system with themeasurement of power consumption. The last section con-cludes and gives some future works.

II. Related Works

Hardware sharing by dynamic reconfiguration not onlyincreases the flexibility of designs but also reduces powerconsumption [3], [4]. The reconfiguration takes place bysending the bitstream to the reconfiguration port. Figure1 shows the common architecture of a reconfiguration con-troller driving Internal Configuration Access Port (ICAP)[5]. ICAP is the hardwired primitive inside the Xilinx

FPGA device by which the bitstream can be dynamicallyloaded into the configuration memory. Reconfigurationspeed deadlock does not come from the ICAP side but inthe bitstream loading from the reconfiguration controllerto ICAP which is usually limited by the access to thebitstream memory. So if the reconfiguration controller iscapable of loading bitstream at very high-speed, it canprovide high reconfiguration bandwidth.

!"#$%&'()"#*

+,-"'.*

/!01*

1'2-2)3,*

4,5"#$%&'()"#*

!"#6'"77,'*

/#89:;<=*

>&689:;<=*

?&@.*

A'B4C*

!D*

!EF*

?26@6',(-*

+,-"'.*

Fig. 1. Partial Reconfiguration with ICAP

Xilinx provides a reconfiguration controller xps hwicap[6], which is processor-dependent (driven by a processor—either MicroBlaze [7] or PowerPC [8]). This reconfigura-tion controller only provides low reconfiguration through-put. The most important advantage of xps hwicap is thehigh capacity for bitstream storage using external non-volatile memories like Compact Flash. To overcome thelow reconfiguration speed, several controllers based onDMA access to the bitstream storage memory are pro-posed in the literature. The BRAM HWICAP [9] appliesDMA access to BRAM which can obtain the maximumtheoretical throughput (400 MB/s) at 100 MHz. Neverthe-less, this controller uses the same frequency as the othercomponents in the system. So the frequency is limited to120 MHz. Another disadvantage of BRAM HWICAP isthe low storage capacity due to limited BRAM amount.Also in [9], the authors proposed another controller—MST ICAP which provides high storage capacity usingDDR2 SDRAM memory. Nevertheless, the lower accessspeed of DDR2 SDRAM compared to BRAM leads tolower reconfiguration speed than BRAM HWICAP.

FaRM [10] includes bitstream compression which allowsto use less BRAM amount than the bitstream size. How-ever, FaRM can operate up to 200 MHz which induces amaximum throughput of 800 MB/s. Additionally, FaRMis fixed to a certain frequency with a variable compressionratios depending on the regularity of the bitstreams, so themaximum throughput could vary. Moreover, compressionalgorithm—Run-Length Encoder (RLE) applied in FaRMdoes not provide an important gain for storage savings.

FlashCAP(i) [11] applies X-MatchPRO [12] which pro-vides a more efficient compression ratio than RLE (74.2%against 63%). But the maximum frequency is limitedto 120 MHz which can provide only a reconfigurationthroughput of 385 MB/s.

We propose an ultra-fast power-aware reconfigurationcontroller which can achieve 1433 MB/s with operatingfrequency of ICAP at 362.5 MHz. This reconfigurationcontroller is processor-independent and requires only a

!"#$%&'(')*+(%

#,,-%

./% 012"%

&3"45627% "89):%

%

;'7'<2-%

%

"89%

"89)#%

=-2>+27?3%','@('A57B%

ACD7<E%F'7,GD,(HE%

@5G2-%?57I+C@A57J%

"89)K% "89)L%

L1#;%

&2?5C@-2II5-%

.M(2-7'4%

;2C5-3%

"89)N%

O('-(%

=D7DIH%!"#$%&

LD(I(-2'C%

Fig. 2. Detailed structure of ultra-fast power-aware reconfigurationcontroller

“Start” signal which can be easily driven by any kind ofmodule. This controller is customized to reach a signifi-cantly higher speed than the state-of-the-art reconfigura-tion speed and offers dynamic frequency scaling to satisfydifferent power constraints.

III. Ultra-Fast Power-Aware ReconfigurationController—UPaRC

Figure 2 details the internal structure of the pro-posed UPaRC consisting of an ultra-fast reconfigura-tion controller—UReC, a dynamic clock generator—DyCloGen, and a decompressor. The Manager, whichconnects to an external memory, drives UPaRC for rapidreconfiguration process.

A. Manager

In the system, the manager carries out three tasks: bit-stream preloading, reconfiguration control and frequencyadaptation—driving DyCloGen to vary the frequency toadapt to various constraints. We use a MicroBlaze toperform these three tasks, but they can be handled bythree different smaller hardware modules to save energy.

1) Bitstream Preloading: The Manager is in charge ofreading the bitstream file in the external memory, parsingthe preamble of the partial bitstream and then loadingbitstream size followed by the configuration data into theBRAM. Figure 3 shows the data loaded by the Manager.The first 32-bit word contains the bitstream size and theoperation mode determining the operation mode of thereconfiguration controller (with or without compression).Configuration data used to reconfigure the related modulefollow this word.

!"#$#%&'()*"+&) ,-.&)

/0) 0)

,-.&)

12)3"#4-5#)6-(7%&$$"-8)

02)3"#4)6-(7%&$$"-8)9-8:;5%'<-8).'#')

Fig. 3. Organization of BRAM contents

Scheduling may be able to predict the tasks to beexecuted on a reconfigurable module [13], thus the configu-ration data preloading can be done during idle time which

does not affect the system computational performanceand that could significantly improve the reconfigurationbandwidth.

Partial bitstream data contain a preamble which de-termines the attributes such as file name, FPGA deviceID, bitstream size, etc. After this preamble, the bitstreamcontains data which configures the related module.

2) Reconfiguration Control: The manager controls thereconfiguration process by sending the “Start” signal tolaunch the reconfiguration and receiving the “Finish” sig-nal when reconfiguration ends. Contrary to xps hwicap inwhich the MicroBlaze is busy during the reconfigurationprocess, the MicroBlaze only launches UPaRC and is freeduring UPaRC performs the reconfiguration. And becausethe MicroBlaze consumes large amount of resources, theenergy consumption during reconfiguration using UPaRCcan be much less than using xps hwicap. Moreover, the re-configuration control can be handled by a small hardwaremodule which can still save more energy.

3) Frequency Adaptation: The Manager analyzes dif-ferent constraints (performance, power consumption, etc.)during runtime and chooses the appropriate frequency tomeet these constraints by driving DyCloGen (see SectionIII-D).

B. Ultra-Fast Reconfiguration Controller—UReC

The reconfiguration controller includes BRAM mem-ory to store bitstreams which are used for reconfigura-tion. The dual-port BRAM memory is used. One portis interfaced with the bitstream manager to preload thebitstream whereas the other port is connected to UReC.The bitstream preloading (driven by the Bitstream Man-ager) does not affect the operation of the reconfigurablemodule, so the reconfiguration time of a module is thetime to download bitstream data from BRAM to ICAP.The reconfiguration process includes DMA access to thesecond BRAM port and burst data transfer from BRAMto ICAP. That allows to reach the maximum reconfigu-ration throughput. This method is also applied by someother state-of-the-art reconfiguration controller [9]–[11].However, these controllers re-use DMA module providedby Xilinx which is very large and does not permit to runat a higher frequency than 200 MHz. We have totallyredesigned the BRAM interface so that configuration datacan be transferred at each clock cycle in burst mode.Moreover, UReC performs only BRAM reading allowingto reduce maximum possible hardware resources. Doingso the UReC occupies very small area that can allow toaccelerate the data transmission from BRAM to ICAP.This custom design allows to accelerate ICAP to very highfrequency (up to 362.5 MHz), higher than the maximumBRAM operating frequency—300 MHz [14]. That is whyUReC frequency is much higher than the fastest state-of-the-art reconfiguration controller—FaRM (200 MHz) [10].

Figure 4 explains the operation of UReC which controlsthe BRAM and ICAP to perform the reconfiguration.

!"#$%&'()"#*+"(,-#%*

./('/* 0-#-12*

!+345*

67*

8",9*.9:9;)"#*<*

.-=9*,9/9'>-#()"#*

Fig. 4. Operation of UReC driving BRAM and ICAP

When UReC receives the “Start” signal, it immediatelyenables BRAM access and reads the first 32-bit word todecide the operation mode (without or with compression)and determine the size of the bitstream. Without compres-sion, the configuration data can be loaded directly fromthe BRAM to ICAP, whereas in compression mode, thedata should be fetched from BRAM to the decompressorbefore being sent to ICAP. The configuration data toICAP is loaded using burst transfer without interruptwhich permits to obtain the maximum reconfigurationbandwidth. A “Finish” signal indicates the end of thereconfiguration process and the EN signal deactivates theBRAM and ICAP access to save power consumption.

C. Lossless Bitstream Compression

Because bitstreams contain configuration details, if com-pression is required, bitstreams must be compressed with-out loss. There exists a lot of lossless data compressionRLE, LZ77, LZ78, Huffman, X-MatchPRO, Zip, 7-zip, etc.[15]. We compare in Table I different lossless compressionalgorithms, tested with different partial bitstream sizesand complexities. Because empty zones in the FPGAdevice can involve repetitive sequences in the configurationbitstreams, so in order not to exaggerate the compressioneffectiveness, we perform the compression only on partialbitstreams which have high resource utilization ratio tominimize number of blank frames in the reconfigurablepartition.

TABLE IComparisons of Different Lossless Compression Algorithms

AlgorithmCompression

Ratio [%]

RLE 63LZ77 71.4Huffman 72.3X-MatchPRO 74.2LZ78 75.6Zip 81.27-zip 81.9

At the moment X-MatchPRO, which is an open-sourcealgorithm providing competitive compression effectivenesswith Zip and 7-zip, is implemented in our system. Thecompression ratio recorded in our system is 74.2% inaverage which signifies that generally the compressed bit-stream is about four times smaller than the original one.

The system operates in two modes depending on thepartial bitstream size of the module to be reconfigured.

• Preloading without compression: If the original bit-stream size is smaller than the BRAM size, the

Bitstream Manager is in charge of pre-loading thebitstream into the BRAM contents.

• Preloading with compression: In case that the orig-inal bitstream size is greater than the BRAM size,bitstream compression is required. By default the X-MatchPRO compression algorithm is implemented inour system. The over-sized bitstream is compressedoffline using PC-running software and then put inthe BRAM memory afterwards. The decompressionpart is performed by a hardware decompressor (Fig.2). This decompressor is dynamically reconfigurablethat allows to change compression/decompression al-gorithm by partial reconfiguration depending on thedecompression speed, provided bandwidth, etc. Be-cause each decompressor has its maximum frequency,after being reconfigured, its frequency (CLK 3 inFig. 2) will be dynamically modified by DyClogen.

D. Dynamic Clock Generator—DyCloGen

DyCloGen is a clock generator able to dynamicallymodify the frequency of its output clocks to meet thedemand. The clock modification process is carried outby controlling the multiplication/division (M/D) factorsdefined in equation:

Fout = Fin × MD

Unlike partial reconfiguration where the reconfigured mod-ule is changed without affecting the others, the clockgenerator modifies the clock frequency while it is stilloperational. So DyCloGen controls Dynamic Reconfigu-ration Port (DRP) [5] of the specific digital clock manager(DCM) block found in Virtex-5 devices [16]. Doing so, theM and D values can be dynamically programmed withoutusing partial reconfiguration via ICAP.

DyCloGen provides three different clock signals (CLK 1,CLK 2, and CLK 3) which are modifiable at run-time.CLK 1 is the clock source for preloading the BRAM con-tents, CLK 2 is the reconfiguration clock whereas CLK 3determines the decompression frequency. Varying theseclocks allows to change the power consumption to adaptto various conditions. Operating at high frequency canoffer high-performance computations but can increase thepower consumption, thus an appropriate frequency shouldbe selected to meet both performance and consumptionrequirements.

IV. Implementations and Comparison

We have implemented the system of Fig. 2 withtwo Xilinx FPGA platforms: ML506 [17] with Virtex-5XC5VSX50T and ML605 [18] with Virtex-6 XC6VLX240Tusing Xilinx Design Suite v13.2. The resources required forblocks are shown in Table II.

The resources required for proposed modules (DyClo-Gen and UReC) are relatively small. The decompressorconsumes a large amount of resources because it offers a

TABLE IIFPGA resources needed by basic blocks of UPaRC

ModuleVirtex-5[slices]

Virtex-6[slices]

DyCloGen 24 18UReC 26 26Decompressor 1035 900

Fig. 5. Reconfiguration Bandwidths vs. Frequencies vs. BitstreamSizes (measured with UPaRCi in preloading without compressionmode using Virtex-5)

really fast decompression speed, inducing a high decom-pression bandwidth (more than 1 GB/s).

Table III shows the comparisons of performance (re-configuration bandwidth, large bitstream handling ca-pacity and maximum frequency) between different re-configuration controllers. There are two instances ofour reconfiguration controller corresponding to twomodes: UPaRCi—preloading without compression andUPaRCii—preloading with compression. With the ML506platform, UPaRCi can reach 362.5 MHz (with Fin =100 MHz, M = 29 and D = 8 for DyCloGen config-uration), offering 1433 MB/s reconfiguration bandwidth.UPaRC is tested on several Virtex-5 XC5VSX50T FPGAsand 362.5 MHz is a successful reconfiguration frequency inour working conditions (default core voltage 1 V, ambienttemperature 20C). Tests under the same conditions on afew Virtex-6 XC6VLX240T show that 362.5 MHz is notreliable, the maximum frequency seems to be few MHzlower. Experiments are underway on a larger number ofsamples to determine if the limitation is specific to the V6family.

Thanks to large storing capacity of external non-volatilememory like the Compact Flash, xps hwicap [6] canhandle large bitstreams without the need of bitstreamcompression. However, it provides a very low reconfigu-ration throughput. With our experiments, the throughputrecorded of this controller is about 180 KB/s. In [9], theauthor measures xps hwicap performance using processorcache memory and it reaches 14.5 MB/s reconfigurationbandwidth.

Since BRAM HWICAP [9] is implemented using Virtex-4 FPGA, it is not easy to compare the hardware overhead.

This controller is limited in bitstream sizes and limitedin frequency (approximate theoretical throughput at thisfrequency). Without compression, our controller offersultimate reconfiguration throughput up to 1.433 GB/s,which is 1.8 times higher than the fastest controller foundin the literature (FaRM [10]—800 MB/s). MST ICAP [9]which can handle large bitstreams is limited in frequencyhence offers lower reconfiguration throughput. FlashCAPi

[11], which is comparable to our UPaRCii thanks to thesame compression method, is also limited in frequency.Figure 5 shows the reconfiguration bandwidth measuredwith different sizes of bitstreams and at different frequen-cies. Because, the time overhead due to the control andthe measurement using MicroBlaze is constant, the largerbitstream is, the less the control affects the reconfigura-tion time and the real bandwidth is more approximateto the theoretical bandwidth. As shown on Fig. 5, at362.5 MHz and with the bitstream size of 6.5 KB, theeffective bandwidth is 1.14 GB/s which is 78.8% of thetheoretical bandwidth at this frequency (1.45 GB/s). Witha bitstream size of 247 KB, the effective bandwidth is1.44 GB/s, which is more approximate the theoreticalbandwidth (99%).

TABLE IIIComparisons of Different Reconfiguration Controllers

ReconfigurationController

Bandwidth[MB/s]

LargeBitstream

Max Freq.[MHz]

xps hwicap [6] 14.5 +++ 120MST ICAP [9] 235 +++ 120FlashCAPi [11] 358 ++ 120BRAM HWICAP [9] 371 - 120FaRM [10] 800 ++ 200UPaRCii 1008 ++ 255UPaRCi 1433 - 362.5

The size of BRAM memory for bitstream preloadingis 256 KBytes. With compression, this memory amountallows for storing the maximum bitstream of 992 KBytes,which is more than 40% of the full bitstream of theselected Virtex-5 device (2444 KBytes). That signifies thatbitstream preloading with compression can handle thelargest module which occupies half of the device resources.In preloading with compression mode, the decompressionblock has a throughput of 2 words/cycle (64-bit datapath), which operates at maximum 126 MHz and suppliesa reconfiguration throughput of 1.008 GB/s. To note thatthe frequency of the decompression block is different fromthe frequency of the reconfiguration block. In preloadingwith compression mode, it is not necessary that UPaRCoperates at maximum frequency. The highest frequency atcompression mode is 255 MHz.

However, reconfiguration throughput and bitstream sizelimitation are not only the major concerns. Power con-sumption should be considered, especially in embeddeddesigns with a power budget, to ensure proper operationof the system.

V. Power Consumption Consideration

Classically, FPGA power consumption can be separatedinto two main contributions: static and dynamic power.The first one is due to transistor leakage and dependenton the supply voltage and the size of the device. Thesecond, which is caused by transistor switching, is highlydependent on the supply voltage, the signals activities,the application complexity and the clock frequency. Thepower consumption related to the reconfiguration is mostlycomposed of dynamic power. We measure the power con-sumption on Xilinx ML605 platform which has a Virtex-6FPGA. ML605 includes a shunt resistor to monitor currentthrough FPGA core, so we can measure Virtex-6 powerconsumption which is not possible using ML506. However,the measured values may change between Virtex-5 andVirtex-6 due to the difference of the process technologies(65 and 40 nm). Figure 6 presents the experimental setupfor power measurements. We use the Virtex’s core shuntwith a high-precision amplifier to handle current andpower consumption measurements which are logged witha digital oscilloscope.

1VVCCINT

Shunt

5mΩ

Virtex-6Vcore

GND

+

-×100

ML605

Fig. 6. Current measurement schematics on ML605 Board using ahigh-precision amplifier and an oscilloscope.

Net capacitance is a parameter of the dynamic powerconsumption, so to reduce dynamic power consumptionreconfiguration controller must have short interconnec-tions. Thanks to the lightweight of our reconfiguration con-troller, the power and energy consumptions are very lowcompared to state-of-the-art controllers. Since xps hwicapproposed by Xilinx is the only available reconfigurationcontroller to public, we compare the energy consumptionof UPaRC with xps hwicap in the same conditions usinga MicroBlaze running at 100 MHz with a 216.5 KBbitstream preloaded in 256 KB of 32-bit BRAM data bus.Without processor optimizations, we achieve a reconfigu-ration throughput of 1.5 MB/s of configuration data andthe energy efficiency is 30 µJ/KB of bitstream. In thesame conditions, using a Microblaze as manager, UPaRC(without compression) consumes only 0.66 µJ/KB whichis 45 times more efficient than xps hwicap.

Moreover, UPaRC can operate at a different clockfrequency than the manager. This feature enables us torespect performance constraints with different power con-sumption characteristics during runtime. Figure 7 showsthe power consumption during the reconfiguration of anuncompressed 216.5 KB bitstream file for different clockfrequencies, from 50 MHz to 300 MHz which is the maxi-

mum guaranteed frequency for BRAMs. On these curves,the power peak before zero timestamp is caused by theactivity of the manager to control UPaRC of which theduration and the power consumption are the same foreach frequency since the frequency of the manager is notmodified (MicroBlaze at 100 MHz). Then the reconfig-uration procedure begins, all the configuration data arecopied from BRAM to ICAP. This activity rises the powerconsumption immediately after the “Start” signal. Oncethe reconfiguration is completed, the power consumptiondecreases to the idle power consumption.

3.8

3.9

4

4.1

4.2

4.3

-0.5 0 0.5 1 1.5

Pow

er(W

)

Time(ms)

100MHz

200MHz

300MHz

50MHzReconfiguration

control

Fig. 7. FPGA core power consumption during dynamic partialreconfiguration using UPaRC with different frequencies on a Virtex-6. Only a MicroBlaze as the manager and UPaRC are implemented

The power consumption at 50 MHz is 183 mW, corre-sponding to a reconfiguration time of 1.1 ms. At 100 MHz,the power consumption is 259 mW during 550 µs. Wenotice that when the frequency is doubled, the reconfig-uration time is halved, but the power is not doubled.This is caused by the manager which is implementedwith an active wait for “Finish” signal and thus requiresenergy. At 200 MHz, the power consumption is 394 mWduring 270 µs. Finally, reconfiguration at 300 MHz requires453 mW during 180 µs.

The reconfiguration manager is right now not optimizedfor power consumption. The manager waits for the endof reconfiguration actively. This wastes some energy, thatis why the energy decreases with the frequency, but inthe case of a smaller manager or without actively wait-ing for reconfiguration to be done, the reconfigurationenergy would be the same for each frequencies. The powerconsumption increases proportionally with the increase ofreconfiguration frequency, so the power-aware solution isto use the lowest possible frequency which meets timingconstraints for the current application. Frequency is dy-namically adjusted, using DyCloGen, to meet applicationperformance requirements and lower the power requiredwhen reconfiguring.

VI. Conclusions and Future Work

An ultra-fast power-aware reconfiguration controller—UPaRC, which enhances the adaptivity to meet various

demands during run-time, opens a higher degree of free-dom in system design and behavior modification duringrun-time. This controller also offers ultimate reconfigura-tion bandwidth which can also meet the needs of high-performance applications. Moreover, the reconfigurationcontroller supports performance and power consumptionon the fly adjustments. This feature enables UPaRC tobe managed by a power optimization algorithm to reduceoverall FPGA consumption. The energy efficiency of UP-aRC is validated through the consumption measurementcampaign.

We aim to further enhance the adaptivity by choosingdifferent bitstream compression techniques at run-timeusing dynamic partial reconfiguration. Depending on therequirements of compression ratios, hardware resources,different frequency limits in compression modes, a widerrange of application can be supported by UPaRC. We willfocus our future work on the global power optimization ofan application using high speed and energy efficient partialdynamic reconfiguration.

References

[1] J. Becker, M. Hubner, G. Hettich, R. Constapel, J. Eisenmann,and J. Luka, “Dynamic and Partial FPGA Exploitation,” Pro-ceedings of the IEEE, vol. 95, no. 2, pp. 438–452, 2007.

[2] R. Viswanath, V. Wakharkar, A. Watwe, V. Lebonheur et al.,“Thermal performance challenges from silicon to systems,” IntelTechnology Journal, 2000.

[3] L. Sterpone, L. Carro, D. Matos, S. Wong, and F. Fakhar,“A New Reconfigurable Clock-Gating Technique for Low PowerSRAM-based FPGAs,” in Design, Automation Test in Europe,Grenoble, 2011, pp. 1–6.

[4] J. Becker, M. Huebner, and M. Ullmann,“Power Estimation andPower Measurement of Xilinx Virtex FPGAs: Trade-Offs andLimitations,” in Integrated Circuits and Systems Design, NewYork, 2003.

[5] Xilinx, Inc, “Virtex-5 FPGA Config. User Guide UG191,” 2009.[6] ——, “LogiCORE IP XPS HWICAP DS586,” 2010.[7] ——, “MicroBlaze Processor Reference Guide UG081,” 2011.[8] ——, PowerPC 405 Processor Block Reference Guide, 2004.[9] M. Liu, W. Kuehn, Z. Lu, and A. Jantsch, “Run-Time Partial

Reconfiguration Speed Investigation and Architectural DesignSpace Exploration,” in Field Programmable Logic and Applica-tions, Prague, 2009, pp. 498–502.

[10] F. Duhem, F. Muller, and P. Lorenzini, “FaRM: Fast Reconfig-uration Manager for Reducing Reconfiguration Time Overheadon FPGA,” Reconfigurable Computing: Architectures, Tools andApplications, pp. 253–260, 2011.

[11] A. Nabina and J. Nunez-Yanez, “Dynamic Reconfiguration Op-timisation with Streaming Data Decompression,” in Interna-tional Conference on Field Programmable Logic and Applica-tions, Milano, 2010, pp. 602–607.

[12] J. L. N. ez and S. Jones, “Gbits/s Lossless Data CompressionHardware,” IEEE Transactions on Very Large Scale Integration(VLSI) Systems, vol. 11, pp. 499–510, 2003.

[13] I. Belaid, F. Muller, and M. Benjemaa, “New Three-LevelResource Management Enhancing Quality of Offline HardwareTask Placement on FPGA,” International Journal of Reconfig-urable Computing, pp. 65–67, 2010.

[14] Xilinx, Inc, “LogiCORE IP Block Memory Generator v4.3.”[15] M. Nelson and J. Gailly, The data compression book, M. Books,

Ed., 1996, vol. 619.[16] Xilinx, Inc, Virtex-5 FPGA User-Guide, January 2009.[17] ——, “ML505/ML506/ML507 Eval. Platform UG347,” 2008.[18] ——, “ML605 Hardware User Guide UG534,” 2011.