Sesame: Simulation of Embedded System ... - Semantic Scholar

Sesame: Simulation of Embedded System Architectures for Multi-level Exploration Berry van Halderen

Simon Polstra

Andy Pimentel

Bob Hertzberger

Department of Computer Science, University of Amsterdam, Kruislaan 403, 1098 SJ Amsterdam berry,spolstra,andy,bob @science.uva.nl


Keywords: Architecture simulation, design space exploration, mixed-level simulation, embedded media systems

Abstract Modern signal processing and multimedia embedded systems increasingly have heterogeneous system architectures. In these systems, programmable processors provide flexibility to support multiple applications while dedicated hardware blocks provide high performance for time-critical application tasks. The heterogeneity of such embedded systems and the varying demands of their growing number of target applications greatly complicate the system design. For this reason, the system design should be supported by tools which facilitate efficient design space exploration of these embedded systems. In this paper, we present an overview of the Sesame simulation environment which addresses the design space exploration of heterogeneous embedded systems architectures. Sesame, which is still under development, aims at supporting the rapid evaluation of instantiations of embedded systems architectures at multiple levels of abstraction. To this end, we are currently investigating how the level of detail of the simulation models can be adjusted in a seamless manner and how mixed-level architecture simulations are best supported.

1 Introduction Modern embedded systems, like those for media and signal processing, increasingly need to be multifunctional and must support multiple standards. A high degree of programmability, which can be provided by applying microprocessor technology as well as reconfigurable hardware, is key to the development of such advanced embedded systems. However, performance requirements and constraints on cost and power consumption still require substantial parts of these systems to be implemented in dedicated hard-

ware blocks. As a result, modern embedded systems often have a heterogeneous system architecture, i.e. they consist of components in the range from fully programmable processor cores to fully dedicated hardware components for the time-critical application tasks. With the emergence of highly programmable heterogeneous embedded systems, the suitability of the existing techniques for their hardware/software co-design [1] needs to be reconsidered. Particularly, the traditional approach in which a single application specification is gradually synthesized into an architectural implementation with the appropriate hardware and software components is not suited for the design of these programmable systems. Such an approach is ideal for the design of dedicated systems targeting a single application, but it lacks the generalizability to cope with programmable architectures suited for the processing of a broad range of applications. Moreover, it hampers the extensibility of systems to support future applications. Another trend which affects the design of embedded systems is the need for reducing the design time to allow a short time-to-market. At the same time, the complexity of the designs is increasing, mainly because systems have to satisfy the performance requirements of a range of different applications. Reducing the design time of these increasingly complex embedded systems implies that the traditional approach of relying on detailed cycle-true simulation models as the most important vehicle for their design space exploration (DSE) has become infeasible. The effort required to build such detailed simulators is relatively high, making it impractical to use them in the very early design stages. Moreover, the low simulation speeds of these simulators significantly hamper the architectural exploration. For modern embedded systems, it is increasingly important to explore different design choices at an

early stage since the increased complexity of the architecture components and their interactions makes the performance behavior hard to predict. To facilitate the design space exploration of these complex systems, a DSE environment should provide support for simulation at a range of abstraction levels. This allows for controlling the speed, required modeling effort and attainable accuracy of the architecture simulations. In such an environment, abstract simulation models are used for exploring the large design space in the early design stages, while in a later stage more low-level architecture models can be applied for detailed performance studies. In the scope of the Artemis (ARchitectures and meThods for Embedded MedIa Systems) project [2] we are developing an architecture workbench which provides simulation methods and tools for the efficient design space exploration of heterogeneous embedded media systems. With the term efficient, we mean that the architecture workbench allows for rapidly evaluating different architecture designs, application-architecture mappings and hardware/software partitionings at various levels of abstraction and for a broad range of (media) applications. The simulation technology provided by the Artemis architecture workbench consists of two methodologies and their associated simulation environments: Spade (System level Performance Analysis and Design space Exploration) [3] and Sesame (Simulation of Embedded System Architectures for Multilevel Exploration). Both methodologies share a lot of ideas and techniques but have different focusing points [2]. In this paper, we will present an overview of the simulation methodology applied in Sesame and its main research challenges. Regarding the latter, hierarchical application and architecture modeling is regarded to be a key issue. Concepts need to be devised to refine simulation models across different abstraction levels in a smooth manner. These concepts should include the support for refining only sections of an architecture model, resulting in mixedlevel simulations. Such mixed-level simulations allow for more detailed evaluation of a specific architectural component within the context of the behavior of the whole system. They avoid the need for building a complete detailed architecture model and do not suffer from deteriorated system evaluation efficiency caused by unnecessarily refined parts of the architecture model. The next section explains why we believe that current simulation technology is too limited for performing efficient design space exploration in the context of heterogeneous embedded systems. In Section 3, we give a general overview of the simulation methodology we apply in Sesame and show that the recognition of separate application and architecture models is

