Hardware Support for QoS-based Function Allocation in Reconfigurable Systems

Transcription

1 Hardware Support for QoS-based Functon Allocaton n Reconfgurable Systems Mchael Ullmann, Wansheng Jn, Jürgen Becker Unverstät Karlsruhe (TH), Germany {ullmann, jn, becker}@tv.un-karlsruhe.de Abstract Ths contrbuton presents a new approach for allocatng sutable functon-mplementaton varants dependng on gven qualty-of-servce functonrequrements for run-tme reconfgurable mult-devce systems. Our approach adapts methodologes from the doman of knowledge-based systems whch can be used for dong run-tme hardware/software resource usage optmzatons. Keywords: CBR, Algorthm, Resource Management. Introducton Durng the last four years FPGAs have become the favorte prototypng devces n many applcaton areas of computer scences and electrcal engneerng. Snce modern FPGAs have a hgher ntegraton densty offerng features lke partal run-tme reconfguraton (e.g. on Xlnx Vrtex II FPGAs) they have become attractve for a varety of embedded applcatons and scentfc approaches explotng theses features. Partal run-tme reconfguraton enables for a new class of embedded applcatons utlzng FPGA resources at run-tme as flexble and adaptve hardware-accelerated coprocessors []. Furthermore there already exst frst academc approaches mplementng a complete reconfgurable system-on-chp supportng run-tme reconfguraton of dedcated functons and ther management at run-tme [7][8]. Other researchers already have mplemented low budget embedded operatng systems runnng on soft-core or hard-wred on-chp processors on FPGA (e.g. uclnux on a Xlnx McroBlaze [9]). Combnng these approaches usng one or several low-cost reconfgurable devces plus dedcated hardware lke ASICs or DSPs wll create flexble and hghly adaptve mult-purpose systems whch can be appled n a varety of applcaton domans (e.g. automotve nfotanment, multmeda, control-orented applcatons etc.). The development and proof of such a versatle system concept s a man research topc of our research group. Our prevous work conssted n the development and mplementaton of a frst run-tme reconfgurable system-on-chp, supportng flexble ondemand hardware-task swtchng and a sophstcated runtme reconfguraton and task management mechansms on Xlnx Vrtex II FPGAs [7][]. Although the tested applcaton doman n our prevous work targets at automotve control applcatons wth soft tme and securty constrants we ntend to extend our approach for other felds of applcaton as already mentoned above. Common embedded systems usually have a set of subfuncton realzatons targetng only one type of hardware for ther executon (e.g. as slow software or hardware accelerated functonalty only). Addtonally the locaton for executon s normally pre-defned at desgn tme. We address ths weak ponts, snce we beleve that run-tme reconfgurable systems n combnaton wth dedcated hardware resources wll have benefts compared to ordnary embedded applcaton approaches whch cannot flexbly adapt to changng needs of users. Furthermore by applyng ntellgent management mechansms we conceve to gan ncreases of system-performance and energy/power-effcency. Fgure. Applcaton (MP3-Player) Applcaton 2 (Vdeo) Applcaton 3 (Automotve ECU) APPLICATION-API (QoS, Functons, Communcaton) Functon- Allocaton- Management CBR-based Functon-/ HW-Resource Selecton Applcaton (Crusecontrol) HW-Layer API (Data, Functon-Negotaton, Reconfguraton) Local Run-Tme Control (GP-Proc) CPU Local Run-Tme Control (FPGA ) Functon Functon Local Run-Tme Control (FPGA n ) Functon Functon Opcode/Btstream-Repostory (FLASH) Reconfgurable HW/SW System As shown n fgure our prevous approach can be reused as multple entty at the lower reconfgurable hardware layer of our conceved system approach. Addtonally dedcated hardware can be added n parallel. The system s logcally dvded nto dfferent layers. At the applcaton level dfferent applcatons are executed dependng on the locaton and the mode of operaton (as parallel hardware or sequental software tasks). Most Proceedngs of the Desgn, Automaton and Test n Europe Conference and Exhbton (DATE 5) 53-59/5 $ 2. IEEE

