This work describes the identification of designs that benefit from a Dynamic Circuit Specialization (DCS) implementation on FPGAs. In DCS, the circuit is specialized for slowly changing inputs, called parameters. For certain applications or cores, a DCS implementation is faster and smaller than the original implementation. However, the best DCS implementation can be hard to identify, as it requires the designer to be familiar with both the design and DCS. In this paper, we present a profiling tool to aid the designer in analyzing the feasibility of a DCS implementation. It automatically provides a functional density estimate for the most interesting DCS implementations

Bruneel, Karel

Davidson, Tom

Stroobandt, Dirk

English

Ghent University Academic Bibliography

IDENTIFYING OPPORTUNITIES FOR DYNAMIC CIRCUIT SPECIALIZATIONTom Davidson, Karel Bruneel, Dirk StroobandtELIS CSL, HES groupGhent UniversitySint-Pietersnieuwstraat 41, B-9000 Gent, Belgiumemail: [name].[surname]@elis.ugent.be1. INTRODUCTIONThis work describes the identification of designs that benefitfrom a Dynamic Circuit Specialization (DCS) implementa-tion on FPGAs. In DCS, the circuit is specialized for slowlychanging inputs, called parameters. For certain applicationsor cores, a DCS implementation is faster and smaller thanthe original implementation. DCS implementations can ben-efit from the possibility in modern FPGAs to reconfigurespecific configuration bits at run-time. This means DCS canbe used to specialize an FPGA circuit during the run-time ofthe FPGA.Initially, in DCS, it is assumed that the parameters areconstant. Constant propagation then allows the specializa-tion of the circuit by partially evaluating the circuit. Thisspecialized circuit is smaller and faster than the original cir-cuit but is only correct for one specific parameter value. Ofcourse, the parameters will not stay constant for ever, even-tually they will change. This is solved using the run-time re-configuration capabilities of the FPGA. A DCS system hasboth an FPGA and a configuration manager. The configu-ration manager is responsible for generating the specializedcircuit and reconfiguring the FPGA.In an implemented DCS system, the FPGA contains aspecialized circuit for the current parameter value. The FPGAis working normally until the value of a parameter changes.Using the new parameter value, a new specialized circuit isgenerated by the configuration manager and the FPGA isreconfigured with this new circuit. During this process theFPGA is halted. Once the reconfiguration has finished, theFPGA is working normally again. Until the next parame-ter change, then the specialization process starts over. Thetime and resources needed to generate the new circuit and toreconfigure the FPGA are overheads DCS introduces. Thetime of one specialization is called the single specializationoverhead.Such a DCS system could be implemented in multipleways. In [1] an efficient method for DCS, developed byGhent University, is described. It includes an FPGA toolflow adapted for DCS, which will be used in the followingsections. For the moment, it only implements the reconfig-uration of LUT truth tables, and not the routing infrastruc-ture. Only a select number of LUTs are run-time reconfig-ured, these LUTS are called TLUTs.Previous papers have shown that this method for DCScan achieve significant area reductions in a number of hard-ware designs. In [1], an adaptive 16-TAP FIR-filter is imple-mented using 56% less area. It uses only 1301 LUTs, whilethe size of the original implementation was 2999 LUTs. Theresulting DCS implementation is also 27% faster than theoriginal implementation. The single specialisation overheadis 166µs. This is the design used for the profiler run-timemeasurements in Section 3. The results for larger FIR-filtersare similar. The same publication also shows a 66% LUT re-duction for Ternary Content-Addressable Memories. Bothof these results, and the adapted FPGA tool flow, were ver-ified by building these DCS implementations on an actualFPGA, the Xilinx Virtex II Pro.[2] shows that a number of key-based encryption algo-rithms also see a significant area reduction, 20.6% for AES.27.8% for Triple DES and a 72.7% reduction for the rc6-algorithm. Finally, in [3] this method for DCS is shownto achieve similar results as hand-crafted run-time recon-figurable implementations of a Network Intrusion DetectionSystem (NIDS). This paper also presents improvements tomake the NIDS implementation fully run-time reconfigurable,using this DCS method.In this paper, we present a profiling tool to aid the de-signer in analysing the feasibility of a DCS implementation(Section 3). It automatically provides a functional densityestimate (see Section 2) for the most interesting DCS imple-mentations.2. DCS IDENTIFICATION OF A DESIGNDetermining whether or not a certain design will benefitfrom a DCS implementation is a difficult task for the de-signer. First, it requires the designer to be familiar with theexact DCS-method. Secondly, in order to find a good pa-rameter selection, insight into the dynamic behaviour of thesignals in the design is required. This is typically not some-thing that is important in the normal design process. In ad-dition, there are no tools that allow the designer to analysethe dynamic behaviour of large groups of signals. VHDLand Verilog Simlators do exist, but they focus on verifyingthe behaviour of a limited number of signals. Even after theparameter selection it is very difficult to predict the gains ofa DCS implementation without actually implementing it. Tosolve this problem, we first decided on a metric that allowsan easier comparison between implementations. This met-ric is the functional density, and is explained in detail below.The next section presents a profiler that uses this metric toautomatically analyse an existing implementation.To identify designs that benefit from DCS, different im-plementations of the design have to be compared. A goodmeasure for this comparison is the functional density (FD) [4].It is the number of computations per unit of area and per unitof time (Equation 1). TFPGA is the complete execution timeof the FPGA. N is the number of operations, and AFPGA isthe number of LUTs in the implementation.FDDCS =NAFPGA × TFPGA (1)The number of operations, N , can always be expressedas the number of clock cycles times a correction factor (C).In the case of the FIR-filter, where one input sample is pro-cessed every clock cycle, N can be redefined as exactly thenumber of clock cycles.DCS implementations where the benefits are high willoccupy less area and therefore have a higher FD. On theother hand, if DCS introduces a large time overhead, thetotal execution time will increase, while the number of op-erations stays the same, leading to a lower FD. A designbenefits from DCS if a DCS implementation with a higherFD that the original implementation can be found.In the DCS implementation a number of signals will beselected as parameters. We call this the parameter set. Themost exhaustive way to find the best DCS-implementation isto calculate the FD for all possible parameter sets. However,this would take a prohibitively long time, because (i) thenumber of signals in complex designs is very high and (ii)calculating the FD itself requires up to hours for complexdesigns.To address (i), the most interesting parameters for DCSare identified based on Equation 2. This equation expressesthe FD as a function of the average single specializationoverhead (TˆSST ) and the average time the FPGA is work-ing for a single parameter value (TˆFPGA).FDDCS =1TˆSSTTˆFPGA+ 1NAFPGA × TFPGA (2)The first part of Equation 2 expresses the degradation ofthe FD, caused by the single specialization overhead. It isclear that the degradation will be small if the single special-ization time is much smaller than the average time for eachparameter value. The influence of the degradation can beseen clearly in Figure 1. This figure shows how the func-tional density is dependent on the average time between pa-rameter changes (TˆFPGA). Looking more closely at the firstpart of Equation 2, this means only signals for which TˆSSTis (much) smaller than TˆFPGA will have a low degradation.In other words, only signals for which the time between tran-sitions (TˆFPGA) is much longer that the overhead for a sin-gle reconfiguration (TˆSST ) are interesting parameter candi-dates. To reduce the number of signals under consideration,signals for which TˆSST is larger than TˆFPGA are ignored.A good value for TˆSST is discussed in Section 3. 0 2000 4000 6000 8000 10000 12000 14000100 102 104 106 108 1010 1012Functional density(Ops/s / LUT)Avg. Time between parameter transitions (clock cycles)Original ImplementationDCS ImplementationFig. 1. Influence of the degradation on the functional den-sity of a DCS-implementation. Compared to the functionaldensity of a generic implementation.As for (ii, the long time needed to calculate the FD), theFD has to be determined for each of the remaining param-eter candidates. Calculating the FD exactly requires run-ning the full FPGA tool flow, which can take hours for com-plex designs [5]. Most time is spent in the last two steps,placement and routing. In addition, both of these steps scalevery badly with increasing circuit size, since both are NP-complete problems.However, the FD can also be estimated, before place-ment and routing. For this estimation, Equation 3, a rewrit-ten version of Equation 2, is used. Where, TˆO is the averagetime between parameter changes in the original implementa-tion. T 1DCS and T1O are the clock periods of the DCS and theoriginal implementation, respectively. All these variablescan be estimated based on the FPGA tool flow before place-ment and routing. A more detailed discussion in Section 3.FDDCS =CTˆSSTTˆOT1DCST1O+ 11AFPGA × T 1DCS(3)3. PROFILERTo help the designer analyse the different DCS implementa-tions of designs based on the FD metric, an automatic pro-filing tool was developed. It requires an RTL description ofthe design and a test bench with realistic input data. Theprofiler uses a two-step approach. In the first step a numberof parameter candidates are selected from all the signals inthe design. In the second step, the functional density is esti-mated for each of those candidates. Both steps are discussedin more detail below.Selecting the parmeter candidates: First, the profilerruns the test bench through a simulator to gather data on thedynamic behaviour of all signals. This data is then analysedin order to remove all signals for which TˆO is smaller thanthe chosen TˆSST . This is the criterion explained in the pre-vious section. However, because the exact overhead of theDCS-implementation is not known yet, a minimal value forTˆSST was chosen. This minimal TˆSST is the time neededto run-time reconfigure one single LUT. This removes allthe signals that have a large FD degradation even with thesmallest possible overhead. All the remaining signals, theparameter candidates, are given to the next step of the pro-filer, which will estimate the FD for each candidate.Functional Density estimate: This FD estimate is basedon Equation 3. Here, TˆO is collected from the analysis of thedynamic signal behaviour in the previous step. All the othervariables (AFPGA, TˆSST ,T 1DCS and T1O ) are collected byrunning an abbreviated FPGA tool flow for DCS [1], withoutplacement and routing. This flow is run for each parametercandidate. After this flow has finished, AFPGA is knownexactly and TˆSST , T 1DCS and T1O can be estimated. Thedetails of these estimates are discussed below.3.1. Single Specialization Time (TˆSST )The single specialization time is the run-time overhead in-troduced by DCS. It has two parts: the time needed for gen-erating a new circuit (Tgeneration) and the time needed forthe actual reconfiguration of the FPGA (Treconfiguration).The FPGA tool flow presented in [1] uses Boolean func-tions to express how the TLUT truth tables are dependenton the parameter values. The new circuit is generated byevaluating these Boolean functions for the new parametervalues. This generation time is estimated using the numberof Boolean operations (BoolOps) and the chosen compu-tation unit (K). K represents the average total overhead ofone Boolean operation. It is determined by running the com-plete run-time reconfiguration flow for a large design multi-ple times, while each time measuring only the time requiredfor the Boolean evaluation.Tgeneration = BoolOps×K (4)This computation unit is generally also the configurationmanager. A good option is the embedded CPU in a lot ofmodern FPGAs. For the Xilinx Virtex II Pro FPGA, this isthe PowerPC 405. In that case, K is 3.32 clock cycles.The reconfiguration time is dependent on the chosen re-configuration method. [1] proposes two methods, one methodusing the HWICAP and one using the Shift Register LUT(SRL) capability of Xilinx FPGA’s.The HWICAP is the standard configuration interface pro-vided by Xilinx. In this case, the FPGA is reconfiguredframe by frame. To estimate the reconfiguration time weestimate number of frames that needs to be reconfigured, as-suming the TLUTs are spread out randomly over the totalnumber of LUTs. The reconfiguration time is then Equation5. For the Virtex II Pro, a single frame is reconfigured in98.23 µs.THWICAPreconfiguration = E[#frames]× Tframe (5)The second method for run-time reconfiguration usesthe Shift-Register LUT capabilities, present in some modernFPGAs. This allows the TLUTs to be combined in one ormore shift registers chains. This method of reconfigurationis much faster because each chain can be reconfigured inparallel and only the actual truth table bits are sent. A HW-ICAP frame carries a lot more overhead. The SRL chainsare clocked at the design speed. For the above information,the reconfiguration time using SRLs can be estimated easily.It uses the number of TLUTS, the number of chains and theclock speed of the DCS implementation (Equation 6).TSRLreconfiguration =#TLUTS × 16× T 1DCS#chains(6)3.2. Clock periods (T 1DCS ,T 1O)The clock periods, T 1DCS , of the DCS implementation, andT 1O, of the original implementation, are estimated by thenumber of LUTs in the longest path of the mapping resultof each implementation. This depth is then multiplied witha worst-case estimate of one complete LUT delay for thetarget FPGA. To get the complete clock period estimation apre and post delay are added. It is assumed that the longestpath will be from FF to FF, not from I/O Block to I/O Block.For the Virtex II Pro, the LUT gate delay is 0.275 ns and theLUT net delay is 0.575. The pre and post delays are 0.886ns and 0.208 ns respectively.T 1estimate = Tpre + depth× TLUTdelay + Tpost (7)3.3. Profiling timeUsing FD estimates instead of exact FD calculations, re-duces the execution time of the profiler significantly. Asdiscussed earlier, the most time intensive parts of the FPGAtool flow are the placement and the routing [5]. Both ofthese steps are avoided by using the estimates. The impactof using the estimates is shown in the execution time mea-surements described below. These experiments were donefor a Virtex II Pro (xc2vp30-7ff1152), the profiler was runon a computer with 8 GBs of RAM and an Intel Core2 QuadQ9650 (3GHz, 1333MHz, 12MB).Two adaptive FIR filters, a 16 TAP and a 32 TAP ver-sion, and corresponding test benches were analysed by theprofiler. The profiler was run two times for each FIR fil-ter, one run used the FD estimates, the other the exact FDcalculation. In each case the execution time for each param-eter candidate was measured. We will discuss the averageexecution time per parameter candidates for all cases.Table 1. The average execution time for one parameter can-didateFD Estimate Exact FD16 TAP filter 36.12 s 107.12 s32 TAP filter 41.67 s 248.10 sThe FD estimate for one parameter candidate in a 16TAP adaptive FIR filter requires 36.12 seconds. Calculatingthe FD exactly instead of estimating it requires an extra 71seconds. In that case, the total analysis time for this filterwould increase from 10.23 minutes to 30.35 minutes. Thisextra time is the time needed for the placement and the rout-ing of the design.In addition, because the placement is an NP-completeproblem, it scales badly with increasing circuit size [5]. E.g.for a 32 TAP adaptive FIR filter, the time needed for theexact calculation of the FD is already 248.10 seconds foreach parameter candidate, while estimating the FD still onlyrequires 41.67 seconds, a difference of 206.43 seconds. So,even though the size of the circuit has only doubled, the timefor placement and routing has increased by 2.9x. The 32TAP adaptive FIR filter still only uses 15% of the VirtexII Pro area. This effect will be even more pronounced indesigns that use a larger FPGA area.We are currently preparing an extensive discussion onthe accuracy of the FD estimates. However, it is alreadyclear that if the FD estimates predict a significant gain, thenthe exact, calculated, FDs will also show a significant gain.4. CONCLUSIONThis paper shows how to identify designs that benefit fromDCS implementations, using the functional density (FD) asa metric. In addition, a profiler that implements this metric ispresented. It automatically analyses the quality of the mostinteresting DCS implementations of a given design. Thisallows the designer to determine more easily whether a cer-tain core benefits from a DCS implementation or not. Toreduce the execution time of the profiler an FD estimate isused instead of an exact calculation.This profiler is the first step towards a completely au-tomatic tool flow for DCS. This flow would allow the im-plementation of DCS systems without any intervention ofthe designer. Additionally, self-aware reconfigurable sys-tems could also use this automatic flow to analyse their owndynamic behaviour, which could lead to optimal DCS im-plementations. Off course, this kind of flow would, mostprobably, require running the full FPGA tool flow at run-time. A process which can take up to hours for complexsystems. However, dependent on the practical implementa-tion of these self aware systems, this kind of elaborate self-analysis would only be done very infrequently.AcknowledgementsThis research was supported by both the IWT and the Euro-pean Commission in the context of the FP7 FASTER project(#287804).5. REFERENCES[1] K. Bruneel, “Efficient circuit specialization for dynamic re-configuration of FPGAs,” Ph.D. dissertation, Ghent Univer-sity, 2011.[2] T. Davidson, F. Abouelella, K. Bruneel, and D. Stroobandt,“Dynamic circuit specialisation for key-based encryption al-gorithms and DNA alignment,” International Journal of Re-configurable Computing, 2012.[3] T. Davidson, M. Merlier, K. Bruneel, and D. Stroobandt, “Adynamically reconfigurable pattern matcher for regular expres-sions on fpga,” in ParCo2011.[4] A. M. Dehon, Reconfigurable architectures for general-purpose computing. Massachusetts Institute of Technology,1996.[5] C. Ababei, “Speeding up FPGA placement via partitioningand multithreading,” International Journal of ReconfigurableComputing, 2009.

Identifying opportunities for dynamic circuit specialization

https://biblio.ugent.be/publication/3110415/file/3110466.pdf

Identifying opportunities for dynamic circuit specialization

Abstract

Similar works

Full text

Available Versions

Ghent University Academic Bibliography