key to obtaining a high degree of modeling and exploration freedom. Section 4 describes the current status of Sesame and presents the challenges associated with hierarchical application and architecture modeling as well as mixed-level simulations. Finally, Section 5 summarizes the work.

2

The limitations of traditional cosimulation

System architecture simulation of heterogeneous systems is a relatively new research field which has received a lot of attention in recent years. The key concept in most of the research and commercial efforts in this field is co-simulation. Like its name already suggests, co-simulation implies that the software parts (which will be mapped onto a programmable processor) and the hardware components of an embedded application and their interactions are simulated together in one simulation [4]. Current co-simulation frameworks (e.g., [5, 6, 7, 8]) typically combine two (rather low-level) simulators, one for simulating the programmable components running the software and one for the dedicated hardware. For software simulation, instruction-level processor simulators are often used, whereas HDLs such as VHDL are usually used for the hardware simulation. Figure 1(a) illustrates the general idea behind co-simulation. In this figure, the white half circles refer to the software components which are executed on programmable architecture components (black half circles) and the arrows indicate the interactions between the software and hardware simulators. A major drawback of this type of co-simulation is its inflexibility: because an explicit distinction is made between software and hardware simulation, it must already be known which application components will be performed in software and which ones in hardware before the system model is built. This significantly complicates the performance evaluation of different hardware/software partitioning schemes since a whole new system model may be required for the assessment of each partitioning. For this reason, the co-simulation stage is often preceded by a stage in which the application is studied in isolation by means of a functional software model written in a high level language. This typically results in rough estimations of the application’s performance requirements, which are subsequently used as guidance for the hardware/software partitioning. In that case, the co-simulation stage is mainly used as verification of the chosen hardware/software partitioning and not as a design space exploration vehicle. Another issue that most of today’s co-simulation research efforts fail to address is how architecture models can be refined in a seamless manner across multiple levels of abstraction and how mixed-level ar-

Application model

Software model

Computational & communication events

Programmable HW model

(a)

Dedicated HW model

Architecture model (Programmable + reconf./dedicated HW) (b)

Figure 1: (a) Typical hardware/software cosimulation versus (b) the Artemis/Sesame approach. chitecture models (in which various architecture components are modeled at different levels of abstraction) are best supported. To overcome the limitations of traditional cosimulation, Sesame applies a different, more flexible, simulation methodology which will be the subject of the following section.

3 The simulation methodology Based on previously gained experience [3, 9], we strongly believe that the recognition of separate application and architecture models for the simulation of embedded systems architectures plays a key role in establishing a high degree of modeling and exploration flexibility. This methodology is illustrated in figure 1(b). An application model describes the functional behavior of an application, including both computational and communication behavior. The architecture model defines the architecture resources and captures their timing behavior. The resources modeled by the architecture model can range from fully programmable processor cores to dedicated hardware blocks. Essential in this modeling methodology is that the application model is independent from architectural specifics, assumptions on hardware/software partitioning or timing characteristics. As a result, a single application model can be used to exercise different hardware/software partitionings and can be mapped onto a range of architecture models, possibly representing different system architectures or simply modeling the same system architecture at various levels of abstraction. This clearly demonstrates the strength of decoupling the application and architecture models: it enables the reuse of both types of models. After mapping, an application model is co-simulated with an architecture model allowing for evaluating the system performance of a particular application, mapping and underlying architecture.

3.1 Trace-driven co-simulation To co-simulate the application and architecture models, an interface between the two must be provided, including a specification of the mapping. For this purpose, we apply trace-driven simulation. In