2 applcatons are conceved to have major parts n software and some dedcated parts accelerated n reconfgurable hardware or DSP. The applcaton level s separated from the lower system levels by an Applcaton-API whch offers servces for communcaton, sub-functon calls and qualty of servce (QoS) negotaton. A further system level below s responsble for the proper allocaton of functons. Dependng on the QoS demands, gven by the applcaton s functon call an approprate mplementaton of the desred functon must be found from a run-tme functon repostory. So ths layer needs nformatons about the avalable functons, ther dfferent mplementatons and QoS features. Addtonally t wll need nformatons about the current system load and power consumpton status, whch are procured by the HW-Layer API one level below. The HW-Layer API s the nterface for all hardware relevant aspects lke resource consumpton, low-level communcaton and reconfguraton of system parts. It connects the hgh level components wth the local system controllers, whch may be located on dfferent devces (e.g. standard CPU, FPGA (soft-core CPU) or DSP). These controllers are responsble for the control of local run-tme reconfguraton and other sub-tasks lke local task/ resource management and communcaton ssues. Ths paper wll focus on some aspects of a QoS-aware functon allocaton so that detals on the other system levels as they were not publshed yet wll be presented n future papers. Our contrbuton s structured as follows: In secton 2 we gve a motvaton for QoS-aware functon allocaton and how t can be solved by means of a smplfed case-based-reasonng approach. Secton 3 descrbes a short applcaton example for our case-basedreasonng approach whereas secton descrbes the hardware/ software mplementaton and synthess results of the algorthm. The paper closes wth a summary and gves an outlook on our future work. 2. QoS-aware Functon Allocaton In some cases, especally n multmeda applcatons t s not suffcent to do a smple functon call f a dedcated functon s needed whch has to comply wth addtonal constrants lke data/frame-rates, processng modes, response deadlnes etc. We conceve that the system offers for one requested functon type dfferent mplementatons whch can be run as software or as reconfgurable accelerated hardware havng dfferent features. So there emerges the problem to dentfy a set of most approprate mplementaton varants whch match best to the gven constrants from request. The found set of mplementaton varants can be used for checkng the current system load and resource consumpton state concernng the feasblty of a best matchng mplementaton out of t whch can be nserted on FPGA or as software-task on a processor. It s possble that the best matchng mplementaton s not currently feasble wthout preemptng other actve (hardware) tasks so an alternatve mplementaton can be offered to the callng applcaton whch has to decde on t. The detals on ths QoS negotaton mechansm as they are not presented here wll be n the scope of future papers. At ths pont t s prmarly here of nterest how a best matchng mplementaton by gven constrants can be found. Before we ntroduce our approach we want to gve an overvew on case-based reasonng and how parts of ths approach can be appled for solvng that problem based Reasonng Background -based reasonng (CBR) s an approach for developng knowledge-based systems that are able to retreve and reuse solutons that have worked for smlar stuatons n the past. CBR traces ts roots to the work of Roger Schank, Janet Kolodner and Mchael Lebowtz n the early 98s [2][5][6]. Snce the begnnng of the 99s CBR approaches are extensvely appled n helpdesk applcatons and dagnostc expert systems for customer support. In CBR systems expertse s emboded n a lbrary of past cases, rather than beng encoded n classcal rules. Each case typcally contans a descrpton of the problem, plus a soluton and/or the outcome. The knowledge and reasonng process used by an expert to solve the problem s not recorded, but s mplct n the soluton. To solve a current problem: the problem s matched aganst the cases n the case base, and smlar cases are retreved. The retreved cases are used to suggest a soluton whch s reused and tested for success. If necessary, the soluton s then revsed. Fnally the current problem and the fnal soluton are retaned as part of a new case. The complete CBR-cycle s shown n fgure base Representaton and Smlarty Problem cases may have dfferent representatons. These can be object-orented, trees & graphs or sets of smple pars of attrbutes and ther values. We have found the latter representaton appears to be best suted for our purposes, snce attrbutes of some type may descrbe comparable features of dfferent mplementatons. The attrbutes values depend on ther type and gven value range and can be of nteger/real type, even dscrete ordered sets of symbols are possble f they can be mapped onto ntegers. Typcal types can be data-rates, dscrete processng modes (float/nteger), power consumpton, code/btstream-szes, response tmes, frame szes, max. bt-error-rates etc. A local smlarty measure s needed for comparng attrbutes of same type between dfferent mplementatons. Such a measure s often based Proceedngs of the Desgn, Automaton and Test n Europe Conference and Exhbton (DATE 5) 53-59/5 $ 2. IEEE

