A HIERARCHICAL SIMULATION FRAMEWORK FOR APPLICATION DEVELOPMENT ON SYSTEM-ON-CHIP ARCHITECTURES. Vaibhav Mathur and Viktor K.

Transcription

1 A HIERARCHICAL SIMULATION FRAMEWORK FOR APPLICATION DEVELOPMENT ON SYSTEM-ON-CHIP ARCHITECTURES Vabhav Mathur and Vktor K. Prasanna Department of EE-Systems Unversty of Southern Calforna Los Angeles, CA fvabhav, ABSTRACT We propose a herarchcal smulaton methodology to assst applcaton development on System-on-Chp archtectures. Herarchcal smulaton nvolves smulaton of a SoC based system at dfferent levels of abstracton. Thus, t enables a system desgner to explot smulaton speed vs. accuracy of results trade-offs. Vertcal smulaton s a specal case of herarchcal smulaton, where a feedback mechansm between the dfferent smulaton levels helps n nterpretng the results of stand-alone smulatons n the system-wde context. The paper presents an approach to perform vertcal smulaton of a class of applcatons under a smplfed scenaro. I. INTRODUCTION Performance requrements under ubqutous computng, and convergence of communcaton and computng technologes have resulted n the emergence of System-on- Chp (SoC) archtectures. Applcaton development on such archtectures nvolves a delcate balance between hgh performance requrements and constrants on area, power, etc. State-of-the-art desgn tools and methodologes are not adequate to manage the desgn complexty of SoCs. Current desgn processes are based on ndependent desgn flow for each archtecture component and have not co-evolved wth changng system desgns and requrements. Programmng models and desgn tools for each component are ndependently utlzed to map an applcaton, and system ntegraton s performed later. Systemwde performance analyss s typcally a manual process. It nvolves the use of component specfc smulators n solaton, and s tedous snce each smulator has a dfferent nput/output nterface. Ths approach results n suboptmal desgn because mult-objectve optmzaton requres exhaustve traversal of a large desgn space. Several envronments [9], [15] have emerged that concentrate more on co-smulaton and system synthess than on hgh level system desgn. Desgn problems (e.g. mproper applcaton-to-archtecture mappng, nsuffcent resources to meet the performance requrements, etc.) detected durng such co-smulaton leads to tedous and tme consumng redesgn of the system [6]. Ths work s supported by the US DARPA Power Aware Computng and Communcaton Program under contract F33615-C montored by Wrght Patterson Ar Force Base. Analog I/O Programmable Processor Customzed Logc Memory Subsystem Hgh Speed Interconnect DMA Subsystem Confgurable Logc Fg. 1. A typcal SoC archtecture The above scenaro necesstates a system level desgn approach. A unfed smulaton envronment s needed that provdes performance estmates (latency, throughput, average power, etc.), for a gven applcaton-to-archtecture mappng, at desred detal and cost (tme) of smulaton. Ths wll enable rapd evaluaton of performance tradeoffs for alternate mappngs at a hgh level and early n the desgn cycle wthout performng tme-ntensve low-level smulatons. Ths paper outlnes a herarchcal smulaton methodology for ths purpose. The work descrbed n ths paper s part of the MILAN 1 project, whch s a collaboratve research effort between the Unversty of Southern Calforna (USC) and the Insttute for Software Integrated Systems (ISIS) at Vanderblt Unversty. MILAN s a Model based Integrated smulaton framework for embedded system desgn and optmzaton [2]. The desgner formally models the target applcaton, underlyng hardware, and constrants (latency, throughput, power, etc.) through a graphcal nterface provded by MILAN. The nformaton s stored n a model database that can be accessed through a smple Component Object Model (COM) [13] nterface. The model nformaton s translated nto sutable nput formats requred by the ntegrated smulators. Thus, MILAN has the capablty to drve multple smulators wth dfferent nput/output formats from a sngle system specfcaton. Herarchcal smulaton means smulatng a desgn at dfferent levels of abstracton n terms of both the structure and the behavor of the underlyng component(s). Vertcal smulaton s a specal case of herarchcal smula- 1 mlan (hnd): meetng, unfcaton.

