Two-level Partitioning of Image Processing Algorithms for theParallel Map-oriented Machine

Reiner W. Hartenstein, Jiirgen Becker, Rainer Kress

University of KaiserslautemErwin-Schrodinger-StraBe,D-67663 Kaiserslautem, GennanyFax: ++49 6312052640, e-mail: abakus@infonnatik.uni-kl.de

AbstractThe partitioning of image processing algorithms with a

novel hardware/software co-designframework (CoDe-X) ispresented in this paper, where a new Xputer-architecture(parallel Map-oriented Machine) is used as universalaccelerator based on a reconfigurable datapath hardwarefor speeding-up image processing applications. CoDe-Xaccepts C-programs and carries out both, the profiling-driven host/accelerator partitioning for performanceoptimization, and the resource-driven sequential/structuralpartitioning of the accelerator source code to optimize theutilization of its reconfigurable datapath resources.

1. IntroductionThe sceneof hardware/software co-designhas introduced

a number of approaches to speed-up performance, to opti-mize hardware/software trade-off and to reduce total designtime [5], [9], [22]. Further co-design approaches are advo-cated explicitly or implicitly in developing custom comput-ing machines (CCMs: [15], [25]) such within the R&Dscenes of ASIPs [4] [24] [28] and FCCMs [6] [7]. With theFCCM approach a von Neumann host implementation isaccelerated by external field-programmable circuits. Hereapplication development usually requires hardware experts.The von Neumann paradigm does not efficiently support"soft" hardware because of its extremely tight couplingbetween instruction sequencer and ALU: architectures fallapart, as soon as the data path is changed. So a new para-digm is desirable like the one of Xputers, which conven-iently supports "soft" ALUs like the rALU concept(reconfigurableALU) [12] or the rDPAapproach (reconfig-urable data path array) by Rainer Kress [18] [19].

For such a new class of hardware platforms a new classof compilers is needed, which generate both, sequentialand structural code: partitioning compilers, which partitiona source into cooperating structural and sequential codesegments. In such an environment hardware/software co-design efforts require two levels of partitioning: host/accel-erator partitioning (first level) for optimizing performanceand a structural/sequential partitioning (second level) foroptimizing the hardware/software trade-off of the Xputer

0-8186-7243-9/96 $05.00 @ 1996 IEEE

resources. This paper presents a framework based on thisparadigm. The hardware/software co-design frameworkCoDe-X targets the partitioning and compilation of con-ventional C programs onto a host using the Xputer as uni-versal configurable accelerator. In contrast to otherhardware/software co-design approaches no additional pro-gramming extensions are required and the framework useis not limited to hardware experts. The partitioning is basedon a simulated annealing algorithm. The fundamentallynew feature of the CoDe-X framework is the two-level co-design approach.

First this paper describes the underlying target hardware.Section 3presents the co-design framework CoDe-X and itsstrategies. Section 4 discusses a computation-intensiveapplication example from image processing.

2. The Target HardwareThe target hardware consists of a host workstation that

uses the Xputer as hardware accelerator (see Figure 1). Thekey concept of an Xputer [10] [12] [13], is to map the struc-ture of performance critical algorithms onto the hardwarearchitecture. Performance critical algorithms typically iter-ate the same set of operations over a large amount of data.Since ever the same operations are applied, an Xputer has areconfigurable parallel arithmetic-logic unit (rALU), whichcan implement complex operations on multiple input wordsand compute multiple results. The reconfigurable datapatharchitecture (rDPA) which serves as rALU has been devel-oped especially for computing statement blocks from loopsas well as other arithmetic and logic computations [11].Allinput and output data to the complex rALU operations isstored in a so-called scan window (SW). A scan window is aprogramming model of a sliding window, which movesacross data memory space under control of a data sequencer.All data in the scan windows can be accessed in parallel bythe rALu.

The large amount of input data typically requires an algo-rithm to be organized in (nested) loops, where different arrayelements are referenced as operands to the computations ofthe cwrent iteration. The resulting sequence of data accesses

77