3 on a transformaton functon whch calculates from the Eucldan or Manhattan dstance of two gven attrbutes a smlarty value n the range [... ], where means that both attrbute values are dentcal and means that both values have a maxmum dstance (no smlarty). dx A,xB sx A,x B=- ; dx A,xB. () f +max d x,x j An example functon s gven n equ. () where x A, x B are attrbute values of same type from a request A and an mplementaton case B. The functon d(x, x j ) calculates the dstance / absolute dfference between both values where max(d(x, x j )) represents the maxmum possble dstance whch can be determned at desgn tme from all attrbutes of same type gven by the mplementaton lbrary. Snce the request and mplementaton descrptons may contan several attrbutes t s not suffcent to calculate for every attrbute par (A Req_, A Impl_ ) a local smlarty s. All local smlartes s have to be combned nto a global smlarty whch enables for comparng all mplementaton varants of same basc functon type wth the attrbute descrpton set of a gven functon request. Such a needed functon S global s denoted as amalgamaton functon whch transforms an nput vector located nsde an n-dmensonal cube [... ] n back nto a scalar range of [... ]. A convenent functon s the weghted sum of all local smlartes as shown n equ. (2). It s monotonous n every argument and S global (,...,)=; S global (,...,)=. n S s,, s w s ; w. (2) f global n At ths pont t should be noted that other approaches for smlarty calculatons are possble as well. A well known method comes from statstcal decson theory and determnes the Mahalanobs dstance by calculatng the co-varance matrx of the whole set of functon attrbutes. Ths method s very effectve concernng the results but the computatonal efforts would be too large so we decded to apply Manhattan dstance metrcs. Confrmed Soluton Retan Learned Tested/ Repared Revse Problem New Base Knowledge Solved n Suggested Soluton Retreve New Retreved Reuse Fgure 2. -based reasonng- cycle [] 3. Applcaton Example for Retreval Followng short applcaton example wll gve an mpresson how a retreval and smlarty comparson can be done. As shown n fgure 3 an applcaton requres an FIR-equalzer functonalty for audo DSP purposes. Each offered type of basc-functonalty has a global functon- whch s used for fndng the proper type entry nsde the functon mplementaton tree. The nodes of ths tree are ordered n a herarchy, where the nodes n the upper level represent all functon types whereas ther successor nodes at lower levels contan nformatons about ther related mplementatons lke the mplementaton- whch can have a unque system-global or a local value and a set of attrbutes, separable agan by unque type s, whch contan detals on each mplementaton s features lke processng btwdth, processng mode (nteger/float), output mode and samplng rate. Other attrbutes lke power consumpton, response deadlnes etc. are concevable. It should be noted here that such metrcs whch characterze a functonalty on QoS-aspects have to be pre-defned by the desgner as a set of attrbutes whose values are derved from smulatons and tests of the functon s model. Dependng on the applcaton s needs the request s attrbute composton may vary. Type FIR Equalzer Fgure 3. Functon Implementaton Tree = -Base Type= FPGA Impl. Impl = A CB_= 6 Btwdth A CB_2= A CB_3= 2 Type D-FFT Integer-Mode Output Surround A CB_= ksamples/s Type=2 Functon Request - Descrpton Desred Type: FIR Equalzer Type = Lst of Constranng Attrbutes A Req_ = 6 (Btwdth) A Req_3 = (stereo-mode) A Req_ = (ksamples/s) DSP Impl. Impl =2 A CB_= 6 Btwdth A CB_2= A CB_3= Request on -Base Integer-Mode Output Stereo A CB_= ksamples/s General Purp. Proc. Impl =3 A CB_= 8 A CB_2= A CB_3= Btwdth Integer-Mode Output Mono A CB_= 22 ksamples/s Functon request at case-base As frst step all functon type entres have to be checked for fndng the requred type ( Type ). It should not happen that the desred type s not found snce the applcaton s functonal requrements should already be known at desgn tme, otherwse the functon can not be served. In the gven example case the desred functon- Type = s found and three possble mplementatons for dfferent executon targets (FPGA, DSP, General Purpose Proc.) have to be checked. Fgure 3 shows that the request s attrbute-set does not have to be completely specfed; ncomplete subsets are possble as well whch s a nce property of case-based retreval. As next step all Proceedngs of the Desgn, Automaton and Test n Europe Conference and Exhbton (DATE 5) 53-59/5 $ 2. IEEE