2 System Development Process: Defne Modelng Paradgm Tools and Components: Creates Develop Model Bulder(s) Model Bulder Use End-User s Process: Edt Models Develop Model Interpreter Creates Model Interpreter Models Use Buld System (Automatcally) Executable System Develop R-T Support Creates Run-tme Support Execute System Fg. 2. Model Integrated Computng ton, where a desgner s nterested not only n smulatng a system sub-component (a task-resource mappng) at multple levels of granularty, but also n meanngful nterpretaton of low-level smulaton results from a systemwde perspectve. For example, the throughput of one system sub-component mght affect the rate of avalablty of data to a data dependent system sub-component. Also, the computaton of a partcular task mght depend on nput data values, that can sometmes only be determned by smulatng real-world system operaton va realstc data sets. Vertcal smulaton s useful when (a) hgh level end-to-end performance estmates are to be further refned through low-level smulaton, and (b) a partcular system sub-component s to be smulated at a fne granularty, takng nto account system-wde effects such as those mentoned above. A hgh level estmaton methodology and a feedback mechansm, explaned n detal n Sectons II and III, helps n achevng both these objectves. Vertcal smulaton wll typcally be useful n the later phase of the desgn cycle, when hgh-level, system-wde performance estmates for a partcular mappng are to be refned through low-level smulatons. Hgh-level smulatons are coarse-graned approxmatons whch yeld very rapd results wth possble compromse n accuracy. Lowlevel smulatons typcally are hghly accurate but are tme consumng. Herarchcal smulaton wth nterpretaton of smulaton results allows the user to explot the trade-offs between smulaton speed and accuracy of results. MILAN focuses prmarly on ntegraton of smulators for Instructon Set Archtecture (ISA) based processors (e.g. RISC, DSP), applcaton-specfc cores, confgurable logc (e.g. FPGA), memores, and nterconnects. Numerous commercal platforms targeted towards communcaton and networkng applcatons, have been ntroduced lately. A typcal platform s shown n Fgure 1. The Unversal Mcrosystem (UMS) [8], the Reconfgurable Communcatons Processor [7], the Jazz PSA [11], and the Platform FPGA [16], are a few examples. These platforms nclude programmable processor(s), confgurable logc, customzed logc, embedded memores, hgh speed nterconnect, and analog I/O components on the same chp. MI- LAN ntegrates smulators for dgtal components only; smulators for analog components are not consdered. The paper s organzed as follows. Secton II descrbes the MILAN project and the underlyng Model Integrated Computng (MIC) [18] desgn approach. Secton III defnes herarchcal and vertcal smulaton concepts. Secton IV dscusses a prototype mplementaton of vertcal smulaton for a class of applcatons. Secton V has concludng remarks. II. THE MILAN PROJECT The focus of the MILAN project [2] s on developng formal modelng paradgms that wll enable smulator ntegraton and effcent applcaton-to-archtecture mappng through automatc desgn space exploraton. MI- LAN adopts Model Integrated Computng (MIC) [18] as the core desgn technology (Fgure 2). MIC s especally valuable for the desgn of computer-based systems wth strong nterdependence between the hardware and the software components. By formally modelng all aspects (applcaton, resource, behavor, constrants, etc.) of a system and usng well-defned rules to generate new systems or manage exstng ones, t s possble to avod the errors that arse when requrements change and the system has to be redesgned or re-mplemented. Whle the ntal modelng effort mght be costly compared to ad hoc approaches, the benefts are apparent for a system that evolves over tme. An envronment that supports the MIC allows the desgner to create doman-specfc models at the requred level of abstracton, valdate these models, and perform varous computatonal transformatons on them (Fgure 2).