shows a regularity,which allows to describe such sequencesgenerically from a few parameters.AnXputer data sequencer(DS) provides seven hardwked generic address generators(GAGs), which arecapableof interpretingsuchparametersetsto compute a generic data address sequence (SP: scan pattern).This address computation does not require memory cycles.That's why it providessubstantialspeed-up.

To be run on an Xputer, an algorithm has to betransformed into parameters sets controlling the genericaddress generators and a configuration of the rALU, whichimplements the data manipulations within a loop body.Datamanipulations are transport-triggered. I. e., each time, theGAG places the SW to a new memory location, the complexoperations configured into the rALU are evokedautomatically. Since locality of data is essential in finding ageneric SP, a compiler for an Xputer first has to create agood and regular storage scheme (DM: data map, seefigure 3) to obtain good results in petformanceoptimization.

Host IF: interfaceSW: scan window

ConfigurationMemory

ConfigurationMemory Q)

:;

I sw I reconf.!

~ALU ::E

0::E

Figure1. Block Diagram of thetarget hardware

The parallel Map-orientedMachine is one possibleXputer architecture,which provides up to seven MoMmodules.EveryMoMmoduleis directlyconnectedto the

host-bus and contains the above described Xputer hardwareunits as well as a configurationmemoryand a rALUcontroler (figure1). Different rALU and GAGconfigurations are stored in the configurationmemory. So afast on-chip reconfiguration is possible during run time.This is necessary for the computation of nested loops,which are not fully nested. In this case a reconfigurationispetformed between inner- and outer-loops, because therALU has to compute a different loop-body and the GAGrequires other parameters for computing differentgenericaddress sequences. The switching between fastreconfiguration-mode and computation-mode is petformedby a controler.

231other MoM

modulesaddress space

MoM moduleM3

M2 ...M1

y.2°1 I': x

2-dimensionaldatamap

Figure 2. Shared memory structure and Xputeraddress format

As described above our most recent Xputer prototypeoperates as a kind of configurable co-processor to a hostcomputer. All I/O operations are done by the host as wellasthe memory management. The host has direct access to allmemory on the Xputer, and on the other hand the Xputercan access data in the host's memory (shared memory andaddress format, see figure 2).

data &instructionshost

The only connection to the host computer is through thebus intetface. That way, the Xputer could be intetfaced to adifferent host with minim~1 effort. The part of the busintetface that is injected into the host's backplane wouldhave to be redesigned according to the host's busspecifications. All other parts could remain the same.

3. Parameter-driven HIS PartitioningThis section gives an overviewon the two-levelhardware!

software co-design framework CoDe-X. Input language tothe framework is the programming language C. The input ispartitioned in a first level into a part for execution on thehostand a part for execution on the Xputer. Possible parts for theexecution on the Xputer may be described in Xputer-C (X-C). X-C is an extended subset of the programming languageC, which lacks only dynamic structures, but includes

78

l

language features to express scan patterns. The X-C input isthenpartitioned in the second level by the X-C compiler in asequential part for programming the data sequencer, and astructural part for configuring the rALU. Special Xputer-library function-calls in the original C description of theapplications allow to take full advantage of the highacceleration factors possible by the Xputer paradigm.Experienced users may add new functions to the library suchthat each user can access them (see Figure 3).

First the hostlXputer partitioning is explained (nextsection). Then the programming of the Xputer is shown.andfinally the options for experienced users are discussed.

3.1 Profiling-driven PartitioningThe first level of the partitioning process is responsible

for the decision which task should be evaluated on the

1St level

PartitionerXputer-library

functions

GNUCcomplier

I

AnalYZer,!

:

Profiler :.. :

II

X-C. . I . compiler. I I ., . .. I\ ,

, ." J--,

-----. 1 ,

HostCompilerSection

XputerCompiler

Section

Figure 3. Overviewon the CoDe-Xenvironment

Xputer and which one on the host. Generally three kinds oftasks can be determined and are filtered out in a first step:

. host tasks,

. Xputer tasks, and

. Xputer-library functions.The host tasks have to be computed on the host, since