4 correspondng attrbutes are retreved from each mplementaton attrbute sub-table and for every mplementaton k a smlarty value S global (k) s calculated by applyng equ. () and (2) as shown n table. If a correspondng mplementaton attrbute s not found, ts local smlarty s can be set to because a mssng attrbute can be seen as unsatsfable requrement. The d max values as used n table were taken from an extra table (not shown here) whch was generated at desgn tme contanng supplemental data on the attrbutes desgn-global upper/lower value bounds (see also fgure (rght maxrange - )). As the results show from table the DSP-based functon-mplementaton matches best to the gven requrements. The FPGA-mplementaton produces the second-best smlarty whereas the standard software mplementaton has a rather low smlarty whch would not satsfy the demands f the attrbutes were nspected manually. It s concevable to reject all results below a gven threshold smlarty. In the gven example the allocaton manager would check now for each acceptable soluton ts feasblty concernng the system load and would suggest the remanng mplementaton-varants to the callng applcaton. Snce every avalable functon realzaton has a unque dentfer t wll be possble to retreve the functon s correspondng confguraton data (CPU opcode/ FPGA btstream) from a global functon repostory for reconfguraton. Table. A Req_ A CB_ Impl. = : FPGA A Req_ A CB_ Impl. = 2 : DSP A Req_ A CB_ Impl. = 3 : GP-Proc Retreval smlarty example d( A Req_, A CB_ ) w j =/3 d( A Req_, A CB_ ) w j =/3 d( A Req_, A CB_ ) 8 8 w j =/3 d max 6-8=8 2-=2-8=36 S global d max 6-8=8 2-=2-8=36 S global d max 6-8=8 2-=2-8=36 S global s s s best It s stll possble that no matchng feasble varant was found so that the applcaton has to repeat ts request wth rather relaxed constrants gvng a chance to the thrd low performance mplementaton ( Impl =3). Otherwse the applcaton can not call the functon. If a functon was allocated and nstantated on hardware t s not necessary to repeat the retreval procedure at repeated functon calls. The allocaton manager could create a knd of bypasstoken contanng data one the prevous selecton whch can be reused at repeated functon calls so that only an avalablty check on the functon and ts allocated resources has to be done.. Hardware/Software Implementaton The functon allocaton manager s retreval functonalty can be mplemented n software or as hardware mapped algorthm. Although case-based retreval s a rather control orented algorthm we have been able to model, smulate and synthesze an accelerated retreval unt on FPGA... Data Structures As frst step the needed data structures for request and mplementaton-tree were defned. We decded to use lnear lsts whch can be connected by reference ponters for creatng complex tree structures. Each lst contans several entres lke s, values, ponters and s termnated by a dedcated NULL-entry. These lsts can be easly mapped on lnear organzed RAM-blocks f all lst elements use the same word length per entry (e.g. 6 or 32 bts). Fgure (left) shows the structure of a lst contanng the request descrpton ncludng the desred functon type, attrbutes and weghtng factors w to be used. The nternal order of entres s predefned so that an attrbute s s always followed by ts value and weght. Addtonally the attrbute-blocks have to be pre-sorted by ther n ascendng order. Ths measure s appled n all other lst-structures as well (see fgure 5) and ams at mprovng the retreval effcency of the algorthm. Because each attrbute has to be searched by ts n each mplementaton s attrbute-lst t s possble to avod a repeated search from the top of each lst. Lst entres presorted by Fgure. Functon Requrements Descrpton - Ponter Funktonstyp Functontype Attrbute Attrbute Wert Value Attrbute Gewcht Weght w Attrbute Attrbute Wert Value Attrbute Gewcht Weght w Lsten End of Ende Lst Request lst structure Lst entres presorted by Attrbutes Supplemental- Data Ponter Attrbute Lower Bound Upper Bound Attrbute Max-Berech Range - Attrbute Lower Bound Upper Bound Attrbute Max Range - Lsten End of Ende Lst Attrbute lst structure Request lst and attrbute lst Snce the next requested attrbute has a larger value than ts predecessor t s possble to contnue searchng from the current poston nstead of dong a repeated search from the top of the local lst. As a consequence the effort for searchng becomes lnear. Another auxlary lst whch s used for smlarty calculaton s shown n fgure (rght). The entres are grouped agan n blocks and they are pre-sorted by attrbute s for the same reasons as mentoned before. The fourth entry of each attrbute block (maxrange - ) contans a pre-calculated recprocal value of d max +. Proceedngs of the Desgn, Automaton and Test n Europe Conference and Exhbton (DATE 5) 53-59/5 $ 2. IEEE

