Multigranular Simulation of Heterogeneous Embedded Systems

Transcription

1 Multgranular Smulaton of Heterogeneous Embedded Systems Adtya Agrawal Insttute for Software Integrated Systems Vanderblt Unversty Nashvlle, TN adtya.agrawal@vanderblt.edu Akos Ledecz Insttute for Software Integrated Systems Vanderblt Unversty Nashvlle, TN akos.ledecz@vanderblt.edu ABSTRACT Heterogeneous embedded systems, where confgurable or applcaton specfc hardware devces (FPGAs and ASICs) are used alongsde tradtonal processors, are becomng more and more wdely used. To facltate rapd desgn and development of such heterogeneous hardware/software systems, t s essental to expand the software desgn cycle to ntegrate hardware modelng and smulaton. Cosmulaton and exploraton of the jont desgn space are key problems. To desgn, develop and verfy such systems, dfferent knds of smulatons at varous levels of granularty are requred. The hardware modelng and smulaton framework of the Model- Based Integrated Smulaton Framework (MILAN) ntegrates these requrements nto a sngle powerful desgn, development and smulaton envronment. Categores and Subject Descrptors E.3 [HW/SW co-desgn]: specfcaton, modelng, cosmulaton and performance analyss, system level parttonng and schedulng. General Terms Performance, Desgn, Standardzaton, Languages and Verfcaton. Keywords Modelng, Orthogonalzaton, Desgn space and Smulaton. 1. INTRODUCTION Confgurable FPGAs and fast ASICs are pushng embedded systems to mplement more and more functonalty drectly n hardware. However, to facltate the rapd desgn and development of such heterogeneous hardware/software systems, t s essental to expand the software desgn cycle to ntegrate hardware modelng and smulaton. The Model-based Smulaton Integraton Framework (MILAN) [1][2] provdes a unfed envronment for the desgn and smulaton of these heterogeneous systems. Such a unfed envronment poses unque requrements that need to be fulflled. One mportant requrement of the heterogeneous desgn paradgm s the orthogonalzaton of concerns, that s to separate varous aspects of desgn n order to effectvely explore alternatve solutons [9]. For example, system requrement specfcatons and mplementaton or computaton and communcaton are good canddate concerns that should be separated. In large and complex systems there s a need for modular desgn to mtgate complexty. Systems are typcally desgned n terms of components and component nteractons. A component usually embodes some knd of computaton and t has a standardzed nterface for communcaton. Ths helps to separate computaton from communcaton and the developer can desgn and mplement one wthout beng concerned wth the other. Separaton of system requrements and mplementaton s desrable because the former captures the ntenton of the system desgner and provde a hgh level vew, whle the latter s specfc and s done at a much fner level of granularty. By capturng the ntenton separate of the mplementaton, the hgh level abstracton s preserved, allowng the user to specfy alternate mplementatons for the same ntent. These alternatves may be n the form of dfferent algorthms to solve the same problem, a choce between hardware and software mplementaton, or a selecton of programmng language. Furthermore, mplementaton s a refnement of the ntent and needs to be captured at dfferent levels of granularty. Intally a coarse gran mplementaton s used for prototypng. Ths