they contain dynamic structures or call operating systemutilities, which cannot be performed on the Xputeraccelerator. The Xputer tasks are the candidates for theperformance analysis on the host and on the Xputer. TheXputer-library functions are used to get the higbestperformance out of the Xputer. An experienced user basdeveloped a function library with all Xputer-libraryfunctions together with their performance values. Thesefunctions can be called directly in the input C-programs.They are evaluated in any case on the Xputer.

At thebeginning,a filtered input program for the Xputer isrepresentedas a graph,calledflow graph.This graph is dividedinto severalXputer tasks.An Xputer task can be computed ona singleMoMmodule and is defined as follows:

. basic block (a linear code sequence),. basic block including conditions,

. fully nested loops (up to seven loops), or

. not fully nested loops (up to seven loops).This means a basic block, which is a linear sequence of

statements, can be included in several Xputer tasks(figure 5). The restriction of seven loops for one Xputer taskis caused by the current Xputer prototype. The datasequencer of this prototype contains seven GAGs, whichcan operate exclusively. The resulting task graph basseveral alternative paths in such a case. A data dependencyanalysis based on the GCD-test [33] gives the datadependencies between the tasks.

Do I = 2 to N

A [I] = B [I] + 1;

D [I] = B [I] - 1;

Enddo; I Strip

~MiningDo J = 1 to N by 32

Do I = J to min (J+31, N);

A [I] = B [I] + 1;

D [I] = B [I] - 1;

Enddo;

Enddo;

Figure 4. Strip mining example (block size: 32)

79

Thus tasks which can be evaluated in parallel can befound. In this phase several code optimization techniquesare possible in order to exploit the target hardware in aoptimized way. For example, single nested loops of largetasks can be transformed into double nested loops byorganizing the computation in the original loop into chunksof approximately equal size (see figure 4). Thistransformation is called strip mining [21]. This makes itpossible to compute these chunks in parallel on differentMoM modules. In our approach the block size of the chunksdepends on parameters describing the hardware resourcesof the cun-ent Xputer prototype in order to achieve anoptimized performance/area trade-off. This technique canbe used e.g. in image processing applications (seeSection 4), if an image is divided in stripes of equal sizes inorder to manipulate these stripes concurrently. Theoptimization techniques [21] of loop distribution (splittingof one loop into two loops computing the same), of loopfusion (transforming two adjacent loops into a single loops)and of loop interchanging (switching inner and outer loop)

BB: basic blockXT: XputerTask

/1rn§I]XT11

I~XT21I~XT31

I~XT41

I~XT51

~XT6~

Figure 5. Examplehowto generate Xputertasks from basic blocks

are also performed by the 1st level partitioner in order toexploit potential parallelism and to optimize the utilizationof the Xputer hardware resources.

For an initial partitioning, thehost tasks are performed onthe host, the Xputer tasks and the Xputer-library functionsare performed on the MoM modules. If several alternativepaths are in the task graph, the largest task which fits ontoan MoM m04ule is chosen. This results in a fine initialpartition since it can be assumed that anXputer tasks can beevaluated faster on the accelerator than on the host. Butthere may be two problems: if the accelerator needsreconfiguration at run-time and in a few cases, if thedatamap has to be reorganized also at run-time.

Run-Time Reconfiguration. In the case of an Xputer-based accelerator, the data sequencer requires a newparameter set, and the rALU requires a reconfiguration.Theparameter set of the data sequencer can be neglected sincethere are only a few parameters to configure. Theconfiguration of the rDPArequires 147456 bits in the worstcase and 23040 bits in an average case. Such a numbercannot be neglected. In any case it is useful to have a localreconfiguration memory on each Xputer board. There arethree possibilities to reduce the overhead forreconfiguration at run-time:

. Configureone idlingXputerboardwhileoneor severalotherboardsare running.Unfortunately,thisis notalwayspossibledue to datadependencies.

. PartialconfigUI3tion:SincetherDPAallowsa partialconfiguration,only thedifferencebetweenthe currentand the set to be configuredhas tobe loaded.Cmrentlyonly theFPGAs fromAIgolronix[16](thenew XilinxXC6200series[3]),Atmel [2],and fromNationalSemiconductcn [26]supportpartialconfiguration.

