Zippy - A coarse-grained reconfigurable array with support for hardware virtualization

Transcription

1 Zippy - A oarse-grained reonfigurable array with support for hardware virtualization Christian Plessl Computer Engineering and Networks Lab ETH Zürih, Switzerland plessl@tik.ee.ethz.h Maro Platzner Department of Computer Siene University of Paderborn, Germany platzner@upb.de Abstrat This paper motivates the use of hardware virtualization on oarse-grained reonfigurable arhitetures. We introdue Zippy, a oarse-grained multi-ontext hybrid CPU with arhitetural support for effiient hardware virtualization. The arhitetural details and the orresponding tool flow are outlined. As a ase study, we ompare the nonvirtualized and the virtualized exeution of an ADPCM deoder. 1 Introdution and Related Work Coarse-grained reonfigurable arhitetures onsist of ALU-based ell arrays and bus-based interonnets. Coarse-grained devies exel in area and energy-effiieny for appliations that require many arithmeti and logial operations on byte and word-sized data. In the last years, many oarse-grained arhitetures have been proposed [14, 16, 12, 1]. Reonfigurable arhitetures arrange operations spatially, whereas proessors arrange operations (mainly) in time. While proessors an ompute arbitrarily large appliations, provided that suffiient memory exists, reonfigurable arhitetures run into a fundamental problem when an appliation exeeds the array size. Hardware virtualization denotes a set of tehniques that try to overome this limitation by utilizing the re-onfigurability of reonfigurable devies. Previously, we have lassified hardware virtualization approahes into three ategories [13]: Temporal partitioning, virtualized exeution, and virtual mahine: Temporal partitioning The first use of the term virtual hardware pointed to the analogy to virtual memory. In a virtual memory system, memory pages are swapped in and out of the main memory, giving appliations the illusion of a muh larger ress spae than physially existent. Similarly, reonfigurable omputing systems an allow appliations to use more hardware than physially existent by swapping in and out portions of the hardware using a reonfiguration proess. This onept leads to temporal partitioning, whih allows for mapping an appliation of arbitrary size to a reonfigurable devie with insuffiient hardware apaity. Temporal partitioning splits appliations into smaller parts, where eah part fits on the devie, and runs these parts sequentially. Related work in arhitetures for hardware virtualization inludes the timemultiplexed FPGA [15], the DPGA arhiteture [4], the Chameleon arhiteture [16] and the DRLE arhiteture [8]. Virtualized exeution Later, the term hardware virtualization was used in a slightly different way to desribe tools and arhitetures that allow for a ertain degree of independene between the synthesized appliation and the atual apaity of the reonfigurable devie. This approah stresses the analogy to instrution set proessors, where the definition of an instrution set deouples appliations from the atual hardware. Similarly, virtualized exeution strives for obtaining a ertain level of ompatibility within a reonfigurable devie family. This ompatibility is ahieved by the definition of a programming model and an atomi unit of omputation. Appliations are split into modules, where eah module fits onto the atomi operator. The programming model speifies the oordination and ommuniation between modules. A onrete instane of the exeution arhiteture an implement any number of atomi operators. The exeution order of the modules is determined either at run-time or at load-time. Examples for virtualized exeution arhitetures are PipeRenh [9], Sore [3], and WASMI [8]. We have also investigated virtualized exeution on the Zippy arhiteture [6, 7] in our previous work. Virtual mahine The virtual mahine approah tries to ahieve an even higher level of devie independene by following the onepts of virtual mahines 1