2 can be transformed n stages to a detaled low-level mplementaton later. By capturng alternatve mplementatons at dfferent levels of granularty we gan the flexblty of choosng the mplementaton accordng to the exact needs of the system. The development cycle starts from a coarse gran mplementaton. Ths s tested for functonal correctness and s then refned to dfferent alternatve mplementatons. The feasblty of these alternatves s explored by proflng them. Ths s followed by system smulaton of a few feasble system wde mplementatons to valdate the system wth respect to the requrements. Smulaton becomes more mportant as testng of these applcatons on actual hardware s expensve and tme consumng, especally for applcatons mplemented n hardware such as FPGAs or ASICs. These desgn and development phlosophes exst and are used n real world embedded systems and can be used for the expanded role of computer-based systems. In the absence of an ntegrated desgn and development envronment, a varety of tools are used to acheve all the above needs. These tools more often than not are ncapable of exchangng desgn, mplementaton and data between each other forcng developers to duplcate nformaton manually between tools. Ths s a tme consumng, neffcent and a error-prone. In order to speed up the desgn cycle, there s a need for an ntegrated desgn and development framework that facltates all these requrements. The Model-based Smulaton Integraton Framework (MILAN) [1] s a sute of tools developed to ntegrate the followng desgn and development needs: Sngle desgn representaton to use n dfferent smulatons and software synthess, Separaton of concerns, Capture dfferent levels of herarchy for refnement. Synthesze code to drve varous smulaton methodologes: solated smulaton, multgranular smulaton, full system smulaton, Speed up the desgn and development cycle for rapd applcaton development. The focus of ths paper s on the modelng paradgm for applcatons mplemented n hardware and the assocated tools ntegrated nto MILAN. These tools consst of an ntegrated envronment to specfy modular system desgn wth alternatve mplementatons. At the lowest level, desgners need to provde SystemC or VHDL mplementatons. The tools are capable to drve varous knds of smulatons from these specfcatons to provde for verfcaton of functonalty and performance. The knds of smulaton supported are solated smulaton of components, mult-granular smulaton of the system, complete system smulaton and smulaton of hardware n heterogeneous hardware/software systems. We begn n Secton 2 by dscussng Model Integrated Computng (MIC) and an overvew of MILAN. In Secton 3 we dscuss the modelng methodology of MILAN wth focus on hardware modelng, followed by the nterpretaton of the models to drve varous smulatons n Secton 4. We conclude n Secton MILAN OVERVIEW The software nfrastructure of MILAN s based on Model Integrated Computng (MIC). MIC employs domanspecfc modelng methodology to represent the system beng desgned. The system models are then used to automatcally synthesze the applcatons and/or to generate nputs to analyss and/or smulaton tools. Ths approach speeds up the desgn cycle, facltates the evoluton of the applcaton, and helps system mantenance, dramatcally reducng costs durng the entre lfecycle of the system. MIC s mplemented by the Generc Modelng Envronment (GME), a metaprogrammable toolkt for creatng doman-specfc modelng envronments [6]. MILAN s a typcal MIC applcaton. Its archtecture s depcted n Fgure 1. The doman-specfc modelng paradgm developed specfcally for MILAN enables the specfcaton of the system n the form of multple-aspect, herarchcal, prmarly graphcal models n GME. The three man categores of models specfy the desred applcaton functonalty, avalable hardware resources and non-functonal requrements n the form of explct constrants. The applcaton models capture the dataflow of the system. Both asynchronous and synchronous dataflow s supported, as well as ther composton. By allowng the specfcaton of explct desgn and mplementaton alternatves as part of these models, MILAN captures the desgn space [10] of the applcaton, not just a pont soluton. Sze, weght, energy, performance and tmng (SWEPT) requrements are also part of the models n the form of formal constrant. Only a subset of the potentally exponentally large desgnspace satsfes all these constrants. A symbolc constrant satsfacton methodology s appled to explore and prune the desgn-space. Once a sngle desgn has been selected, generators translate the models nto the nput of the selected smulators. Smulators already ntegrated nto MILAN nclude Matlab [8], SystemC [12], HperE, a hghlevel performance estmator developed n parallel wth