. Contextswitch:Acontextswitchallowsthe switchingbetween two or more already loaded configuration sets.In the case of the rDPA array 2304 bits have to betransmitted to switch all 96 datapath units.Datamap Reorganization. Due to the large repertory of

scan patterns of the generic address generators (GAGs), areorganization of the datamap in the local memories is notrequired in many cases. A necessary reorganization can beperformed by the host since the host has direct access to thelocal memories via the external bus and the interface. Whenthe host evaluates a task, it can read from any local memoryand may also write back to any local memory.

Profiling. For each Xputer task, the worst case executiontime on the accelerator as well as on the host is computed.The performance data for the accelerator is received fromthe datapath synthesis system (DPSS) in the X-C compiler.The X-C compiler is able to evaluate the number ofiterations for the compound operator. Knowing this

80

execution time, the complete evaluation time can beapproximatedby multiplying it with the iteration count. Thetime-consuming placement of operators in the DPSS doesnothave to be performed for this analysis.

The performance of the host is approximated byexamining the code. For each processor type andworkstation,another model is required. The behavior of theunderlying hardware and operating system has to bedeterministic and known. This implies the timing behaviorof all hardware components, the effects of caching,pipelining, etc. The operating system must provide staticmemory management, system calls should have acalculable timing behavior, and no asynchronous intelTUptsshould be allowed [27]. The techniques used are similar tothese from Malik et. al. [23].

The profiler is also computing the overall execution time

tace by using the Xputer as accelerator. The time taceincludes delay times for synchronization, possiblereconfigurations and memory re-mappings of the Xputerduring run time (see equation (1)).The iterative partitioningprocess tries to optimize tace and is based on simulatedannealing, which is described later in this chapter.

(eq. 1)t = ~t +~t +~t+ace £..J exe. £..J exe . £..J r

i E HT I j E XT J j E XT

L tmem.+ L tsyn- L tovj E XT J VXputerCalls j E XT

whereas:

~ t : sum of execution times of tasks£." exeli e HT executed on the host (H1)

L texe : sum of execution times of tasksj e XT j executed on the Xputer (XT)

L trje XT

: sum of delay times for reconfiguring theXputer during run time

~ t : sum of delay times for re-mapping the 2-£." memoj e XT J dimensional organized Xputer data map

during run time

L tsyn:sum of delay times for synchronizingVXputerCal/s hostlXputer (operating system calls)

L tovVXT

: sum of overlapping execution timesbetween tasks executedsimultaneously on hostlXputer

The overall execution time is deteffilined by delay timesof the basic blocks (host and Xputer), plus the abovementioned penalty times (see tacc' equation (1)). Memory

re-mappings are necessary, when two basic blocks use thesame data onto the Xputer, but they are needing a differentdistribution of the data within the two-dimensionalorganized memory. Then a re-ordering of the data itemsmust be perfOffiledbefore the execution of the second basicblock starts, which must be also considered in equation (1).Thevalueof tace is usedas COST-functionin thesimulatedannealing process (see figure 3) and has to be minimized foroptimizing the acceleration-factor of an application (seeequation (1)): The COST-function is determined each timefrom the profiler according to equation (1) using the actualviewed partitioning of the simulated annealing process:

Due to the data dependencies the profiler takesconcurrent evaluations into consideration. The possibledelay times for reconfiguring the Xputer during run timewill be necessary, if a partition moves more basic blocks tothe Xputer, than parallel GAG- or rather rALU-units areavailable, or if a fast on-chip reconfiguration is necessaryfor an Xputer-task. If possible, the reconfiguration isperformed in parallel to running host tasks. For faster accessall delay times are stored in a lookup table. For speedimprovement of the simulated annealing algorithm, the costincrease or decrease due to the exchange is computed only.The rest of the basic blocks are not considered.

Simulated Annealing. The iterative partitioning phase isbased on a simulated annealing algorithm [20]. Ouralgorithm computes differentpartitionings of Xputer tasksbyvarying their task allocation between host and Xputer. TheXputer tasksof the initialpartitioning are swapped. If thenewpartitioning results in a lower overall cost, it is accepted. Ifnot, there is still a finiteprobability to accept.This probabilitydepends on the temperature of the annealing process. Thisavoids that the algorithm gets stuck in a local minimum.Since a good initial partitioning is used at the beginning, westart with a low initial temperature. The temperature isgradually lowered fast at the beginning and slower at theend.algorithm SIMULATED ANNEALINGbegin

temperature = INITIAL_TEMP.partitioning = INITIAL_PARTITIONINGwhile (temperature> FINAL_TEMP.) do

for trials = 0 to MAXIMUM_TRIALS donew-partitioning = PERTURB(partitioning);~C = COST(new-partitioning) -

COST(partitioning);if «~C < 0) II (RANDOM(0,1) < exp(-~C/T)))then partitioning = new-partitioning;