2 and portable ode. The appliation is speified for an abstrat exeution arhiteture and a hardware virtual mahine is responsible for remapping this speifiation for the abstrat arhiteture model to the onrete exeution arhiteture. Researh in hardware virtual mahines has been reported in [11, 10]. Although this approah seems intriguing sine it features platform independent hardware, no effiient implementation of a hardware virtual mahine has been shown so far. The Zippy projet aims at the investigation of a hybrid proessor onsisting of an embedded CPU and a oarsegrained reonfigurable array. Hardware virtualization is a entral aspet of the Zippy projet. Previously, we have desribed the Zippy arhiteture with its basi support tools featuring a system-level, yle-aurate simulation environment [7, 6, 5]. In ontrast, this paper fouses on the arhitetural features for hardware virtualization, espeially for the temporal partitioning approah. Up to now, work in temporal partitioning has onentrated on fine-grained arhitetures and netlists or data-flow graphs as appliation models. For oarse-grained arhitetures, temporal partitioning of netlists has been hardly treated so far. Most studies assume that appliations are speified in a high-level language and that only runtime intensive loops are mapped to the oarsegrained arhiteture. This leads to different problems, more related to parallelizing ompilation tehnology, e.g, loopunrolling, vetorization, modulo-sheduling. We argue that effiient hardware virtualization requires the simultaneous development of the arhiteture and the orresponding tool flow, rather than building virtualization tools on top of an existing or fully speified arhiteture. The Zippy framework with its parameterizable models and tools forms an ideal environment for suh an arhiteture-toolflow odesign. In Setion 2, the Zippy arhiteture and the orresponding tool flow is presented. Setion 3 disusses a ase study demonstrating the benefits of temporal partitioning. Finally, Setion 4 onludes the paper and points to further work. 2 The Zippy Arhiteture The Zippy arhiteture is not a single, onrete arhiteture but an arhitetural simulation model of a hybrid CPU. The model integrates an embedded CPU ore with a oarsegrained reonfigurable unit and an be widely parameterized to resemble whole families of hybrid CPUs. Zippy was reated to provide an experimentation framework for hybrid CPUs and, speifially, hardware virtualization. Zippy arhitetures are modeled at a level of detail that is suffiient for system-wide yle-aurate simulation. Besides the simulation tools, Zippy inludes a tool-hain to generate software and hardware exeutables. Along with our Reonfigurable Unit Coproessor Interfae Config. Memory Context Sequener FIFO FIFO Coarse Grained Reonfigurable Array Register Interfae Ctrl Addr Data Figure 1. Reonfigurable Unit Arhiteture previous work on virtualized exeution, the Zippy system arhiteture and the o-simulation framework has been presented in detail [7, 5, 6]. For our urrent work on temporal partitioning on oarse-grained arrays the Zippy arhiteture has been extended. Hene the following setion will onentrate on the hanges to the arhiteture in partiular to the reonfigurable ell that have been introdued to support temporal partitioning. Finally the supporting software tools are briefly disussed. 2.1 System and Reonfigurable Unit Arhiteture Zippy is omposed of two main units, the CPU ore and the reonfigurable unit (RU), attahed via a o-proessor port. The oproessor port is used for all data-transfers between the CPU and the RU and exposes all RU funtions to the CPU via read and write operations on the RU s register interfae. Figure 1 shows a shemati diagram of the reonfigurable unit. Zippy is a multi-ontext arhiteture, i.e., several onfigurations an be stored onurrently in the onfiguration memory. The RU an swith rapidly between these onfigurations. The ativation and sequening of onfigurations is ontrolled by the ontext sequener. The FIFOs are used to pass input data and results between the CPU ore and the reonfigurable array and also between different onfigurations (ontexts) of the RU. The register interfae provides aess to the RU funtion bloks to the CPU. The reonfigurable array is the workhorse of the Zippy arhiteture. The array is built of omputing ells, memory bloks, input and output ports and an interonnetion network. The interonnet splits into two substrutures, a bus interonnet and a loal interonnet struture. As with many parts of the Zippy arhiteture, the reonfigurable array is parameterized. Figure 2 shows the programmable bus interonnet of this 4x4 ell instane of the Zippy ar-