3 MILAN [13], SmpleScalar [4], Armulator [3]. Some smulaton results need to be ncorporated back n the models n the form of performance attrbutes of components, for example, to make them avalable for other smulators. For some smulators ths wll necessarly be a human-n-the-loop process, whle for others the procedure can be automated. Generc Modelng Envronment (GME) 1. Modelng of hardware applcatons usng doman specfc concepts and to separate the concerns. 2. Strong data typng of communcaton ports for accurate smulaton of data exchange and to catch modelng errors at desgn tme. 3. Parameterzaton of components to develop generc modules for reuse, as well as to desgn a set of solutons nstead of a sngle soluton. Applcaton Models Constrants Resource Models 4. Data abstracton and nformaton hdng to better manage complexty usng multple aspects of the same module. Functonal Smulator Power Smulator Desgn-Space Exploraton and Prunng DESIGN System Synthess Hgh-Level Smulator Performance Smulator 5. Explct desgns of alternatve mplementatons to capture desgn choces n order to better explore dfferent solutons. 6. A paradgm to compose hardware and software components together to facltate the desgn of heterogeneous systems. SYSTEM Fgure 1. MILAN Archtecture Model Interpreter confgurng/drvng smulator Model Interpreter feedng Data back to the models The fnal component n the MILAN archtecture s Software Synthess. Notce that ths step s smlar to drvng smulators. Instead of targetng the executon model of a smulaton engne, the synthess process needs to generate code for a gven runtme system. Just lke there s a need to support multple smulators, MILAN supports multple target runtme systems. The goal of the paper s to descrbe how a careful composton of a varety of modelng concepts can result n a hghly doman-specfc modelng methodology that supports the unque needs of the complex applcaton doman of smulaton of computer-based systems. We shall focus on modelng of applcatons mplemented n hardware and how the models are used to drve the varous types of smulaton. 3. MODELING METHODOLOGY Modelng s an abstracton of the system and captures specfc detals requred to best represent, understand, mplement and modfy the system. Tradtonal hardware desgn approaches and the need for ntegratng wth the expandng doman of computer-based systems motvated us to ncorporate varous modelng methodologes to mtgate complexty, separate concerns and to provde for effectve management and mantenance of these systems. The wde varety of doman specfc modelng concepts that has been ncorporated are as follows. 3.1 Hardware Modelng The goals whle developng the hardware applcaton modelng paradgm were separaton of concerns, flexblty to capture the mplementaton n dfferent languages and at dfferent levels of granularty. Another goal was to mtgate complexty to help desgn more manageable systems. The model of computaton n hardware s unbuffered herarchcal dataflow. Herarchcal dataflow mples that a dataflow node can contan a dataflow subgraph. Unbuffered dataflow means that the recever and sender need to be synchronzed. Ths model of computaton can alternatvely be looked at as the structural descrpton. The hardware modelng paradgm conssts of a set of modules mplementng behavor and drected lnks connectng modules specfyng the dataflow graph of the system. The modules are herarchcal, that s they can contan other modules and module assocatons formng a dataflow subgraph. Fgure 2 shows the basc meta model of MILAN s hardware-modelng paradgm. hwmodule s the basc buldng block. It s a herarchcal module as t can contan subgraphs. Ports defne the nput and output nterface of the module, whle hwsgnalconn s an assocaton between ports representng a data path. These ports can also be connected to and from a hwbus. Modules also contan hwdatastore whch represent memory elements. A module that doesn t contan a subgraph has processes assocated wth t. Processes specfy the behavor of a module. Ths s captured as functons mplemented n a hardware descrpton language such as VHDL or SystemC. Notce that, hwmodule contans hwfunctonbase, an