temperature = SCHEDUlE(temperature)end.

Figure 6.The Simulated Annealing Algorithm

81

I.

The exchange function PERTIJRB (see figure 3) usesseveralpossibilities to change the partitioning randomly:

. A large Xputer task is split into several smallertasks, and vice versa.

. One or more Xputer tasks are moved from onepartition to the other.

The PERTURB-function is randomly choosing and usingone of these two possibilities, because simulated annealingis a probabilistic algorithm of optimizing combinatorialproblems, where the exchanging of elements is completelyarbitrary.

3.2 Resource-driven 2nd level PartitioningThe X-C compiler, which realizes the 2nd level of

partitioning of CoDe-X, translates an X-C program intocode which can be executed on the Xputer without furtheruser interaction. It comprises four major parts: the datasequencer parameter generator (DSPG), the datapathsynthesis system (DPSS), and the analysis/profiling tool (NP) together with the partitioner.

The partitioner at 2nd level (see Figure 3.) performs adata and control flow analysis. First the control flow of theprogram graph is partitioned according to the algorithm ofTatjan [32] resulting in a partial execution order. Thisalgorithm is partitioning the program graph into subgraphs,which are called Strongly Connected Components. Thesecomponents correspond to connected statement sequenceslike fully nested loops for example, which are possiblyparallelizable. The Xputer hardware resources have notbeen considered until now. So second the obtained coarse-grained components have to be transformed such that:

. theresultingsequencecomprisesblocksofpossiblysimilarsize,and

. a goodexploitationof thegivenhardwareresources can be guaranteed by using availableparallelism

This second partitioning of the data flow is improved byusing a heuristic, which control the computational stepsexploiting the special Xputer hardware resources in anoptimized way [29]. This heuristic analyzes, if the structureof statement sequences can be mapped well to the Xputerhardware avoiding reconfigurations or idle hardwareresources. Xputers provide best parallelism at statement orexpression level. So in our approach we try to vectorize thestatement blocks in nested for-loops according to thevectorization algorithm of J. R. Allen and K. Kennedy [17],after a data dependency analysis has been performed {33].

The data sequencer parameter generator (DSPG)maps theprograms data in a regular way onto the two- dimensionallyorganizedXputer datamap, followedby a computation of theright address accesses (data sequencing) for each variable(see Figure 3.). This tool is computing the access sequences

r"

of each variable used inside of nested for loopsaccording tothe linear index functions of these variables.This means thatthe for loops of X-C programs are mapped onto parametersfor configuring one generic address generatorof the datasequencer, which is then generating the correspondingphysical addresses only by hardware.

The access sequences of up to 4 fully nestedloops can becomputed by this tool. A configuration file for the X-Ccompiler give~ the current restrictions of thehardware, e.g.number of GAGs available, size of rALD subnetsetc. Thisallows a flexible handling of the compiler for future up-~rades of the Xputer hardware. The datapath synthesissystem is responsible for the synthesis towards the rALD.The code optimizations of loop folding (pipeliningacrossiterations of for loops) and loop unrolling are performedbythe DPSS whenever possible. In the current version therDPA serves as rALD. Due to a general interface betweenthe rest of the X-Ccompiler and the synthesis system, it canbe replaced easily by another synthesis tool, if required.