5 Snce t s a constant we do not need to mplement an expensve hardware dvder savng resources. By usng the recprocal value we can do a rather fast multplcaton wth the attrbutes absolute dfference nstead of dong a slow dvson (see also equ. ()). Fgure 5 shows the mplementaton-tree structure whch s a herarchcal tree of three levels. Smlar to fgure 3 t contans a top level lst ncludng mplementaton-s and reference ponters to the correspondng mplementaton lsts. Each mplementaton lst contans blocks sorted by mplementaton wth ponters referencng to lsts of attrbute/value pars of each mplementaton. All partal lsts are generated at desgn tme creatng one bg block of lnear concatenated lsts. Fgure 5. Implementaton Tree / Base Lst Entry Ponter Funktonstyp Functontype Verwes Reference Ponter Funktonstyp Functontype Verwes Reference Ponter Funktonstyp Functontype Verwes Reference Ponter End Lsten of local Ende Lst Implementaton Lst Funktonsrealserung Funct. Implementaton Verwes Reference Ponter Funktonsrealserung Funct. Implementaton Verwes Reference Ponter Funktonsrealserung Funct. Implementaton Verwes Reference Ponter End Lsten of local Ende Lst Attrbutes of Implementaton Attrbute Attrbute Wert Value Attrbute Attrbute Wert Value Attrbute Attrbute Wert Value End Lsten of local Ende Lst Lst entres presorted by Lst entres presorted by Lst entres presorted by Level Level Level 2 Implementaton-tree structure.2. Hardware Implementaton The hardware mplementaton of the retreval unt was done by modelng ts behavor n Matlab Stateflow at frst. We developed some tools n Matlab for creatng and exportng all needed data structures (mplementaton-tree, request lst etc.) so that they can be easly used for testng purposes n Stateflow, VHDL and C. After testng and verfyng of our Stateflow model we converted the behavoral model nto syntheszable VHDL code by usng a specal converson tool JVHDLgen [3]. Ths tool s stll n beta state of development but t proved to work fne although we had to do some mnor restrctons to our Stateflow model snce not all features of Stateflow are currently supported. Addtonally some manual code modfcatons were necessary for syntheszng the model onto Xlnx Vrtex II 3 FPGA usng Xlnx ISE 6.2. Fgure 6. CLB-Slces: Max. Clock: Extract functon basc-type from request and look n case-base for correspondng entry Selecton of next functon mplementaton from sub-lst, store of correspondng mplementaton from case-base Determne type and value of next attrbute from request, get range constant d max from attrbute-supplemental lst Look n attrbute lst of mplementaton for a matchng attrbute entry and get ts value attrbute found da, A _ CB S S dmax A MULT8X8s: BRAMS(8Kbt): S S S w Last attrbute from request processed? yes S > S Best? Keep S and mplementaton Last mplementaton n lst? yes / delver most smlar mplementaton attrbute not found Most smlar retreval algorthm Fgure 6 gves an overvew on the man parts of the mplemented algorthm. The shown verson s able to fnd the most smlar mplementaton. The delvered results wll be the and smlarty value of the best matchng mplementaton. The man components of the retreval unt s data path are depcted n fgure 7. It should be noted that ths data path s schematc was derved from the Stateflow model as the generated VHDL code s less sutable for extractng control- and data path nformaton. The processng btwdth of all attrbute values was defned at 6 bt. Our tests showed that ths btwdth s suffcent even for fxed pont calculatons wthout serously losng accuracy. We have been able to show that we get the same retreval results n hgh precson floatng pont Matlab smulaton as we get from VDHL smulaton usng ModelSm. Table 2. Synthess results on XC2V3 Resources: Xlnx Vrtex II 3 77 MHz no no of % 2 of 96 2 % 2 of 96 2 % The hardware desgn takes CLB slces, two 2x8bt hardware multplers and can be operated at 75 MHz (see also table 2). A small amount of addtonal memory of about.5 kb s needed for storng the mplementaton-tree gvng space for a full set of 5 Proceedngs of the Desgn, Automaton and Test n Europe Conference and Exhbton (DATE 5) 53-59/5 $ 2. IEEE