3 Functonal Smulator Power Smulator Applcaton Models Generc Modelng Envronment (GME) Constrants Desgn-space Exploraton and Prunng DESIGN System Smulaton SYSTEM Resource Models Fg. 3. MILAN Archtecture Hgh-Level Estmator Performance Smulator Model Interpreters A metamodel s a formal descrpton of the modelng envronment s model constructon semantcs,.e. the modelng paradgm. Syntactcally and semantcally correct models are created usng modelng paradgms. The metamodel defnes the syntactcal buldng blocks avalable to the desgner for descrbng (nstantatng) the system. It also defnes the doman-specfc composblty rules and the constrants that enforce some of the semantcs n the system specfcaton. Model nterpreters are the software components that translate the models for use n the MILAN executon envronment. A model database s a key component that stores the models and the translated nformaton n a canoncal form that provdes a common representaton for the nformaton that are used n drvng varous smulators. The model database also stores the smulaton results. The Generc Modelng Envronment (GME) [10] s a confgurable graphcal tool sute supportng MIC. The confguraton of the envronment to support domanspecfc modelng s performed n a formal manner through the use of metamodels. The metamodelng language s the UML class dagram notaton [5]. Well-formedness rules that are also part of the metamodels are specfed usng the Object Constrant Language (OCL). These constrants, along wth the syntactcal rules of the doman language, are enforced by the automatcally generated target envronment. MILAN explots the MIC technology to confgure an envronment talored for embedded system desgn, evaluaton, and optmzaton. The framework ncorporates power as an mportant desgn metrc. Power estmaton and optmzaton s supported through ntegraton of exstng component specfc power smulators, based on system-wde power models. Fgure 3 shows the archtecture of MILAN and also depcts the system desgn flow from the users perspec- tve. The graphcal nterface s provded by GME confgured to support the modelng paradgms developed for MI- LAN. Semantc nformaton n the modelng paradgms s captured through metamodels. The metamodels confgure the GME for creatng doman-specfc models. Followng models for the desgn of embedded systems based on SoC archtectures are currently supported n MILAN. Resource models [3] descrbe avalable hardware components and ther nterconnectvty n a herarchcal block dagram-lke notaton. Applcaton models are based on a herarchcal sgnal flow representaton wth mportant extensons. Most notably, the modelng language allows for the specfcaton of explct desgn or mplementaton alternatves of any component. Ths enables modelng of the entre desgn space of the applcaton as opposed to a pont soluton. To manage ths desgn space, applcaton requrements, resource constrants, and other specfcatons are captured explctly through OCL, n the metamodels. Performance modelng of SoC archtectures nvolves characterzng desred performance metrcs of a gven mappng n terms of archtecture parameters. The performance model leverages from pror USC work n hgh level performance models for tradtonal and reconfgurable archtectures [1][14]. The communcaton model provdes a common formalsm to enable nter-operablty of smulators that represent the same nformaton n dfferent formats. The desgn-space exploraton and prunng tool takes the potentally very large desgn space and apples the constrants usng a symbolc constrant satsfacton technque to fnd the set of solutons that satsfy all the constrants. The goal of desgn space exploraton s to dentfy a small number of vald canddate desgns. MILAN supports an estmaton methodology that ntegrates varous component-specfc performance models (power, tme) and enables system-wde performance evaluaton. The methodology s based on a hgh level systemwde performance model to evaluate complex applcaton to archtecture mappng choces and dfferent schedules of executon. Although, deally a low-level (detaled) system wde performance model can be defned, t s mpractcal snce dverse archtecture features (reconfgurable vs. customzed logc, varable vs. statc parameters etc.) cannot be captured unformly. Moreover, smulatons based on t wll be cost (tme) ntensve. The desgn of a Hgh Level Performance Estmator (HPerE) based on a hgh level performance model s motvated by these ssues. MILAN supports dfferent classes of smulators, besdes the HPerE. Functonal smulators (e.g., MATLAB or SystemC), verfy the functonalty of the applcaton. Several low-level smulators (power, performance) wll be supported n future. The HPerE along wth the low-level smulators ntegrated n MILAN facltates mult-level smulaton, whch explots the trade-off between the accuracy of results and the smulaton speed.