3 vbus_e 2.2 Reonfigurable Cell Arhiteture INP0 hbus_mem INP1 hbus_s hbus_n MEM0 MEM1 MEM2 MEM3 Figure 2. Reonfigurable Array: Bus Interonnet ray. Programmable routing swithes are indiated by small bus-driver symbols at the rossing of wires. There are three types of horizontal buses: the horizontal north buses (hbus n) that onnet ells in adjaent rows, the horizontal south buses (hbus s), that onnet ells in the same row, and the memory buses (hbus mem), that onnet all ells in a row to an on-hip memory blok. Additionally, the vertial east buses (vbus e) provide onnetivity between the ells in the same olumn. For the following disussion we onsider an array instane with 4x4 ells, 2 horizontal north and south buses, 2 vertial east buses and 2 input and 2 output ports. The bit-width of the ALUs and buses is onfigured to 24 bit. In ition to the bus interonnet the array provides also loal interonnet between neighboring ells. Eah ell an read the output data from all of its 8 immediate neighbors. The loal interonnet is also fully homogeneous thanks to ylial ontinuation at the edges of the array. The ells an read data from the FIFOs via the input buses (INP0/1) and they an write data to the FIFOs using the output buses (OUTP0/1). The ells an onnet to the input and output buses using the horizontal north buses. The ontrol signals for the FIFOs are generated by programmable ontrollers. OUTP0 OUTP1 Figure 3 presents a detailed view of the onfigurable ell. The ell has a rather versatile input struture with overall three inputs, an operator blok, and an output struture. Eah of the inputs an onnet to either of five soures: any loal neighbor, a horizontal bus, a vertial bus, a onstant, or to the ell s output register (feedbak path). The ell s onfiguration determines whih of these input soures or onstant values is atually seleted. The operator blok is ALU-based and performs the ell omputation. Figure 3 inludes a table of implemented ell operations. Most arithmeti and logial operations are selfexplaining. The pass operation passes the input value to the output (identity), what an be useful for routing purposes. The testbitat instrutions are used for bit-tests. testbitat0(value,mask) takes an input value and a mask and returns 1 if all bits that are set in mask are set to 0 in value, otherwise the operator returns 0. The testbitat1 operator works analogously for testing whether bits are set to 1. The (sel,a,b) operator forwards input a or input b to the output, depending on the value of the least-signifiant bit of sel. This operator is partiularly useful for implementing ontrol-flow, i.e., data-dependent proessing, on the reonfigurable array. Eah row of ells has aess to a shared ROM memory blok, f. Fig. 2. The rom(r) operation of a ell reads the ontents at ress r of the ROM assoiated with this ell. The ontents of the ROM are part of the onfiguration. Zippy is speifially designed to support hardware virtualization, in partiular through time-multiplexed exeution of iruits. To this end, the reonfigurable array arhiteture is designed as a multi-ontext arhiteture. A multiontext arhiteture an onurrently store several onfigurations on-hip. The ontext sequener whih is part of the RU an swith rapidly between these onfigurations and ativate one of the ontexts for exeution. All ontexts share the omputation elements in the data-path, but eah ontext has its own set of registers. This allows to store intermediate results generated by a ontext until the next ontext invoation and eliminates the need to use memory strutures to store these data and time-onsuming ontext store and restore phases. Moreover, the Zippy ell provides means for a ontext to read registers from other ontexts whih enables effiient data-transfers between ontexts. Figure 3 shows the integration of these per-ontext register files into the Zippy ell arhiteture. A reonfigurable ell features one input register file per input and an output register file. The ell inputs are always registered, independently of whether the data will later on be used or not. That is, when a ell reeives an input data in a given exeution yle, the data is written to the input register seleted by