6 functon types contanng mplementatons * attrbutes each, usng 6 bt words for each entry (see table 3, reference ponters are ncluded). Req_Data A ABS(X) Dff(A, A CB ) Req-MEM Type A Fgure 7. Req_Mem_Addr. w Exst A _CB S CB_Data (+D max_ ) - CB-MEM A _CB CB_Mem_Addr. Type A _CB TEMP Reals_ Reals max New_Req S= S *w S max CTRL (ncl.mem_ptr)? max? Req_Ptr S max Data-path - Most smlar retreval Apart from the hardware mplementaton we also mapped the retreval algorthm nto a C program runnng on a Xlnx McroBlaze soft-processor at 66 MHz. The software verson whch takes only 98 bytes of opcode and 28 bytes for varables proved to produce dentcal retreval and smlarty results for a selected set of test cases where we created dfferent mplementaton-trees and requests. The same test cases were appled to the hardware mplementaton and we compared the performance results of both mplementatons. As result we have found that our hardware verson s at 66 MHz about 8.5 tmes faster than the software soluton. Table 3. -base memory consumpton Dfferent types of attrbutes n total: Implementatons per functon type: Attrbutes per Request: Types of basc functons n total: Attrbutes per Implementaton: Memory consumpton of case-base: (6 bt-words each entry/ponter) Memory consumpton of request: 5. Conclusons and Outlook 6 (worst case) 5.5 kb 6 Bytes We have proved the feasblty of a hardware accelerated functon-retreval on QoS requrements based on methodologes from case-based reasonng theory. Although we adopted the CBR-retreval and smlarty determnaton steps for our purposes some mght argue that the presented approach does not mplement a complete CBR-cycle as shown n fgure 2. Actually many practcal CBR-mplementatons restrct to the retreval step only and re-use the found soluton wthout adaptaton and assessment step, snce a reasonable adaptaton of the found soluton s a very complex and tme consumng process, whch s not necessary n a retreval of statc mplementatons. Although the mplementaton-tree s currently a statc structure we conceve dynamc update mechansms of -Base-data structures and functon repostores at run-tme enablng for a self-learnng system as new aspects of our future work. Our next step wll be an extenson for gettng n most smlar solutons from retreval whch offers the possblty for checkng out the feasblty of dfferent matchng varants. Addtonally we thnk about optmzatons of the used mplementaton-tree structure and retreval fnte state automaton for gettng a better speed-up. Furthermore a rather compacted attrbute block representaton could be used for loadng s and values as blocks wthn one step speedng everythng up at least by factor References [] A. Aamodt, E. Plaza, -based reasonng: foundatonal ssues, methodologcal varatons, and system approaches, AI Communcatons, March 99, 7(l):39-59,. [2] B. Bartsch-Spörl, M. Lenz, A. Hübner, -Based Reasonng -- Survey and Future Drectons, Lecture Notes n Artfcal Intellgence, Vol. 57, Sprnger-Verlag, Berln, Hedelberg (999), pp [3] [] B. Grese, E. Vonnahme, M. Porrmann, U. Rückert, Hardware Support for Dynamc Reconfguraton n Reconfgurable SoC Archtectures, Proceedngs of the rd Internatonal Conference on Feld Programmable Logc and Applcaton (FPL'), 2, August, Sprnger, pp [5] J. L. Kolodner, Retreval and Organzatonal Strateges n Conceptual Memory, Lawrence Erlbaum, Hllsdale, New Jersey, 98. [6] R. C. Schank, Dynamc Memory: A Theory of Learnng n Computers and People, Cambrdge Unversty Press, New York, 982. [7] M. Ullmann, M. Hübner, B. Grmm, J.Becker,"On- Demand FPGA Run-Tme System for Dynamcal Reconfguraton wth Adaptve Prortes", Proceedngs of the rd Internatonal Conference on Feld Programmable Logc and Applcaton (FPL'), 2, August, Sprnger, pp [8] H. Walder, M. Platzner, A Runtme Envronment for Reconfgurable Hardware Operatng Systems, Proceedngs of the rd Internatonal Conference on Feld Programmable Logc and Applcaton (FPL'), 2, August, Sprnger, pp [9] [] Proceedngs of the Desgn, Automaton and Test n Europe Conference and Exhbton (DATE 5) 53-59/5 $ 2. IEEE