4 III. HIERARCHICAL AND VERTICAL SIMULATION MILAN has the followng capabltes to assst applcaton development under a unfed smulaton envronment. ffl Smulator Integraton: Integratng multple component specfc smulators and drvng these smulators wth dfferent nput/output formats usng a sngle system specfcaton s defned as Smulator Integraton. The system s specfed n terms of applcaton and resource models, and end-to-end performance requrements. The models are stored n the model database that enables seamless smulator ntegraton by provdng a common nformaton repostory. The model nterpreters translate ths nformaton nto the syntax and the semantcs of the nputs requred to drve the smulators. ffl Herarchcal smulator ntegraton: Herarchcal refers to multple levels of abstracton of the models descrbng the system. Herarchcal smulaton mples smulatng the system or a system sub-component at dfferent levels of abstracton and mplementaton. Thus, provdng herarchcal smulaton capablty for a partcular task-to-resource mappng means provdng the user wth a choce of smulators for that resource, at dfferent levels of granularty (assumng they are ntegrated nto the framework). Smulator ntegraton of component-specfc or system-wde hgh level and low level smulators s termed as herarchcal smulator ntegraton. Hgh-level smulators are typcally based on a few key parameters of the system (or system sub-component) and are desgned to provde rapd performance estmates, possbly at the expense of accuracy. Low-level smulators (such as cycle-accurate smulators) are hghly accurate but can requre an order of magntude more smulaton tme and a much larger set of nput parameters to be specfed, compared to hgh-level smulators. The herarchcal, block-dagram lke specfcaton of the resources themselves also provdes dfferent levels of abstracton correspondng to the dfferent granulartes of resource representaton requred by hgh-level and low-level smulators. ffl Vertcal smulaton: Herarchcal smulator ntegraton enables the smulaton of a system sub-component (a task mapped onto a compute resource) at dfferent levels of granularty, usng any of the ntegrated smulators for that component, thereby allowng the desgner to explot the smulaton tme vs. accuracy of results trade-off. There are two scenaros when stand-alone, mult-granular smulaton s not useful: (a) when the desgner s nterested n refnng hgh-level estmates of a partcular mappng, provded by HPerE, and (b) when the desgner wants detaled and realstc statstcs about a partcular system sub-component. A meanngful nterpretaton of the results of herarchcal (mult-granular) smulaton, n the system-wde context s defned as vertcal smulaton. Vertcal smulaton uses the herarchcal smulator ntegraton capablty and provdes Functonal Smulaton User System Specfcaton DATABASE Model Informaton Stmulus Vertcal Smulaton Low level Smulators HPerE Model Interpreters Fg. 4. Herarchcal Smulaton Framework drvng smulators feedback a mechansm to refne a system sub-component or the endto-end performance estmates of a canddate mappng. The HPerE system-wde performance estmaton methodology does not rely on cycle-accurate smulaton of a gven applcaton on the target resource at the tme HPerE s nvoked. The HPerE requres pre-characterzed costs from expermental results, vendor-suppled nformaton for lbrary components, or any other offlne method. In the later stages of the desgn cycle, smulaton tme wll be of less concern because the desgn space would have reduced to a smaller, manageable set of mappngs that satsfy broad system requrements. In the frst desgn scenaro as mentoned above, the desgner wll be nterested n refnng the HPerE estmates for a gven mappng, by runnng low-level smulatons for selected components. The model database not only stores the models but also the data values processed by the system sub-component, and the results of smulaton. One of the crucal nformaton requred for nvokng any smulator s the ncomng data set(s), whch form a stmulus to the system sub-component (a task-tocompute resource mappng). The stmulus s obtaned ether through functonal smulaton of the applcaton or by usng data generator scrpts for the predecessor tasks n the path of applcaton executon. These methods are explaned n detal n Secton IV. Snce the smulaton results are also stored n the database, smulatng a component at