our approach, the application model is structured as a network of concurrent communicating processes, thereby expressing the inherent parallelism available in the application and making communication explicit. Each process, when executed, produces a trace of events which represents the application workload imposed on the architecture by that particular process. Thus, the trace events refer to the computational and communication operations performed by an application process. These operations may be coarse grain, such as ‘compute a Discrete Cosine Transform (DCT)’. Therefore, our approach differs from classical trace-driven simulation in which the events typically refer to fine-grained operations [10]. Since application models represent the functional behavior of applications, the traces correctly reflect data dependent behavior. Consequently, the architecture models which are driven by the application traces do not need to represent functional behavior but only need to account for the performance consequences of the application events.

3.2

Application modeling

For the modeling of applications, we use the Kahn Process Networks model of computation [11]. To obtain a Kahn application model, a sequential application is restructured into a program consisting of parallel processes communicating with each other via unbounded FIFO channels. In the Kahn paradigm, reading from channels is done in a blocking manner, while writing is non-blocking. The computational behavior of an application can be captured by instrumenting the code of each Kahn process with annotations which describe the application’s computational actions. The reading from or writing to Kahn channels represent the communication behavior of a process within the application model. By executing the Kahn model, each process can record its actions in order to generate the trace of application events necessary for driving the architecture model. In the field of application modeling, a lot of research has been done on models of computation (e.g. [12]). We decided to use Kahn Process Networks for application modeling because they nicely fit with the media processing application domain (to which our target applications belong) and have the property of being deterministic. The latter means that the same application input always results in the same application output, i.e. the application behavior is architecture independent. This automatically guarantees the validity of the event traces when the application and architecture simulators are executed independently of each other [13]. A beneficial side effect of using a separate application model is that it also makes it possible to analyze

Kahn process

Channel

Application model

Event trace

Proc. core

Proc. core FIFO buffer

Architecture model

Bus

Figure 2: Mapping a Kahn application model onto an architecture model. the potential performance constraints of an application in isolation from any architecture. This can be a benefit as it allows for investigating the upper bounds of the performance and may lead to early recognition of bottlenecks within the application.

3.3 Mapping and architecture modeling A model of an architecture is based on components representing (co)processors, memories, buffers, busses and so on. A performance evaluation of the architecture can be achieved by simulating the performance consequences of the incoming computational and communicational events from the application model. This requires an explicit mapping of the Kahn processes and channels of the application model onto the components from the architecture model. The generated trace of application events from a specific Kahn process is routed towards a specific component inside the architecture model by using a traceevent queue. The Kahn process dispatches its application events to this queue while the designated component in the architecture model consumes them. This is illustrated in Figure 2. As is shown, it is possible to map the trace-event queues of two or more Kahn processes onto a single architecture component (e.g. when several application tasks are mapped onto a microprocessor). In this case, the events from the different queues need to be scheduled. We reiterate that the underlying architecture model is solely a performance model and does not need to model functional behavior. An architecture model is constructed from generic building blocks provided by a library. This library contains performance models for processing cores, communication media (like busses) and different types of memory. Evidently, such a library-based modeling approach greatly simplifies the reuse of architecture model components. At a high level of abstraction, the model of a processing core is a black box which can model timing behavior of a programmable processor, a reconfig-

urable component or a dedicated hardware unit. Modeling such a variety of architectural implementations is accomplished by the fact that the architecture simulator assigns parameterizable latencies to the incoming application events. For example, to model software execution of an application event, a relatively high latency can be assigned to the event. Likewise, to model the application event being executed by dedicated or reconfigurable hardware one only needs to tag the event with a smaller latency. So, by simply varying the latencies for computational application events, different hardware/software partitionings can rapidly be evaluated at a high level of abstraction. In this approach, the communication events from the application model are used for modeling the performance consequences of data transfers and synchronizations at the architecture level. These events cause the appropriate communication component within the architecture model (onto which the communicating Kahn channel is mapped) to account for the latencies associated with the data transfers. As design decisions like hardware/software partitioning are made, components of the architecture model may be refined. This implies that the architecture model starts to reflect the characteristics of a particular implementation (e.g. dedicated versus programmable hardware). To facilitate the process of model refinement, the architecture model library should include models of common architecture components at several levels of abstraction. For example, there may be multiple instances of a microprocessor model such as a black box model, a model which accounts for the performance consequences of the processor’s memory hierarchy (e.g. TLB and caches) and a model which accounts for the performance impact of both its memory hierarchy and datapath (e.g. pipelining and ILP). To support such architecture model refinement, the events from the application model should also be refined to match with the level of detail present in the architecture model. In the next section, we will elaborate on this issue in more detail.

4

The Sesame simulation environment