The task of configuring the rDPA is carried out in thefollowing four phases: logic optimization and technologymapping, placement and routing, data scheduling, andfinally the code generation. Partitioning of the statementsonto the different rDPA chips is not necessary since thearray of rDPA chips appears as one array with transparentchip boundaries. The DPSS also gives the execution timeofthe compound operator in the rDPA. Since the worst casedelay times of the individual operators are known inadvance, the data scheduling delivers the completeexecution time. Further details about the X-C compiler andthe four phases of the DPSS, as well as examples of themapping onto the rDPA can be found in [29] and [11].

For each Xputer task the X-C compiler produces a trade-off between area, that means amount of rDPA resources,and performance is computed and displayed in a graph.

X-C Compiler

...datamap ) l rALUcodeXputer Compiler Section

operatorlibrary-- ~

ExperiencedUser .

Figure 7. Overview on the 2nd

partitioninglevel.

82

Now,for each Xputer task a single point in the trade-offgraphis chosen. Since the size of the rDPA array is fixed,thepoint with the maximum performance which fits ontotherDPAof the MoM module is taken. For this task theconfigurationset, the required time for configuration, andthe execution time is stored. Usually the followingoptimizationsare performed by the X-C compiler. 8

. fully nested loops: loop unrolling (or forlarge compound operators: loop folding)

. not fully nested loops:

8 inner loop: loop folding (or for smallcompound operators: loop unrolling)

8 outer loop: vectorization (to save area),or normal operation

The selection of the possible implementationof an Xputertaskis fully automaticandrequiresno userinteraction.

3.3 Experienced UsersThe experienced user is responsible for building a

generic function library with a large repertory of Xputer-library functions. The scan patterns as well as the rALUcompoundoperators can be described in the language MoPI[1],which fully supports all features of the MoM modules.The input specification is then compiled into Xputer code,namely thedatamap, the data sequencer code and the rALUcode, dependent on the concrete functions calls in the inputC-program (see figure 3). The rALU assembler (RAss)allows theextension of the operator library which is used asa base for the configuration of the rDPA (see figure 3). Alloperators of the programming language C are in theoperator library by default User specific functions for thedatapath units can be added.

4. Example: SmoothingAlgorithmSmoothing operations are used primarily for diminishing

spuriouseffects, that may be present in a digital image as aresult of a poor sampling system or transmission channel.Neighborhood averaging is a straightforwardspatial-domaintechniquefor image smoothing [8].Given an N x N imagef(x,y), the procedure is to generate a smoothed image g (x,y),whose gray level at each point (x,y) is obtained by averagingthe gray-level values of the pixels of f contained in apredefined neighborhood (kernel) of (x,y). In other words,the smoothed image is obtained by using the equation:

g (x, y) =~ L f (n, m)(n, m) e S

for x,y =0,1, ...,N-l. S is the setof coordinatesof pointsin the neighborhood of (but not including) the point (x,y),and M is a pre-computed normalization factor. This smal1example for illustrating the methods of CoDe-X wasdivided in four tasks. Two of them were filtered out in the

(eq. 2)

first step for being executed on the host in every case. Thesewere tasks containing I/O routines for reading inputparameters and routines for plotting the image, whichcannot be executed on the Xputer. The remaining two taskswere potential candidates for mapping onto the Xputer. Inone of these two tasks strip mining was applied by the 1stlevel partitioner, because one for-loop could be transformedaccording to figure 8.

The resulting smaller independent loops can executed inparallel on different MoM modules. The X-C compiler wasperforming loop unrolling additionally up to the limit ofavailable hardware resources (see section 3.2).

The profiler was computing the host- and Xputer- costfunctions for them. The data dependencies require asequential execution of the four tasks, which influenced theoverall execution time of this application. The final decisionwas to shift the two candidates for the Xputer to theaccelerator. The X-C compiler on the second level ofhardware/software co-design was then mapping these basicblocks onto the Xputer. In this final solution the Xputermust be configured only one time. The address generationfor the data accesses in the fully nested loops of the two

.fQr(row=O;row<6400-constl; row++)