5 low-level mples updatng the performance cost assocated wth t. By nvokng the approprate low-level smulator, updatng the performance costs, and then nvokng HPerE, refned estmates can be obtaned (for the frst scenaro). Ths bottom-up feedback needs model nterpreters that can sutably nterpret the low-level smulaton results and update the model database. The second scenaro s much more challengng because t requres a top-down feedback from the HPerE to enable realstc low-level smulaton, as aganst the bottomup feedback from the low-level smulaton results for refnng HPerE estmates. A realstc smulaton s one that provdes performance statstcs closest to those exhbted by the fnal system when t s deployed n the real world. Two of the mportant consderatons n arrvng at such realstc low-level smulaton results are the avalablty of realstc data values that wll be processed by that task, and modelng of system-wde effects such as nput/output delays due to samplng rates of sensors, constrants on buffer sze, etc. Although the HPerE and low-level smulaton results are both stored n the model database, a common respostory by tself s not suffcent to help the user get a realstc set of performance statstcs for a partcular task, wth system-wde effects taken nto consderaton. Vertcal smulaton technques are requred to meanngfully nterpret low-level smulaton results wth top-down feedback from the HPerE. The next secton addresses ths ssue n more detal. There s another aspect to ntegratng smulators that s outsde the scope of the MILAN project. When more than one component-specfc low-level smulators are nvoked smultaneously and system-wde performance s evaluated through real-tme nteracton among the dfferent smulators, the capablty s termed horzontal smulaton. Although horzontal smulaton, f mplemented correctly, can accurately smulate the actual nteracton among subcomponents, concurrent executon of component-specfc smulators poses multtude of challenges. For example, most wdely-used smulators are not desgned to nteract at run-tme, wth other systems. Modfyng such smulators can prove to be tme-consumng and not always feasble. Specfyng a common API for smulators to conform to, s an equally challengng task. Fnally, there are smulaton speed (tme) ssues that can arse when smulators have to synchronze, say, at every cycle. IV. VERTICAL SIMULATION: ASIMPLE IMPLEMENTATION Usng the MILAN modelng paradgms, the system desgner specfes the target applcaton, underlyng resources, the task-to-resource mappng, a schedule of executon of the tasks, and performance constrants. The nformaton s stored n the model database, and model nterpreters extract ths nformaton and translate t nto sutable formats for drvng the ntegrated smulators. Herarchcal smulaton s facltated through ths mechansm, as explaned n the prevous secton. Ths secton outlnes vertcal smulaton mplementaton for a smplfed scenaro. Followng assumptons are made. ffl Applcaton s modeled as a Drected Acyclc Graph (DAG). Each vertex n the DAG represents a task and edges between the vertces represent the data transfer between the tasks. Every task n the DAG s atomc. Ths means that a task cannot be further decomposed nto subtasks. If the task s dependent on data from multple tasks, we assume that the task s actvated (smulated) when the data from all ts predecessor tasks (the stmulus) n the DAG s avalable. ffl Currently, the data processng rate by all the tasks s assumed to be same and constant durng the entre executon of the applcaton. There s no change n the rate of processng dependent on a control data. ffl Resources consst of compute resources (RISC core, FPGA, etc.), storage elements (memores), and communcaton channels (buses). Explct communcaton through the channels occurs between the compute resources. ffl The task-to-resource mappng and the schedule of executon of the tasks on the compute resources together defne an executon model for the applcaton. Only one task s executed on a compute resource at any tme. There s no resource sharng wth others tasks durng the executon.e., the tasks do not compete for resources such as compute cycles, memory etc. The precedng (and succeedng) tasks n the schedule can however be executed on the same resource. Snce there s no concurrent executon of the tasks on the same resource, the results of stand-alone smulaton (that typcally does not model concurrency and resource sharng) accurately represent the computaton cost of the task beng smulated. A lnear task graph wth only one task mapped onto a compute resource at a tme, trvally satsfes the assumptons under the applcaton and the executon model. The sequental data dependence between the tasks satsfes the requrement that the stmulus (consstng of just one data value) s avalable before the task s ntated. For vertcal smulaton, the user selects a partcular task and an assocated low-level smulator for the resource onto whch that task s mapped. Invocaton of a smulator requres the followng nputs: (a) The stmulus (the ncomng data set to the task) (b) the smulator confguraton parameters, and (c) an approprate mplementaton of the task (e.g. C code for a RISC smulator or a VHDL code for an FPGA smulator). These three nputs are provded by the model nterpreter. The stmulus S to a task denoted by vertex V s modeled by two vectors: S =[fd 1 ;d 2 ; :::; d g; k ft 1 ;t 2 ; g], :::t k where d represents nput data value, t represents the arrval tme of the value, and k s the n-degree of V. The