4 hbus onst vbus hbusn hbusn txno... txno loal OP hbusn arithmeti ops:,sub,mul,neg logi ops: not,and,nand,or, nor,xor,xnor, srl,sll, ror,rol,pass test ops: eq,neq,lte,gte tstbitat0, memory ops: rom other ops: legend: determined by onfiguration determined by ative ontext txno Figure 3. Reonfigurable Unit: Cell Model the ontext seletor (txno). In the same yle, the input data for the operation blok is either a onstant, the diret ell input, or an be read from any of the input registers. This hoie is part of the onfiguration. The output of the operator blok is also automatially registered in the output register file ontrolled by the ontext seletor. In ontrast, the ell output is ontrolled by the onfiguration and an be seleted out of the diret operator output and any of the output registers. Generally, an appliation iruit ontains (ombinational) operators and registers. We all these registers user registers. A virtualized iruit requires itionally soalled virtualization registers that are used to transfer data between ontexts. While the registers in the register-rih Zippy ell an be used arbitrarily, we have deided to implement user registers in the ells input register files and the virtualization registers in the ells output register files. This speifi hoie has been made to simplify the proess of mapping virtualized appliations to the array. At the same time, this hoie imposes onstraints on the mapping and the ell usage. For example, an operation in ell x writes its result to the orresponding output register of that ell. An operator mapped to ell y in a subsequent ontext requiring this data as an input has to read from ell x. This leads to i) routing between the two ells and ii) the fat that the regular output of ell x annot be used in the subsequent onfiguration. The operation blok of ell x an, however, still be utilized. 2.3 Tool-flow and Simulation Environment The Zippy software support omprises a number of tools that allow a designer to generate appliations onsisting of parts running in software and parts running in hardware. The software tool flow inludes a C ompiler and a funtion library for aessing the reonfigurable hardware from the software appliation. The ompiler hain is based on SimpleSalar s versions of the GNU C ompiler and utilities and has been desribed in [5]. For mapping appliations onto the reonfigurable array, we have developed tools for tehnology-mapping, plaing and routing iruits onto the reonfigurable array. The appliations are given in graph form and are onverted to a textual desription in the Zippy Netlist Format (ZNF). Map, plae and route tools operate on this format. While these algorithms have been speifially tailored to the Zippy arhitetural model, they have been inspired by tehniques and algorithms known from FPGA plaement and routing [2]. After running the tools, the resulting plaed and routed netlist is passed to a onfiguration generator tool whih turns the array onfiguration into a format that an be read and loaded by the CPU during runtime. The performane evaluation of different Zippy arhitetures and virtualization tehniques is performed with our o-simulation framework whih has been disussed in [5, 7]. 3 Case Study The ase study illustrates the use of the Zippy arhiteture and in partiular its support for hardware virtualization. We ompare the exeution of an ADPCM appliation on a large instane of the Zippy arhiteture with a smaller instane of the same arhiteture. The large instane requires more area but allows to map the omplete appliation into one onfiguration. The smaller instane requires hardware virtualization to run the appliation. Both implementations are ompared to an implementation that uses only the CPU ore. 3.1 Appliation ADPCM is a well established speeh oding algorithm. Figure 4 presents our hardware implementation that has been manually derived from the C-ode referene implementation. ADPCM uses 31 ombinational operators (that an be diretly implemented by a ell), 3 dediated registers, 1 input, and 1 output port. The dediated registers an be implemented within the input register files of the Zippy ells, f. Fig. 3. Thus the hardware implementation requires an exeution arhiteture with at least 31 ells.