The Sesame simulation environment intends to be an architecture exploration tool with which architectural design choices can be explored in an efficient and flexible manner. It does not necessarily envision a progressive refinement of the models nor does it target the synthesis of an application into an implementable design. Instead, we envision Sesame to be used alongside a design tool, as a research vehicle to rapidly investigate the design choices and for the designer to gain insight in architectures. To realize Sesame’s goal of obtaining a high degree of modeling and exploration flexibility at the ar-

chitecture level, this must be supported by the application models. An application model should be as independent from an architecture model as possible such that it can easily be co-simulated with alternative architecture models, either modeling different architectures or the same architecture at different abstraction levels. The latter also includes mixed-level architecture models. Evidently, this should all be achievable without changing the application model. Given the above requirement for Sesame’s application models, it is important that the model of computational behavior implemented by the annotations is not flat and token based, as one may be inclined to do with Kahn based models. In a flat annotation mechanism the generated application events are always of the same abstraction level as the annotations themselves. Since the generated application events should match with the amount of detail in the architecture model, a refinement of the architecture model would imply that the annotations in the application model also need to be refined. Such a correlation between the application and architecture models is undesirable for Sesame, in which we aim at application models that transparently support architecture simulation at all of the required levels of abstraction.

4.1 Hierarchical application model We are investigating the introduction of a hierarchical annotation scheme to be able to describe application behavior at multiple levels of abstraction. Typically one would instrument a program using simple annotation markers. When the program execution passes such a marker, an application event is generated. This has the major disadvantage that the annotations and the source code they represent are not directly related (i.e., the scope of an annotation is not clearly defined). Furthermore, there is only a linear relationship between the markers. A well structured software implementation of an application model can act as a guide for constructing a hierarchical relationship between the annotations. In that case, the function call-graph hierarchy is used as a reference for the abstraction level of the annotations. At a high level of abstraction, the Kahn process identifiers and the initial functions called (i.e., those at the top of the call-graph hierarchy) form the annotations. Lowering the abstraction level means that the trace events match the subroutines called from the parent functions. When decreasing even further in abstraction level, the control-flow structures become the basis of the annotations. Using the structure of the program there is always a well defined begin and end to the source code being annotated. To integrate this within a program source code we need to add some syntactic constructs with which blocks of code can be tagged with annotations.

High (Kahn) processes

Annotation abstraction

Procedures/ functions

Specified in application source

code blocks high level instructions instructions compiled assembly

Dependent on architecture (specified outside appl. model source)

Low

Figure 3: Location of annotation refinement: The refinement of the more abstract annotations is still much application dependent, whereas at lower levels of abstraction architecture issues start to play a role. In this hierarchical annotation scheme (see figure 3), refinement of the upper abstraction levels is solely an application modeling issue. Going further down the hierarchy of abstraction levels, there is a point where decomposing an annotation into finer grained events becomes more an architectural issue. The operations may become dependent on the type of architecture used. The level at which this becomes an issue is dependent on target architecture. For example, dedicated components tend to execute coarser grained operations than programmable processors. The hierarchical annotation scheme should allow for an external specification describing how to expand coarse grained events when the expansion becomes architecture dependent rather than application dependent. It is imperative that this specification is external to the Kahn application model since this avoids architectural dependencies in the application model. Moreover, the hierarchical annotation scheme requires to be extendible in the sense that the modeler only needs to describe the annotation hierarchy up to the level of interest. So, if one is not interested in instructionlevel events, then they can simply be left out in the annotation hierarchy. Further extensions to the annotation scheme we are investigating include parameterizing the annotations with information on application state. In this context, application state relates to the size, contents and location of the data being processed. A simple example of this is to parameterize the application event ‘multiply two matrices’ with the actual matrix size. Another important parameter may be the objects (variables) being referenced in the application. With this information, a trace of memory references may be constructed. This can be used for the evaluation of cache and TLB performance of microprocessor components in a heterogeneous architecture.

4.2

Architecture simulation

The Sesame architecture models are implemented in the discrete-event simulation language Pearl [14]. This is a relatively small but powerful language

High-level application model

common resource LOAD(block) COMPUTE(block)

Processor 1

load word

Processor 2

LOAD block

Shared medium

Low-level application model

load(word) compute(word) load(word) compute(word) load(word) compute(word)

Memory

Memory

throughput (images/time-period)

120