6 V V V V Database Stmulus, task code, confguraton parameters (a) Step I: Input DAG G d 2 d 1 d1 d2 (b) Step II: Back traversal to the nput vertex wth reversed edges Low level smulator S vs = {d 1, d 2 } (c) Step III: Functonal Smulaton computaton statstcs (d) Step V: Low level smulatons Fg. 5. Steps for vertcal smulaton rate of arrval and the data values are crucal for realstc smulaton of the task. Our smple vertcal smulaton technque focuses on task latency and not throughput,.e. the arrval rate of data at a node s not currently modeled. For determnng the stmulus, the followng method s used (see Fgure 5). The task to be vertcally smulated, and the nput vertex V for the entre applcaton are marked n the applcaton DAG G. To determne all data flows that lead from V to, the drecton of the edges s reversed and the graph s traversed startng from. All the vertces on all the paths leadng from to the nput vertex V are determned. Functonal smulaton s then performed for all these vertces (tasks) accordng to the dependences specfed by the orgnal graph G, and the data stmulus for s obtaned. Another method for obtanng the stmulus s requrng the user to assocate a scrpt wth every task. Ths scrpt generates dummy output that represents the actual output, had the task been executed wth real nput data. If such scrpts are provded, obtanng the data stmulus for a specfc task wll nvolve executng the dummy data generators only for ts mmedately precedng tasks. Functonal smulaton s stll preferable, because the computaton cost of a task s most accurately obtaned through smulaton that uses data values generated durng the actual applcaton executon. For example, consder an mage processng applcaton. Computaton of the correlaton coeffcents for an mage vector depends on the ntensty of the pxels, whch n turn depends on the relatve dstance on the RGB color scale. Generatng dummy vectors that represent actual mages seen by the system n the real world can be dffcult or even mpossble. Whle the stmulus obtaned through functonal smulaton and generator scrpts s stored n the model database, some typcal data values generated durng pror applcaton development, and tested for the worst or the best case performance satsfacton can as well be stored. These can be reused for the current applcaton development process as stmulus for low-level smulatons. Once the stmulus s obtaned, the approprate low-level smulator s nvoked. The results from low-level smulaton need to be sutably nterpreted and used to update the computaton costs assocated wth the task n the model database. Ths s a bottom-up feedback mechansm, where results from low-level smulaton are used to obtan more accurate system-wde performance estmates through HPerE. Stand-alone smulaton of a task, however, does not model the system-wde effects on task executon, such as nput/output delays due to samplng rates of sensors, constrants on buffer sze, etc. The smulaton also does not capture the state of the processng element between task executons. For example, the cache contents after a task completes executon affect the ntal memory access costs (compulsory msses) for the next task that executes on the same resource. These access costs wll be avalable through HPerE and wll also be stored as a stmulus n the database. However, ths stmulus s requred wth the output of the low-level smulatons. HPerE provdes such top-down feedback necessary for system-wde nterpretaton of the low-level smulaton results. Theestmates of system-wde effects provded by HPerE, such as nput/output data delays, are used n conjuncton wth stand-alone smulaton results to arrve at more accurate performance statstcs for the system sub-component. The ssues n mplementng vertcal smulaton for a general scenaro are dscussed n Secton V. The vertcal smulaton outlned above s beng mplemented n MILAN. The MILAN applcaton modelng paradgm allows graphcal representaton of the target applcaton as a DAG, wth task mplementatons specfed for each node of the DAG (C source code, HDL mplementatons, etc.). The current verson of the resource modelng paradgm s capable of representng unprocessor archtectures as modeled by the SmpleScalar smulator [17], a prototype ntegraton of whch has been completed for MI-