4 abstract base class. Ths class has been specalzed for SystemC and VHDL. It can also be specalzed to supported other languages later. The functons can be event drven or sequental. Events are specfed usng the hwtrgger connecton between processes and ports. Fgure 2. Meta model of the hardware applcaton paradgm. Herarchy n the modelng paradgm serves two purposes. Frst, t helps separate ntenton from mplementaton. Usng herarchy the system s desgned accordng to the ntenton, that s the hgh-level dataflow of the system. Then the desgn n refned by desgnng the modules n detals untl t s low-level enough to provde an mplementaton. Second, t helps to mtgate complexty. The dataflow graph of large systems can be very complex; herarchy hdes data at dfferent levels to make the systems more manageable. The functons can be specfed at any level of granularty and can be n ether VHDL or SystemC. Ths provdes the user wth the flexblty to choose between dfferent HDLs. Moreover mplementatons n dfferent languages can coexst provdng the user wth desgn choces. 3.2 Data Type Data type models n MILAN are used for several purposes. Frst of all, to accurately smulate communcaton performance, the amount of data exchanged needs to be captured. Furthermore, as data type models are attached to hardware modules, or more precsely to ther nput and output ports, they defne the nterface of those components. When the components are attached usng sgnal connectons, ther nterfaces are checked to ensure that only compatble objects are connected. Fnally, the data type models can also be used to generate the correspondng defntons n the target hardware descrpton language ensurng consstency. The MILAN data type modelng paradgm allows the specfcaton of both smple and composte types. Smple types, such as floats and ntegers, specfy ther representaton sze,.e. the number of bts used. Composte types can contan smple types and other composte types. Attrbutes of the felds specfy extra nformaton such as array sze or sgned/unsgned type. Data types supported by the C programmng language can be modeled n MILAN. Preexstng data types, specfed n a DSP lbrary for example, can also be modeled. Ther name and sze n bytes are the only nformaton MILAN requres. The hardware applcaton and the data type modelng paradgms are composed together accordng to precse rules (not shown). OCL constrants ensure that every port has exactly one type specfcaton and that dataflow connectons are only allowed between ports havng compatble data types. 3.3 Parameters In order to support parametrc hardware modules, such as an FFT block wth confgurable data ponts, MILAN allows for the specfcaton of such parameters. Components contan ParameterPorts capturng ther parameter nterface. A Parameter can be connected to a ParameterPort supplyng a value to t. Each port has a default value that s used f no Parameter s attached to t. Both the ParameterPort and the Parameter are data typed, usng the same modelng technque as for ports. Typng nformaton s used to verfy that the suppled parameter s compatble wth the parameter nterface of the component. Parametrc modelng plays an mportant role n representng desgn spaces. A parametrc component encapsulates multple mplementatons that can be selected by supplyng an approprate value for the parameter. For example, an N-pont FFT model encapsulates a number of FFT mplementatons spannng the vald range of N. Thus, a number of optons can be represented n the models nstead of an mplementaton. Furthermore parameterzaton helps to desgn and develop generc components that can be reused. 3.4 Multple Aspects The MILAN applcaton modelng paradgm s qute complex. However, the hardware descrpton, data type specfcaton and parameter modelng are largely orthogonal concepts. Therefore, they can be separated nto dfferent aspects to allow the user to better manage and understand the system. In the Hardware aspect, only module, ports, buses, data stores and the true mplementaton scrpts are shown. In Type aspect, Ports,