5 in t_120 t_230 t_231 t_232 op0 rom indextbl op2 gt : i1=88 index op1 op4a : i0=88 : i1=d op4 op19 rom stepsztbl op3 lt : i1=0 op4b : i1=0 op10 srl : i1=2 op11 srl : i1=1 ontext 0 ontext 1 step op15 op13 op12 srl : i1=3 op14 op16 op7 : i1=4 op6 and : i1=7 op8 : i1= op9 op17 : i1=1 obuf pass0 valpred ontext 2 op20 op24 lt : i1= op18 op21 sub op22 op23 gt : i1=32767 op25a : i0= : i1=d op25 op5 : i1=8 op25b : i1=32768 out Figure 4. ADPCM: appliation netlist 3.2 Experiments For the non-virtualized implementation, we have hosen a reonfigurable array of size 7x7. Although a 6x6 array would provide a suffiient number of ells, the dense interonnet struture of the ADPCM netlist leads easily to ongestion and makes plaement and routing on a 6x6 array rather diffiult. Using a 7x7 array relaxes the implementation onstraints and allows the tools to quikly find a routable implementation. For the virtualized implementation the full netlist has been manually partitioned into three smaller netlists, suh that eah of them fits onto an array of size 4x4. An automati partitioning has not been implemented at the urrent stage of the projet. Figure 4 presents the division of the initial netlist into three ontexts. Virtualization registers have been inserted where data has to be transferred from one ontext to another. These virtualization registers are denoted by t x y in this figure. For eah of these netlists, a onfiguration is generated using the Zippy plae and route tools. Figure 4 shows that for this implementation all feedbak paths of the iruit stay within single ontexts. It must be noted that this is not a requirement for hardware virtualization. Due to the virtualization registers, feedbak yles between ontexts are possible. The pure software implementation uses the C soure ode of the ADPCM referene implementation. The ode has been ompiled with SimpleSalar s GNU C ompiler, with optimizations turned on and set to -O. 3.3 Experimental Setup and Results The performane results for the pure CPU implementation have been obtained by simulation with SimpleSalar. SimpleSalar s onfiguration parameters have been hosen to math a typial embedded CPU ore with in-order exeution and stati branh-predition, f. [5]. Table 1 summarizes the results of the ase study and demonstrates the trade-off involved in hardware virtualization. The superior performane of the single-ontext, nonvirtualized implementation is paid for with more than 3 times the hardware effort of the virtualized, 3-ontext, implementation. Thus, hardware virtualization seems useful in two situations: First, it offers a sensible approah to redue the amount of required hardware while still making use of omputation in spae. Seond, when the given hardware is too small to aommodate the overall iruit, hardware virtualization is mandatory. The results for the pure software implementation have been determined by measuring the number of yles needed for deoding 512 bloks of 1024 samples. The non-virtualized implementation deodes 1 sample per yle. The virtualized implementation requires 3 yles for deoding one ADPCM sample. Eah of the three on-