. {

. fQr (col.=O; col. <6400-const2+ 1; col. ++ )

. 1sumval =Pix.[(row+O)*256 + (col.+O)] * Coeff[O];sumval += Pix.[(row+0)*256 + (col.+l)] * Coeff[1];sumval += Pix.[(row+0)*256 + (col.+2)] * Coeff[2];sumval += Pix.[(row+1)*256 + (col.+O)] * Coeff[3];sumval += Pix.[(row+l)*256 + (col.+l)] * Coeff[4];sumval += Pix.[(row+ 1)*256 + (col.+2)] * Coeff[5];sumval += Pix.[(row+2)*256 + (col.+O)] * Coeff[6];sumval += Pix.[(row+2)*256 + (col.+1)] * Coeff[7];sumval += Pix.[(row+2)*256 + (001.+2)]* Coeff[8];

Pix._new[ «row+dead_rows )*256+( col. +dead_ools»]

sumvallnormal3actor;

} I Strip} ~Mining

fQr(ind.=0; ind.<6400-constl;ind.=index+l000){..fm (row=ind.; row<min(ind.+lOOO,6400-constl); row++). {. fQr (col.=O; col.<6400-const2+1); col.++). 1

sumval=Pix.[(row+O)*256 + (col.+O)] * Coeff[O];sumval += Pix.[(row+0)*256 + (col.+l)] * Coeff[l];..

Figure 8. Transforming for-loop by using stripmining with block size 1000

83

Xputer tasks was handledeach time by one generic addressgenerator. The finalacceleration factor in comparison witha SUN SPARC10/51was 73.

5. ConclusionsCoDe-X, a two-levelpartitioning hardware/software co-

design framework for Xputers has been presented. TheXputer is used as universal accelerator hardware based onreconfigurabledatapaths.One of the new features is the twolevel co-designapproach. CoDe-X accepts C-programs andcarnes out theprofiling-driven host/accelerator partitioningfor performance optimization and resource-parameter-driven sequential/structural partitioning for acceleratorprogramming.At first level, performance critical parts of analgorithm are localized and shifted to the Xputer withoutmanualinteraction. The second level carries out a resource-driven compilation/synthesis from accelerator source codeto optimize the utilization of its reconfigurable datapathresources. From several application examples encouragingacceleration factors have been obtained in comparison to asingleworkstation without an accelerator-board.

6. References[1] A. Ast, J. Becker, R. W. Hartenstein, R. Kress, H. Reinig, K.

Schmidt: Data-procedural Languages for FPL-basedMachines; 4th Int. Workshop on Field Programmable Logicand Appl., FPL'94, Prague, Sept. 7-10, 1994, Lecture Notesin Computer Science, Springer, 1994

[2] N. N.: Configurable Logic, Design and Application Book;Atmel Coporation, San Jose, CA, 1994

[3] S. Churcher, T. Kean, B. Wilkie: The XC6200 FastMapTMProcessor Interface; 5th Int. Workshop on Field-Programmable Logic andApplications, FPL'95, Oxford, UK,Aug.lSept. 1995

[4] A. Despain, I.-J. Huang: Synthesis of Application SpecificInstruction Sets"; IEEE-Trans on CAD of Integrated Circuitsand Systems, Vol. 14, no. 6, June 1995

[5] R. Ernst, J. Henkel, T. Benner: Hardware-SoftwareCosynthesis for Microcontrollers; IEEE Design & Test, pp.64-75, Dec. 1993

[6] K. L. Pocek, D. Buell: Proc. IEEE Workshop on FPGAs forCustomComputingMachines,FCCM'94,Napa,CA,April 1993

[7] see [6], but 1994, 1995, and 1996[8] Gonzalez R. C., Wintz P.: Digital Image Processing;

Addison-Wesley Publishing Company, USA 1977[9] R. K. Gupta, C. N. Coelho, G. De Micheli: Program

Implementation Schemes for Hardware-Software Systems:IEEE Computer, pp. 48-55, Jan. 1994

[10] R. W. Hartenstein, J. Becker, R. Kress, H. Reinig, K.Schmidt: A Reconfigurable Machine for Applications inImage and Video Compression; Conf. on CompressionTechniques & Standards for Image & Video Compression,Amsterdam, Netherlands, March 1995

[11] R. W. Hartenstein, R. Kress: A Datapath Synthesis Systemfor the Reconfigurable DatapathArchitecture; Asia and SouthPacific Design Automation Conference, ASP-DAC'95,Nippon Convention Center, Makubari, Chiba, Japan, Aug. 29- Sept. 1, 1995

--

[12] R.W. Hartenstein, AG. Hirschbiel, M. Weber: "A NovelParadigm of Parallel Computation and its Use to ImplementSimple High Performance Hardware"; InfoJapan'90-International Conference memorizing the 30th Anniversaryof the Computer Society of Japan, Tokyo,Japan, 1990;

[13] see [12]: also in: Future Generation ComputerSystems no. 7,pp. 181-198 (North-Holland, 1991/92)

[14] R. Hartenstein, (opening key note): Custom ComputingMachines - An Overview; Workshop on DesignMethodologies for Microelectronics, Smolenice Castle,Smolenice, Slovakia, Sept. 1995

[15] R. Hartenste!n, J. Becker, R. Kress: CustomizedComputers:a generalized survey; submitted for FPL'96, Darmstadt,1996

[16] T. A. Kean: Configurable Logic: A DynamicallyProgrammable Cellular Architecture and its VLSIImplementation; Ph.D. Thesis, University of Edinburgh,Dept. of Computer Science, 1989

[17] K. Kennedy: Automatic Translation of Fortran ProgramstoVector Form; Rice Technical Report 476-029-4, RiceUniversity, Houston, October 1980

[18] R. Kress: A fast reconfigurable ALU for Xputers; Ph.D.dissertation (submitted), Kaiserslautern University, 1996

[19] R. Kress: Computing with reconfigurable ALU arrays; ITPress (planned for 1996)

[20] L. Lin: High-Level Synthesis, Introduction to Chip andSystem Design; Kluwer Acad. Pub!., Boston, London, 1992

[21] D. B. Loveman: Program Improvement by Source-to-SourceTransformation; Journal of the Association for ComputingMachinery, Vol. 24,No. I, pp.121-145, January 1977

[22] W. Luk, T. Lu, I. Page: Hardware-Software codesign ofMultidimensional Programs; Proceedings of the IEEEWorkshop on FPGAs for Custom Computing Machines,FCCM'94, Napa, CA,Aprill994

[23] S. Malik, W. Wolf, A. Wolfe, Y.-T. Li, T.-Y. Yen:Performance Analysis of Embedded Systems; NATO/ASI,Tremezzo, Italy, 1995, Kluwer Acad. Publishers, 1995

[24] P. Marwedel, G. Goossens (ed.): "Code Generation forEmbedded Processors", Kluwer Acad. Publishers, 1995

[25] D. Monjau: Proc. GIIITG Workshop Custom Computing,Dagstuhl, Germany, June 1996

[26] N. N.: Configurable Logic Array (CLAyTM);PreliminaryDatasheet,NationalSemiconductors,SantaClara,CA,Dec. 1993

[27] P. Puschner, Ch. Koza: Calculating the Maximum ExecutionTlIDeof Real-TlIDePrograms; Journal of Real-Time Systemsp. 159-176, Kluwer Academic Publishers 1989

[28] Sato et aI.:An IntegratedDesign Environment for ApplicationSpecific Integrated Processors, Proc. ICCD 1991

[29] K. Schmidt: A Program Partitioning, Restructuring, andMapping Method for Xputers; Ph.D. Thesis, University ofKaiserslautem, 1994

[30] K. Schmidt: Xputers: a high performance computingparadigm; IT Press (planned for 1996)

[31] N. A. Sherwani: Algorithms for Physical DesignAutomation; Kluwer Academic Publishers, Boston 1993

[32] R. E. Tatjan: Testing Flow Graph Reducibility; Journal ofComputer and System Sciences 9, pp. 355-365, 1974

[33] M. Wolfe, C.-W. Tseng: The Power Test for DataDependence; IEEE Transactions on Parallel and DistributedSystems, Vol. 3, No.5, Sept 1992

84

l