5 Parameters, ParameterPorts and data type references are dsplayed. Fnally, Components, Parameters, ParameterPorts and ther correspondng connectons are vsble n the Parameter aspect. Multple-aspect modelng s a natural way to mplement separaton of concerns. 3.5 Software applcaton modelng The software applcaton modelng paradgm s based on a dataflow representaton. A dataflow graph conssts of a set of compute nodes and drected lnks connectng them representng the flow of data. A flat graph representaton does not scale well for human consumpton, so we extended the basc methodology wth herarchy. There s extensve lterature on varous dataflow representatons. At the two ends of the spectrum are synchronous [7] and asynchronous dataflow. Both these models of computaton are supported by MILAN and have been dscussed n greater detals n [6]. 3.6 Alternatves Tll now we have dscussed the modelng envronment and a lot of ts feature, however we haven t dscussed how alternatve desgns are represented n the models. Parameterzed components are one way of representng desgn alternatves. Beng able to use multple languages of mplementaton provdes for alternatve mplementaton. MILAN also allows the user to have an explct choce between synchronous, asynchronous data flow and hardware mplementaton. Ths s acheved by usng alternatves. Alternatves are models that can contan synchronous, asynchronous software dataflow and hardware modules and the contanment mples an or condton. That s one and only one of the gven mplementatons wll be used. Furthermore choce between dfferent algorthms to solve the same problem can also be captured usng explct alternatves. 3.7 Composton of hardware and software MILAN supports the composton of hardware and software models. Fgure 3. Composton of hardware and software The metamodel n Fgure 3 specfes that a dataflow component can contan hardware modules and sgnal connectons. Furthermore, hardware and dataflow can be assocated usng the connecton DFHWConn. Ths represents a data path between software and hardware components. Thus, a hardware mplementaton of a sub- SystemCan resde n any dataflow component. 4. SUPPORT FOR SIMULATION After creatng a desgn envronment that allows us to model applcatons and s able to capture hardware and software desgns, parameterzed components and desgn alternatves, there s a need to drve varous smulatons from these models. A typcal development cycle starts from a coarse gran mplementaton, whch s tested for functonal correctness. Wth respect to hardware applcatons, SystemC s a good language to provde a coarse gran mplementaton. Smulaton of the SystemC mplementaton can be used to verfy functonal correctness. The user wll normally refne one block at a tme and so he/she may need to smulate the refned module wth coarse gran mplementatons of the other. MILAN s support of smulaton at dfferent levels of herarchy s called mult-granular smulaton. After refnng the desgn to varous alternatve mplementatons, the feasblty of the mplementatons s explored by proflng the modules. Proflng of modules requres smulaton of each component n solaton to come up wth performance numbers such as throughput, latency, power consumpton and memory requrements. Ths knd of smulaton n MILAN s referred to as solated smulaton. After proflng the modules a few feasble desgns are chosen for system wde smulaton to valdate the system requrements. Ths s referred to as full system smulaton. In heterogeneous systems, that s systems havng hardware and software components nteractng wth each other, verfcaton of desgn becomes a more challengng task. Smulaton of the hardware havng communcaton wth software components can be acheved by provdng a communcaton brdge between the hardware and software components. Ths helps to smulate hardware wth the software mplementaton provdng more accurate results. To drve the varous smulatons mentoned above and to automate ths process the models captured n the desgn envronment need to be nterpreted to generate code for smulaton. 4.1 Model Interpretaton The nterpreter of the hardware-modelng paradgm n MILAN generates code for smulaton. Currently SystemC code generaton s supported, that s f the behavor of the system s descrbed n SystemC, the nterpreter can