In this example a block consists of three words, and in the real program operations are interleaved.

all blocks (high abstr) all words (low abstr) mixed-level

100 80 60 40 20 0 1:7 1:51:4 1:3

1:2

2:3 4:5 1:1 5:4 3:2

2:1

3:1 4:15:1 7:1

communication:computation ratio

Figure 4: Architecture model and the corresponding simulation results. Both processors execute a program that alternates between the accessing of an individual memory and internal computation. The operations can either be specified at block level or at word level. Processor 1 executes the higher block-level model, while processor 2 performs the more detailed word-level model. Together, this composes a mixed-level simulation. As a performance metric, we observe the amount of data processed at processor 2. The simulation has been performed for different ratios regarding the communication versus computation performance. which has specifically been designed with the purpose of (abstract) computer architecture modeling in mind. As a consequence, Pearl has shown to be extremely suitable for easily and quickly building new or extending existing architecture models [15], while yielding simulation speeds of up to an order of magnitude faster than those obtained by more generalpurpose simulation languages. Evidently, the latter greatly improves the scope of the design space that can be explored in a reasonable amount of time.

and-play’ fashion by more detailed models. This embedding of refined, and possibly decomposed, component models in an otherwise unchanged architecture model seriously affects the interconnection with the rest of the architecture model. In addition, it also requires support for mixed-level simulation since the abstraction level at which the different architecture components are modeled is not necessarily the same.

Sesame exploits the high simulation speed of Pearl as well as the ease with which it can construct and extend architecture models. Starting from black box architecture models, Sesame targets the gradual refinement of the models towards the level of becoming cycle-true. It provides an architecture model library which includes models for common architecture components at several levels of abstraction. These models of architecture components are not meant to be fixed building blocks with pre-defined interfaces but merely are template models which can be extended and adapted to the user’s likings. With this scheme, a high degree of flexibility is gained (which can be helpful when refining the models) at the cost of a slightly increased effort required to build architecture models. This effort will however still be relatively small due to the modeling ease provided by Pearl.

In [16], we showed that transactions between architecture components form the main obstacle for mixedlevel simulation. With very simple models we found that a too naive use of mixed-level models easily produces bogus results which are an artifact of the mixedlevel simulation itself, rather than that they can be explained by the individual properties of the combined abstraction levels. Such a pitfall is illustrated in figure 4. The graph is only for illustrative purposes to indicate that it is problematic to merge different abstraction levels in a single simulation model. We will not draw further conclusions from it, since this would require a detailed explanation of the experiment which is beyond the scope of this paper. Figure 4 shows that the mixed-level simulation results have a completely different behavior than one would expect. Simulation of data processing of two processors at either a block or word level shows similar behavior (the top two curves in the graph), whereas the results from a mixed-level simulation strongly deviate. The reason for this is that the mixed-level model for this simulation is too straightforward: we made the simple assumption that the shared medium component is able to operate at multiple levels of ab-

At this stage, we are investigating how to adjust the level of abstraction of the architecture models in a seamless and graceful manner. Refinement of one component in the architecture model should not lead to a total new implementation of the entire model. Ideally, only the models of those architecture components which need to be refined are replaced in a ‘plug-

4.2.1 Mixed-level simulations

straction, i.e. transport either words or whole blocks in a single transaction. Over a period of time this component therefore operates at both abstraction levels, while at any given specific moment in time it operates at either the low (word) or high (block) abstraction level. For models operating at a single abstraction level, the accesses by the two processors to the shared resource are properly interleaved, while for the mixed-level simulation model this interleaving is disordered: The accesses to the shared resource have different perceptions of time for data transactions and therefore the assumption of having exclusive access to the resource (causing a bad interleaving pattern) is highly questionable. The work on mixed-level simulations is ongoing. Rather than merging multiple abstraction levels into a single model, with conflicting perceptions of time, we are currently experimenting with an approach using loosely connected partial models. Regarding the above example, such an approach yields two separate model instances for the shared medium (one for each abstraction level) which are subsequently corrected to emulate contention due to shared accesses. For a more detailed description of this modeling approach, the reader is referred to [16].