7 LAN. Currently, for specfyng task-to-resource mappng, a task node n the applcaton graph s explctly assocated wth the underlyng resource label. MATLAB has been ntegrated nto MILAN for functonal smulaton. These capabltes of MILAN enable a user to functonally smulate the entre applcaton, and perform low-level smulaton for a selected task-resource par. Vertcal smulaton, as descrbed prevously, requres addtonal capabltes that are beng mplemented. These nclude graph traversal from the specfed node n the drecton of the edges, functonal smulaton of an applcaton sub-graph, desgn and mplementaton of model nterpreters for bottom-up feedback, etc. A prelmnary desgn of HPerE has been completed, and mplementaton s under progress. Vertcal smulaton for applcaton development provdes the capablty to perform mult-level smulaton for a partcular applcaton-to-resource mappng. The desgner can evaluate hardware vs. software speedup for a task and can change the mappng for that task only, or for the entre system f desred. An FFT algorthm mplemented as Decmaton n Tme and Frequency (DITF) s less computatonally ntensve (n terms of floatng pont operatons) as compared to DIT or DIF radx-2 mplementatons [4]. A desgner can evaluate the end-to-end performance enhancements usng such alternate algorthmc mplementatons. V. CONCLUDING REMARKS Ths paper dscussed the concept and need for herarchcal and vertcal smulaton, and a smple mplementaton n the context of MILAN. Some mportant ssues that are applcable n a more general scenaro reman to be addressed. A few of the mportant characterstcs of the general scenaro are: ffl Tasks are executed concurrently on the same resource. ffl The latency and throughput of a task change dependng on control data. Ths n turn, affects the rate of avalablty of data to the data dependent tasks n the applcaton executon. ffl Communcaton between compute resources s through dfferent mechansms, such as global memory. Ths mpacts the end-to-end latency, power consumpton, etc. We are currently enhancng HPerE to address the ssues n the general scenaro. The feedback mechansm (bottom-up and top-down) as dscussed n the paper wll be mplemented and enhanced. Ths wll nvolve wrtng approprate model nterpreters. In future, the refnement of the hgh level model parameters themselves wll be performed, based on low-level smulaton results. We envson that our framework wll address the system level desgn challenge facng the SoC communty by provdng an accurate mechansm to evaluate nteractons between SoC components at varous levels of granularty, by explotng the smulaton tme vs. accuracy of results trade-off. VI. ACKNOWLEDGMENTS We would lke to thank Amol Baksh (USC), Sumt Mohanty (USC), and Akos Ledecz (ISIS). Amol provded nvaluable feedback on smulator ntegraton, and herarchcal smulaton ntegraton aspects of MILAN (the subject of ths paper). Sumt provded nputs on HPerE, and Akos provded nputs on the MILAN archtecture. REFERENCES [1] Algorthms for Data Intensve Applcatons on Intellgent and Smart Memores (ADVISOR), Unv. of Southern Calforna. [2] A. Baksh, V. K. Prasanna, A. Ledecz, et al., MILAN: A Model Based Integrated Smulaton Framework for Desgn of Embedded Systems, ACM SIGPLAN 2001 Workshop on Languages, Complers, and Tools for Embedded Systems (LCTES 2001), Utah, June [3] A. Baksh and V. K. Prasanna, Abstract Resource Representatons for Custom Desgn of System-on-Chp Archtectures, submtted to IFIP VLSI-SOC 2001, Montpeller, France, December [4] M. Balducc, A. Ganapathraju et al., Benchmarkng of FFT Algorthms, IEEE Southeastcon 97, Engneerng New Century, Proceedngs, pp [5] G. Booch et al., The Unfed Modelng Language User Gude, Addson-Wesley Pub Co., [6] H. Chang et al., Survvng the SOC Revoluton A Gude to Platform-Based Desgn, Kluwer Academc Publsher, Massachusetts, USA, [7] Chameleon Systems Inc., [8] Cradle Technologes, [9] Synopsys Eagle, ds.html. [10] Generc Modelng Envronment, [11] Improv Systems Inc., [12] The MILAN Project, [13] Mcrosoft Component Object Model, [14] Models, Algorthms and Archtectures for Reconfgurable Computng Project, [15] CoWare N2C, [16] Xlnx Inc., [17] SmpleScalar Tool Set, mscalar/smplescalar.html. [18] J. Sztpanovts, G. Karsa, Model-Integrated Computng, IEEE Computer, Aprl, 1997.