6 generate the code for solated, mult-granular and full smulaton. The generated code can be compled and run to get smulaton results. Furthermore smulaton of hardware n a heterogeneous system s also supported. The nterpreter traverses through the graph and gathers the requred nformaton, lke ports, sgnals, data elements, event drven functons and ther dependences. These are then used to generate SystemC glue code. 4.2 Mult-granular Smulaton In the herarchcal graph representng the system, typcally the lowest level modules contan the behavoral nformaton. Usng mult-granular smulaton the user can choose to provde behavoral nformaton for any module at any level of herarchy. Thus the user can smulate a system wth a mxture of coarse gran and fne gran mplementatons. The hgh level behavoral nformaton s captured n the Coarse Gran Aspect of the module. The nterpreter generates the code for the system and whenever t fnds a module marked for usng the coarse gran mplementaton t uses that and doesn t traverse deeper n that module. 4.3 Isolated Smulaton In order to smulate a module n solaton the module needs to be drven by sourcng functons and the output of the module needs to be sent to snkng functons. In MILAN we allow the user to capture the exact sourcng and snkng functon assocated wth each communcaton port. Hence to synthesze for an solated smulaton of a module, the true mplementaton of the module n queston s used along wth the sourcng and snkng functons from adjacent modules. The nterpreter generates code of the module n queston and creates sourcng and snkng modules for t. The sourcng and snkng modules contan smulaton scrpts specfed by the user n the Substtute aspect of the adjacent modules. Isolated smulaton can be performed not only on a sngle module but on a subgraph also, that s a connected subgraph can be chosen for smulaton and the modules adjacent to ths graph wll be used to supply and consume data. 4.4 Full Smulaton For a complete smulaton of the entre system a sngle desgn needs to be chosen. The user can choose between alternatve mplementatons by markng one of varous alternatve mplementatons to use. Alternatvely, the desgn-space exploraton tool can dentfy the pont desgns that satsfy the all constrants [10] and mark the selected alternatves automatcally. The nterpreter then traverses through the models and pcks up the chosen alternatve mplementatons to form a sngle desgn. The true mplementatons of the desgn are then used to generate SystemC code for a full smulaton. 4.5 Smulaton n Heterogeneous Systems To smulate hardware n a heterogeneous system, t s necessary to facltate communcaton between hardware and software components. In a real-world system, hardware software nteractons are facltated usng devce drvers. However, we do not requre devce drvers to smulate the system. The communcaton s acheved by usng enttes called proxes. At a hardware software nterface proxes are generated on both sdes of the nterface. For example, a hardware proxy wll read data from the hardware module at the nterface and ppe t to ts software counterpart usng TCP. Smlarly t wll read data from the ppe and provde t to the hardware module. The software proxy does the same at the other end. The nterpreter breaks the heterogeneous graph nto hardware and software graphs. It then generates the proxes and connects the respectve graphs at the nterface. Fnally, the two graphs are sent through ther respectve nterpreters. The hardware and software code can fnally be compled ndependently and then run together to smulate the hardware. 5. EXAMPLE APPLICATION Image processng systems and specfcally, mssle Automatc Target Recognton (ATR) systems face many challenges due to extremely large computatonal requrements and physcal, power, and envronmental constrants [11]. Thus, t s a good example to demonstrate some of the capabltes of MILAN. Input Image Stream Class Flter Banks Preprocessng 2D FFT Multply 2D IFFT do_peaks Class Dstance Calculaton Class Determnaton Fgure 4. ATR applcaton block dagram Dsplay Result The desgn and smulaton of a system n the MILAN framework starts wth applcaton modelng. Gven the sze of the ATR applcaton and the large number of desgn choces, both herarchy and alternatves are used extensvely. Fgure 5 shows a model of the do-peaks block of the ATR n the MILAN framework. Ths model captures one of the core computatons n the ATR applcaton. When desgnng the applcaton t was determned that the functonalty of the peak to surface rato (PSR) can be realzed n hardware or software. Instead of makng the selecton upfront, the alternatve realzatons are captured n the models and the selecton postponed tll a later phase of desgn. Notce that n Fgure 5 PSR s modeled as an

7 AsyncAlternatve (colored dfferently) Fgure 6 shows the alternatve realzatons of PSR. Fgure 5. do_peaks model of the ATR applcaton The software mplementaton of PSR s an asynchronous dataflow node and uses regular C code. The hardware mplementaton, on the other hand, s a hgh-level node representng a dataflow subgraph (Fgure 7b). In the early phases of the desgn t s not necessarly clear whch one s a better mplementaton. The sutablty of one or the other depends upon the actual resources that are avalable, the runtme executon envronment that s employed, and other factors. The varous smulaton tools asssts the desgner n makng these selecton decsons based on the requrements of the system. mplementaton. Then the user wll smulate the system wth the coarse gran mplementaton. The next step wll requre the user to profle the hardware alternatve n order to allow hm to choose between the hardware and software at a later stage. Ths wll requre an solated smulaton of the detaled hardware mplementaton of the PSR. The desgner wll select the hardware verson n the alternatve model and run solated smulaton on t. The nterpreter wll then use the herarchcal mplementaton of the PSR and use sourcng and snkng functons from Calculate_Mean_Std and Calculate_Dstance to generate SystemC code for solated smulaton. After decdng on the mplementaton to use the desgner wll want to run a full smulaton of the system wth the rght desgn choce. In ths example, let s say that the hardware mplementaton s chosen. Then the user selects that alternatve and runs the full system smulaton. In ths case the nterpreter uses the herarchcal mplementaton of the PRS mplemented n hardware as well as the complete mplementaton of the rest of the system. The full smulaton allows the user to verfy the desgn wth respect to system requrements. (a) Coarse gran aspect Fgure 6. Alternatves n ATR applcaton Fgure 7 shows two aspects of the hardware model of the PSR. In addton to the nput and output ports, the Hardware aspect contans a data flow sub-graph of the model showng the refned realzaton of the module. The coarse gran aspect shows the hgh level mplementaton of PSR. It contans a SystemC-scrpt, and a VHDL-scrpt. The SystemC-scrpt s a placeholder for the hgh level SystemC code mplementng the PSR, whle the VHDLscrpt s a placeholder for VHDL code. An approprate scrpt s selected based on the target smulator. A typcal desgn cycle wll begn wth the desgner wantng to verfy the functonal correctness of the alternatve hardware applcaton wth a coarse gran mplementaton. So the desgner wll choose the hardware verson of the PSR and mark t to specfy the use of a course gran (b) Hardware aspect Fgure 7. Two aspects of the hardware model of PSR