5 Summary Because of the growing need for supporting multiple applications and standards, modern embedded systems architectures increasingly become heterogeneous, in which dedicated hardware components provide high performance and programmable components provide flexibility. The design of such embedded systems becomes more and more complex due to the widening application domain they target and the variety of demands of these target applications. As a consequence, good techniques and tools are needed to efficiently explore the large number of design decisions for these embedded systems at an early design stage. In this paper, we presented the Sesame simulation environment which addresses the efficient design space exploration of heterogeneous embedded systems architectures. It targets the swift evaluation of different architecture designs, applicationarchitecture mappings and hardware/software partitionings at various levels of abstraction and for a broad range of applications. Sesame provides a high degree of evaluation flexibility by following two strategies: First, it decouples application and architecture behavior by recognizing separate application and architecture models within the system simulation. Second, it will allow for hierarchical application and architecture modeling in order to simulate system architectures at multiple levels of abstraction or even to perform mixed-level architecture simulations. Espe-

cially the latter strategy opens a whole new area of research problems that Sesame needs to address. To drive the realization and fine-tuning of the discussed application and architecture modeling methods, we are currently using a modified M-JPEG encoder application. This application, which includes dynamic quality control and can operate on both RGB and YUV formats on a per-frame basis, is modeled and studied for a number of target architectures. In [17], some initial results from this case study are presented.

References [1] W. H. Wolf. Hardware-software co-design of embedded systems. Proc. of the IEEE, 82(7):967–989, July 1994. [2] A. D. Pimentel, P. van der Wolf, E. F. Deprettere, L. O. Hertzberger, J. T. J. van Eijndhoven, and S. Vassiliadis. The Artemis architecture workbench. In Proceedings of the Progress workshop on Embedded Systems, pages 53–62, Oct. 2000. [3] P. Lieverse, P. van der Wolf, E. F. Deprettere, and K. A. Vissers. A methodology for architecture exploration of heterogeneous signal processing systems. In Proc. of the Workshop on Signal Processing Systems, pages 181–190, 1999. [4] J. Rowson. Hardware/software co-simulation. In Proc. of the Design Automation Conference, pages 439–440, 1994. [5] H. H¨ubert. A survey of HW/SW cosimulation techniques and tools. Master’s thesis, Royal Inst. of Tech., Sweden, June 1998. [6] S. L. Coumeri and D. E. Thomas. A simulation environment for hardware-software codesign. In Proceedings of the Int. Conference on Computer Design, pages 58–63, Oct. 1995. [7] C. Passerone, L. Lavagno, M. Chiodo, and A. Sangiovanni-Vincentelli. Fast hardware/software co-simulation for virtual prototyping and trade-off analysis. In Proc. of the Design Automation Conference, 1997. [8] K. Hines and G. Borriello. Dynamic communication models in embedded system cosimulation. In Proc. of the Design Automation Conference, 1997. [9] A. D. Pimentel and L. O. Hertzberger. An architecture workbench for multicomputers. In Proc. of the 11th Int. Parallel Processing Symposium, pages 94–99, April 1997.

[10] R. A. Uhlig and T. N. Mudge. Trace-driven memory simulation: A survey. ACM Computing Surveys, 29(2):128–170, 1997. [11] G. Kahn. The semantics of a simple lamguage for parallel programming. In Proceedings of the IFIP Congress 74, 1974. [12] J. Buck, S. Ha, E. A. Lee, and D. G. Messerschmitt. Ptolemy: A framework for simulating and prototyping heterogenous systems. Int. Journal of Computer Simulation, 4:155– 182, Apr. 1994. [13] M. Dubois, F. A. Briggs, I. Patil, and M. Balakrishnan. Trace-driven simulations of parallel and distributed algorithms in multiprocessors. In Proc. of the 1986 Int. Conference in Parallel Processing, pages 909–915, Aug. 1986. [14] H. L. Muller. Simulating computer architectures. PhD thesis, Dept. of Computer Science, Univ. of Amsterdam, Feb. 1993. [15] A. D. Pimentel. A Computer Architecture Workbench. PhD thesis, Dept. of Computer Science, Univ. of Amsterdam, Dec. 1998. [16] A. W. van Halderen, A. Belloum, A. D. Pimentel, and L.O. Hertzberger. On hybrid abstraction-level models in architecture simulation. In Proceedings of the Progress workshop on Embedded Systems, pages 29–36, Oct. 2000. [17] T. Stefanov, P. Lieverse, E. F. Deprettere, and P. van der Wolf. Y-chart based system level performance analysis: an M-JPEG case study. In Proceedings of the Progress workshop on Embedded Systems, pages 113–124, Oct. 2000.