6 Implemen- yles relative array tation per sample speedup size CPU only n. a. single ontext ells 3-ontext ells Table 1. Performane of the three different ADPCM implementations texts is ativated and exeuted for one yle. This shedule is repeated ylially. The maximal lok frequeny for the reonfigurable array is appliation-speifi and would have to be determined by analyzing the longest path of the mapped and routed iruit. The timing model we urrently use is quite inaurate and does not onsider mapping and routing. However, we envision an embedded CPU ore that runs at modest lok frequenies. This justifies the assumption that both CPU ore and reonfigurable unit run at the same lok rate. 4 Conlusions and Future Work We have presented the Zippy hybrid CPU that employs a oarse-grained multi-ontext reonfigurable array. A distintive feature of Zippy is its support for hardware virtualization. While one approah of hardware virtualization, namely virtualized exeution, has already been presented in [5], this paper foused on an approah termed temporal partitioning. The Zippy arhiteture and the simulation environment allow us to perform studies with hardware virtualization tehniques. This is of utmost importane, sine no ommerial implementations of suh arhitetures are readily available. By a ase study we have demonstrated the feasibility of hardware virtualization and the involved trade-offs between exeution time and required hardware. Future work will fous on the development of algorithms that automatially perform the temporal partitioning of appliations onto the Zippy arhiteture. Our long term goal is to reate an end-to-end tool-flow that starts with a hardware desription (in the ZNF netlist format) and reates an implementation that uses hardware virtualization if needed. Referenes [1] V. Baumgartne, F. May, A. Nükel, M. Vorbah, and M. Weinhardt. PACT XPP a self-reonfigurable data proessing arhiteture. In Pro. 1st Int. Conf. on Engineering of Reonfigurable Systems and Algorithms (ERSA), pages 64 70, [2] V. Betz, J. Rose, and A. Marquardt. Arhiteture and CAD for Deep-Submiron FPGAs. Kluwer Aademi Publishers, [3] E. Caspi, M. Chu, R. Huang, J. Yeh, J. Wawrzynek, and A. DeHon. Stream omputations organized for reonfigurable exeution (SCORE). In Pro. 10th Int. Conf. on Field Programmable Logi and Appliations (FPL), pages , [4] A. DeHon. DPGA utilization and appliation. In Pro. 4th ACM Int. Symp. on Field-Programmable Gate Arrays (FPGA), pages , [5] R. Enzler, C. Plessl, and M. Platzner. Co-simulation of a hybrid multi-ontext arhiteture. In Pro. 3rd Int. Conf. on Engineering of Reonfigurable Systems and Algorithms (ERSA), pages CSREA Press, [6] R. Enzler, C. Plessl, and M. Platzner. Virtualizing hardware with multi-ontext reonfigurable arrays. In Pro. 13th Int. Conf. on Field Programmable Logi and Appliations (FPL), pages , [7] R. Enzler, C. Plessl, and M. Platzner. System-level performane evaluation of reonfigurable proessors. Miroproessors and Mirosystems, 29(issues 2 3):63 73, Apr [8] T. Fujii, K.-i. Furuta, M. Motomura, M. Nomura, M. Mizuno, K.-i. Anjo, K. Wakabayashi, Y. Hirota, Y.-e. Nakazawa, H. Itoh, and M. Yamashina. A dynamially reonfigurable logi engine with a multi-ontext/multi-mode unified-ell arhiteture. In 46th IEEE Int. Solid-State Ciruits Conf. (ISSCC), Dig. Teh. Papers, pages , [9] S. C. Goldstein, H. Shmit, M. Budiu, S. Cadambi, M. Moe, and R. R. Taylor. PipeRenh: A reonfigurable arhiteture and ompiler. IEEE Computer, 33(4):70 77, Apr [10] Y. Ha, P. Shaumont, M. Engels, S. Vernalde, F. Potargent, L. Rijnders, and H. D. Man. A hardware virtual mahine for the networked reonfiguration. In IEEE International Workshop on Rapid System Prototyping, pages , [11] Y. Ha, S. Vernalde, P. Shaumont, M. Engels, R. Lauwereins, and H. De Man. Building a Virtual Framework for Networked Reonfigurable Hardware and Software Objets. Journal of Superomputing, 21(2): , February [12] T. Miyamori and K. Olukotun. REMARC: Reonfigurable multimedia array oproessor. IEICE Trans. on Information and Systems, E82-D(2): , Feb [13] C. Plessl and M. Platzner. Virtualization of hardware introdution and survey. In Pro. 4rd Int. Conf. on Engineering of Reonfigurable Systems and Algorithms (ERSA), pages CSREA Press, [14] H. Singh, M.-H. Lee, G. Lu, F. J. Kurdahi, N. Bagherzadeh, and E. M. Chaves Filho. MorphoSys: An integrated reonfigurable system for data-parallel and omputation-intensive appliations. IEEE Trans. on Computers, 49(5): , May [15] S. Trimberger, D. Carberry, A. Johnson, and J. Wong. A time-multiplexed FPGA. In Pro. 5th IEEE Symp. on Field- Programmable Custom Computing Mahines (FCCM), pages 22 28, [16] Xinan Tang, M. Aalsma, and R. Jou. A ompiler direted approah to hiding onfiguration lateny in Chameleon proessors. In Pro. 10th Int. Conf. on Field Programmable Logi and Appliations (FPL), pages 29 38, 2000.