8 Subsequent to applcaton modelng, the next step n the ATR desgn s resource modelng. In ths step the target resources are modeled as per the resource-modelng paradgm. 6. CONCLUSION Needs of embedded applcatons have expanded wth the advent of FPGA s and ASIC s. The ncreasng complexty and heterogenety of such systems drves the need to have an ntegrated framework to support desgn and development to speed up the desgn cycle and to explore varous alternatve solutons. MILAN s a framework that provdes an ntegrated envronment to desgn embedded system applcatons usng doman specfc concepts. It allows for the desgn of alternatve solutons and abstracts the mplementaton from desgn. Separaton of concerns and modular desgn are the pllars of MILAN. Modelng of hardware usng doman specfc concepts n a heterogeneous system allows for better representaton of the desgn and helps developers to desgn systems n an ntutve manner. Support for varous smulaton needs by a composte envronment helps to speed up the desgn cycle and allows for better exploraton of alternatve solutons. The framework, specfcally the hardware paradgm has been appled to varous small and medum szed projects wth a great deal of success n terms of ncreasng effcency and reducng the desgn tme. 7. ACKNOWLEDGMENTS The research descrbed n ths paper s sponsored by the DARPA IPTO Power Aware Computng and Communcatons program. The MILAN project s a jont effort of Prof. Vktor Prasanna s group at the Unversty of Southern Calforna and the Insttute for Software Integrated Systems at Vanderblt Unversty. 8. REFERENCES [1] Agrawal, A. et al. MILAN: A Model Based Integrated Smulaton Framework for Desgn of Embedded Systems, Workshop on Languages, Complers, and Tools for Embedded Systems (LCTES 2001), Snowbrd, Utah, June [2] MILAN. [3] ARMulator. _debug [4] Burger, D. and Austn, M., The SmpleScalar Tool Set, Verson 2.0, Computer Archtecture News, 25 (3), pp , June, [5] J.T. Buck, S. Ha, E.A. Lee and D.G. Messerschmtt, Ptolemy: A Framework for Smulaton and Prototypng Heterogeneous Systems: Int. Journal of Computer Smulaton, specal ssue on "Smulaton Software Development", vol.4, pp , Aprl, 1994 [6] Ledecz, A., et al. Composng Doman-Specfc Desgn Envronments, Computer, pp , November, [7] Lee, E. A. And Messerschmdt, D. G., Statc schedulng of synchronous data flow programs for dgtal sgnal processng. Transactons on Computers, C36 (1): , January [8] MATLAB. [9] Marco Sgro, Lucano Lavagno, Alberto Sangovann- Vncentell. Formal Models for Embedded System Desgn. IEEE Desgn & Test of Computers, 17(2):14-27, June [10] Neema, S., System Level Synthess of Adaptve Computng Systems, Ph. D. Dssertaton, Vanderblt Unversty, Department of Electrcal and Computer Engneerng, May [11] Nchols, K. And Neema, S., Dynamcally Reconfgurable Embedded Image Processng System, Proceedngs of the Internatonal Conference on Sgnal Processng Applcatons and Technology, Orlando, FL, November, [12] SystemC. [13] Mohanty, S. And Prasanna, Vktor K., Rapd System- Level Performance Evaluaton and Optmzaton for Applcaton Mappng onto SoC Archtectures, 15th IEEE Internatonal ASIC/SOC Conference, Rochester, New York.