Noc Stuffs
Content
Electronic System-Level Synthesis Methodologies
Andreas Gerstlauer, Member, IEEE, Christian Haubelt, Member, IEEE, Andy D. Pimentel, Senior Member, IEEE, Todor P. Stefanov, Member, IEEE, Daniel D. Gajski, Fellow, IEEE, and Jürgen Teich, Senior Member, IEEE
Abstract—With ever-increasing system complexities, all major semiconductor roadmaps have identified the need for moving to higher levels of abstraction in order to increase productivity in electronic system design. Most recently, many approaches and tools that claim to realize and support a design process at the so-called electronic system level (ESL) have emerged. However, faced with the vast complexity challenges, in most cases at best, only partial solutions are available. In this paper, we develop and propose a novel classification for ESL synthesis tools, and we will present six different academic approaches in this context. Based on these observations, we can identify such common principles and needs as they are leading toward and are ultimately required for a true ESL synthesis solution, covering the whole design process from specification to implementation for complete systems across hardware and software boundaries. Index Terms—Electronic system level (ESL), methodology, synthesis.
I. INTRODUCTION
I
N ORDER to increase design productivity, raising the level
of abstraction to the electronic system level (ESL) seems mandatory. Surely, this must be accompanied by new design automation tools [1]. Many approaches exist today that claim to provide ESL solutions. In [2], Densmore et al. define an ESL classification framework that focuses on individual design tasks by reviewing more than 90 different point tools. Many of these tools are devoted to modeling purposes (functional or platform) only. Other tools provide synthesis functionality by either software code generation or C-to-RTL high-level synthesis. However, true ESL synthesis tools show the ability to combine design tasks under a complete flow that can generate systems across hardware and software boundaries from an algorithmic specification. In this paper, we therefore aim to provide an extended classification focusing on such complete ESL flows on top of individual point solutions.
Manuscript received February 24, 2009; revised June 6, 2009. Current version published September 18, 2009. This paper was recommended by Associate Editor P. Eles. A. Gerstlauer is with the Department of Electrical and Computer Engineering, University of Texas at Austin, Austin, TX 78712 USA (e-mail: [email protected]). C. Haubelt and J. Teich are with the Department of Computer Science, University of Erlangen–Nuremberg, 91054 Erlangen, Germany (e-mail: [email protected]; [email protected]). A. D. Pimentel is with the Informatics Institute, University of Amsterdam, 1098 XG Amsterdam, The Netherlands (e-mail: [email protected]). T. P. Stefanov is with the Leiden Institute of Advanced Computer Science, Leiden University, 2300 RA Leiden, The Netherlands (e-mail: [email protected]). D. D. Gajski is with the Center for Embedded Computer Systems, University of California, Irvine, CA 92697 USA (e-mail: [email protected]).
Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TCAD.2009.2026356
Typically, ESL synthesis tools are domain specific and rely on powerful computational models [3] for description of desired functional and nonfunctional requirements at the input of the synthesis flow. Such well-defined rich input models are a prerequisite for later analysis and optimization. Typical computational models in digital system design are process networks, dataflow models, or state machines. On the other hand, implementation platforms for such systems are often heterogeneous or homogeneous multiprocessor system-on-chip (MPSoC) solutions [4]. The complexity introduced by both input computational model and target implementation platform results in a complex synthesis step, including hardware/ software partitioning, embedded software generation, and hardware accelerator synthesis. Aside from this, at ESL, the number of design decisions, particularly in communication synthesis, is compelling in contrast to lower abstraction levels. Even more so, due to the increasing number of processors in MPSoCs, the impact of the quality in computation and communication synthesis is ever increasing. In this paper, we aim to provide an analysis and comparative overview of the state-of-the-art current directions and future needs in ESL synthesis methodologies and tools. After identifying common principles based on our observations, we develop and propose a general framework for classification and, eventually, comparison of different tools in Section II. In Section III, we then present, in detail, a representative selection of three ESL approaches developed in our groups. To provide a more complete overview, Section IV briefly discusses three related academic approaches. After introducing all six tools, we follow with a comparison and discussion of future research directions based on our classification criteria in Section V. Finally, this paper concludes with a summary in Section VI. II. ELECTRONIC SYSTEM DESIGN In this section, we will identify common principles in existing ESL synthesis methodologies and develop a novel classification for such approaches. Later, this will enable a comparison of different methodologies. Furthermore, based on such observations, synergies between different approaches can be explored, and corresponding interfaces between different tools can be defined and established in the future. A. Design Flow Before deriving a model for ESL synthesis, we start by defining the system design process in general. As nearly all ESL synthesis methodologies follow a top–down approach, a definition of the design process should support this view.
0278-0070/$26.00 © 2009 IEEE
1518 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 28, NO. 10, OCTOBER 2009
Fig. 1. Electronic system design flow.
Furthermore, it should show the concurrent design of hardware and software and required synthesis steps. A visualization of this is given by the double roof model [5] shown in Fig. 1. The double roof model defines the ideal top–down design process for embedded hardware/software systems. One side of the roof corresponds to the software design process, whereas
the other side corresponds to the hardware design process. Each side is organized in different abstraction levels, e.g., task and instruction levels or component and logic levels for the software or hardware design processes, respectively. There is one common level of abstraction, the ESL, at which we cannot distinguish between hardware and software. At each level, in a synthesis step (vertical arrow), a specification is transformed into an implementation. Horizontal arrows indicate the step of passing models of individual elements in the implementation directly to the next lower level of abstraction as specifications at its input. The double roof model can be seen as extending the Y-chart [6] by an explicit separation of software and hardware design. Furthermore, for simplicity, we do not include a third layout roof representing a physical view of the design. Note, however, that layout information, while traditionally being of minor importance, is increasingly employed even at the system level, e.g., through early floorplanning, to account for spatial effects such as activity hot spots [7], wiring capacitances, or distance-dependent latencies [8]. The design process represented by the double roof model starts with an ESL specification given by a behavioral model that is often some kind of network of processes communicating via channels. In addition, a set of mapping constraints and implementation constraints (maximum area, minimal throughput, etc.) is given. The platform model at ESL is typically a structural model consisting of architectural components such as processors, busses, memories, and hardware accelerators. The task of ESL synthesis is then the process of selecting an appropriate platform architecture, determining a mapping of the behavioral model onto that architecture, and generating a corresponding implementation of the behavior running on the platform. The result is a refined model containing all design decisions and quality metrics, such as throughput, latency, or area. If selected, components of this refined model are then used as input to the design process at lower abstraction levels, where each hardware or software processor in the system architecture is further implemented separately. Synthesis at lower levels is a similar process in which a behavioral or functional specification is refined down into a structural implementation. However, depending on the abstraction level, the granularity of objects handled during synthesis differs, and some tasks might be more important than others. For instance, at the task level on the software side, communicating processes/threads bound to the same processor must be translated into the instruction-set architecture (ISA) of the processor, targeted toward and running on top of an off-theshelf real-time operating system (RTOS) or a custom-generated runtime environment. This software task synthesis step is typically performed using a (cross-)compiler and linker tool chain for the selected processor and RTOS. At the instruction level, the instruction set of programmable processors is then realized in hardware by implementing the underlying microarchitecture. This step results in a structural model of the processor’s data path organization, usually specified as a register-transfer level (RTL) description.
On the other hand, at the component level on the hardware side, processes selected to be implemented as hardware accelerators are synthesized down to an RTL description in the form of controller state machines that drive a datapath consisting of functional units, register files, memories, and interconnect. This refinement step is commonly referred to as behavioral or high-level synthesis. Today, there are several tools available to perform such a high-level synthesis automatically [9], [10]. Finally, at the logic level, the granularity of the objects considered during logic synthesis then corresponds to Boolean formulas implemented by logic gates and flip-flops. An important observation that can be made from Fig. 1 is that, at the RT level, hardware and software worlds unite again, both feeding into (traditional) logic design processes down to the final manufacturing output. In addition, we note that a top–down ESL design process relies on the availability of design flows at the component or task (and eventually logic and instruction) levels to feed into on the hardware and software side, respectively. Lower level flows can be supplied either in the form of corresponding synthesis tools or by providing predesigned intellectual property (IP) components to be plugged into the system architecture. B. Synthesis Process Before identifying the main tasks in ESL synthesis, we first develop a general synthesis framework applicable at all levels. As discussed in the previous section, during synthesis, a specification is generally transformed into an implementation. This abstract view can be further refined into an X-chart as shown in Fig. 2. With this refinement, we can start to define terms that are essential in the context of synthesis. A specification is composed of a behavioral model and constraints. The behavioral model represents the intended functionality of the system. Its expressibility and analyzability can be declared by its underlying model of computation (MoC) [3]. The behavioral model is often written in some programming language (e.g., C, C++, or JAVA), system-level description
GERSTLAUER et al.: ELECTRONIC SYSTEM-LEVEL SYNTHESIS METHODOLOGIES 1519
Fig. 2. Synthesis process.
language (SLDL) (e.g., SpecC or SystemC), or a hardware description language (HDL) (such as Verilog or VHDL). The constraints often include an implicit or explicit platform model that describes an architecture template, e.g., available resources, their capabilities (or services), and their interconnections. Analogous to the classification of behavioral models into MoCs, specific ways of describing architecture templates can be generalized into models of architecture (MoAs) [11]. Similar to the concept of MoCs, an MoA describes the characteristics underlying a class of platform models in order to evaluate the richness of supported target architectures at the input of a synthesis tool. ESL architecture templates can be coarsely subdivided based on their processing, memory, and communication hierarchy. On the processing side, examples include single-processor systems, hardware/software processor/coprocessor systems, and homogeneous, symmetric or heterogeneous, asymmetric multiprocessor/multicore systems (MPSoCs) [4].1 Memorywise, we can distinguish shared
versus distributed memory architectures. Finally, communication architectures can be loosely grouped into shared busbased or network-on-chip (NoC) approaches. Aside from the architecture template, constraints typically contain mapping restrictions and additional constraints on nonfunctional properties like maximum response time or minimal throughput. The synthesis step then transforms a specification into an implementation. An implementation consists of a structural model and quality numbers. The structural model is a refined model from the behavioral model under the constraints given in the specification. In addition to the implementationindependent information contained in the behavioral model, the structural model holds information about the realization of design decisions from the previous synthesis step, i.e., mapping of the behavioral model onto an architecture template. As such, a structural model is a representation of the resulting architecture as a composition of components that are internally described in the form of behavioral models for input to the next synthesis step. On top of a well-defined combination of MoCs
1While
details of supported architecture features and restrictions, as defined, e.g., by tool database formats, can differ significantly, we limit discussions and comparisons to such high-level MoA classifications in this paper.
for component-internal behavior and functional semantics, we can hence introduce the term model of structure (MoS) for separate classification of such implementation representations and their architectural or structural semantics. Again, a MoS allows characterization of the underlying abstracted semantics of a class of structural models independent of their syntax. Hence, MoSs can be used to compare expressibility and analyzability of specific implementation representations as realized by different tools. For example, at many levels, a netlist concept is used with semantics limited to describing component connectivity. At the system level, pin-accurate models combine a netlist with bus-functional component models. Furthermore, transaction-level modeling (TLM) concepts and techniques are employed to abstract away from pins and wires.2 Similar to behavioral models, structural models are often represented in a programming language, SLDL, or HDL. Quality numbers are estimated values for different implementation properties, e.g., throughput, latency, response time, area, and power consumption. In order to get such estimates, synthesis tools often use so-called performance models instead of implementing each design option.3 Performance models represent the contributions of individual elements to overall design quality in a given implementation. Basic numbers are composed based on specific semantics, e.g., in terms of annotation granularity or worst/average/best case assumptions, such that the overall quality estimates can be obtained, e.g., through simulation or static analysis. To distinguish and classify representations of quality numbers across different instances and implementations of performance models, we introduce the concept of an underlying model of performance (MoP). A MoP thereby refers to the overall accuracy and granularity in time and space. Generalizing from the detailed definitions of specific performance models, such as timing, power, or cost/area models, a MoP can be used to judge the accuracy
of the quality numbers and the computational effort to get them. Examples of simulation-based MoPs for different classes of timing granularity are cycle-accurate performance models (CAPMs), instruction-set-accurate performance models (ISAPMs), or task-accurate performance models (TAPMs) [12]. Quality numbers are often used as objective values during design-space exploration (DSE) when identifying the set of optimal or near-optimal implementations. Given a specification, the task of synthesis then generates an implementation from the specification by decision making and refinement (Fig. 2). At any level, synthesis is a process of determining the order or mapping of elements in the behavioral model in space and time, i.e., the where and when of their realization. Decision making is hence the task of computing an allocation of resources available in the platform model, a spatial binding of objects in the behavioral model onto these allocated resources, and a temporal scheduling to resolve resource contention of objects in the behavioral model bound to the same resource.
2Again,
many definitions of specific TLM variants exist, but for simplicity, we limit discussions in this paper to a general classification. 3We use the term “performance” in the
Andreas Gerstlauer, Member, IEEE, Christian Haubelt, Member, IEEE, Andy D. Pimentel, Senior Member, IEEE, Todor P. Stefanov, Member, IEEE, Daniel D. Gajski, Fellow, IEEE, and Jürgen Teich, Senior Member, IEEE
Abstract—With ever-increasing system complexities, all major semiconductor roadmaps have identified the need for moving to higher levels of abstraction in order to increase productivity in electronic system design. Most recently, many approaches and tools that claim to realize and support a design process at the so-called electronic system level (ESL) have emerged. However, faced with the vast complexity challenges, in most cases at best, only partial solutions are available. In this paper, we develop and propose a novel classification for ESL synthesis tools, and we will present six different academic approaches in this context. Based on these observations, we can identify such common principles and needs as they are leading toward and are ultimately required for a true ESL synthesis solution, covering the whole design process from specification to implementation for complete systems across hardware and software boundaries. Index Terms—Electronic system level (ESL), methodology, synthesis.
I. INTRODUCTION
I
N ORDER to increase design productivity, raising the level
of abstraction to the electronic system level (ESL) seems mandatory. Surely, this must be accompanied by new design automation tools [1]. Many approaches exist today that claim to provide ESL solutions. In [2], Densmore et al. define an ESL classification framework that focuses on individual design tasks by reviewing more than 90 different point tools. Many of these tools are devoted to modeling purposes (functional or platform) only. Other tools provide synthesis functionality by either software code generation or C-to-RTL high-level synthesis. However, true ESL synthesis tools show the ability to combine design tasks under a complete flow that can generate systems across hardware and software boundaries from an algorithmic specification. In this paper, we therefore aim to provide an extended classification focusing on such complete ESL flows on top of individual point solutions.
Manuscript received February 24, 2009; revised June 6, 2009. Current version published September 18, 2009. This paper was recommended by Associate Editor P. Eles. A. Gerstlauer is with the Department of Electrical and Computer Engineering, University of Texas at Austin, Austin, TX 78712 USA (e-mail: [email protected]). C. Haubelt and J. Teich are with the Department of Computer Science, University of Erlangen–Nuremberg, 91054 Erlangen, Germany (e-mail: [email protected]; [email protected]). A. D. Pimentel is with the Informatics Institute, University of Amsterdam, 1098 XG Amsterdam, The Netherlands (e-mail: [email protected]). T. P. Stefanov is with the Leiden Institute of Advanced Computer Science, Leiden University, 2300 RA Leiden, The Netherlands (e-mail: [email protected]). D. D. Gajski is with the Center for Embedded Computer Systems, University of California, Irvine, CA 92697 USA (e-mail: [email protected]).
Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TCAD.2009.2026356
Typically, ESL synthesis tools are domain specific and rely on powerful computational models [3] for description of desired functional and nonfunctional requirements at the input of the synthesis flow. Such well-defined rich input models are a prerequisite for later analysis and optimization. Typical computational models in digital system design are process networks, dataflow models, or state machines. On the other hand, implementation platforms for such systems are often heterogeneous or homogeneous multiprocessor system-on-chip (MPSoC) solutions [4]. The complexity introduced by both input computational model and target implementation platform results in a complex synthesis step, including hardware/ software partitioning, embedded software generation, and hardware accelerator synthesis. Aside from this, at ESL, the number of design decisions, particularly in communication synthesis, is compelling in contrast to lower abstraction levels. Even more so, due to the increasing number of processors in MPSoCs, the impact of the quality in computation and communication synthesis is ever increasing. In this paper, we aim to provide an analysis and comparative overview of the state-of-the-art current directions and future needs in ESL synthesis methodologies and tools. After identifying common principles based on our observations, we develop and propose a general framework for classification and, eventually, comparison of different tools in Section II. In Section III, we then present, in detail, a representative selection of three ESL approaches developed in our groups. To provide a more complete overview, Section IV briefly discusses three related academic approaches. After introducing all six tools, we follow with a comparison and discussion of future research directions based on our classification criteria in Section V. Finally, this paper concludes with a summary in Section VI. II. ELECTRONIC SYSTEM DESIGN In this section, we will identify common principles in existing ESL synthesis methodologies and develop a novel classification for such approaches. Later, this will enable a comparison of different methodologies. Furthermore, based on such observations, synergies between different approaches can be explored, and corresponding interfaces between different tools can be defined and established in the future. A. Design Flow Before deriving a model for ESL synthesis, we start by defining the system design process in general. As nearly all ESL synthesis methodologies follow a top–down approach, a definition of the design process should support this view.
0278-0070/$26.00 © 2009 IEEE
1518 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS, VOL. 28, NO. 10, OCTOBER 2009
Fig. 1. Electronic system design flow.
Furthermore, it should show the concurrent design of hardware and software and required synthesis steps. A visualization of this is given by the double roof model [5] shown in Fig. 1. The double roof model defines the ideal top–down design process for embedded hardware/software systems. One side of the roof corresponds to the software design process, whereas
the other side corresponds to the hardware design process. Each side is organized in different abstraction levels, e.g., task and instruction levels or component and logic levels for the software or hardware design processes, respectively. There is one common level of abstraction, the ESL, at which we cannot distinguish between hardware and software. At each level, in a synthesis step (vertical arrow), a specification is transformed into an implementation. Horizontal arrows indicate the step of passing models of individual elements in the implementation directly to the next lower level of abstraction as specifications at its input. The double roof model can be seen as extending the Y-chart [6] by an explicit separation of software and hardware design. Furthermore, for simplicity, we do not include a third layout roof representing a physical view of the design. Note, however, that layout information, while traditionally being of minor importance, is increasingly employed even at the system level, e.g., through early floorplanning, to account for spatial effects such as activity hot spots [7], wiring capacitances, or distance-dependent latencies [8]. The design process represented by the double roof model starts with an ESL specification given by a behavioral model that is often some kind of network of processes communicating via channels. In addition, a set of mapping constraints and implementation constraints (maximum area, minimal throughput, etc.) is given. The platform model at ESL is typically a structural model consisting of architectural components such as processors, busses, memories, and hardware accelerators. The task of ESL synthesis is then the process of selecting an appropriate platform architecture, determining a mapping of the behavioral model onto that architecture, and generating a corresponding implementation of the behavior running on the platform. The result is a refined model containing all design decisions and quality metrics, such as throughput, latency, or area. If selected, components of this refined model are then used as input to the design process at lower abstraction levels, where each hardware or software processor in the system architecture is further implemented separately. Synthesis at lower levels is a similar process in which a behavioral or functional specification is refined down into a structural implementation. However, depending on the abstraction level, the granularity of objects handled during synthesis differs, and some tasks might be more important than others. For instance, at the task level on the software side, communicating processes/threads bound to the same processor must be translated into the instruction-set architecture (ISA) of the processor, targeted toward and running on top of an off-theshelf real-time operating system (RTOS) or a custom-generated runtime environment. This software task synthesis step is typically performed using a (cross-)compiler and linker tool chain for the selected processor and RTOS. At the instruction level, the instruction set of programmable processors is then realized in hardware by implementing the underlying microarchitecture. This step results in a structural model of the processor’s data path organization, usually specified as a register-transfer level (RTL) description.
On the other hand, at the component level on the hardware side, processes selected to be implemented as hardware accelerators are synthesized down to an RTL description in the form of controller state machines that drive a datapath consisting of functional units, register files, memories, and interconnect. This refinement step is commonly referred to as behavioral or high-level synthesis. Today, there are several tools available to perform such a high-level synthesis automatically [9], [10]. Finally, at the logic level, the granularity of the objects considered during logic synthesis then corresponds to Boolean formulas implemented by logic gates and flip-flops. An important observation that can be made from Fig. 1 is that, at the RT level, hardware and software worlds unite again, both feeding into (traditional) logic design processes down to the final manufacturing output. In addition, we note that a top–down ESL design process relies on the availability of design flows at the component or task (and eventually logic and instruction) levels to feed into on the hardware and software side, respectively. Lower level flows can be supplied either in the form of corresponding synthesis tools or by providing predesigned intellectual property (IP) components to be plugged into the system architecture. B. Synthesis Process Before identifying the main tasks in ESL synthesis, we first develop a general synthesis framework applicable at all levels. As discussed in the previous section, during synthesis, a specification is generally transformed into an implementation. This abstract view can be further refined into an X-chart as shown in Fig. 2. With this refinement, we can start to define terms that are essential in the context of synthesis. A specification is composed of a behavioral model and constraints. The behavioral model represents the intended functionality of the system. Its expressibility and analyzability can be declared by its underlying model of computation (MoC) [3]. The behavioral model is often written in some programming language (e.g., C, C++, or JAVA), system-level description
GERSTLAUER et al.: ELECTRONIC SYSTEM-LEVEL SYNTHESIS METHODOLOGIES 1519
Fig. 2. Synthesis process.
language (SLDL) (e.g., SpecC or SystemC), or a hardware description language (HDL) (such as Verilog or VHDL). The constraints often include an implicit or explicit platform model that describes an architecture template, e.g., available resources, their capabilities (or services), and their interconnections. Analogous to the classification of behavioral models into MoCs, specific ways of describing architecture templates can be generalized into models of architecture (MoAs) [11]. Similar to the concept of MoCs, an MoA describes the characteristics underlying a class of platform models in order to evaluate the richness of supported target architectures at the input of a synthesis tool. ESL architecture templates can be coarsely subdivided based on their processing, memory, and communication hierarchy. On the processing side, examples include single-processor systems, hardware/software processor/coprocessor systems, and homogeneous, symmetric or heterogeneous, asymmetric multiprocessor/multicore systems (MPSoCs) [4].1 Memorywise, we can distinguish shared
versus distributed memory architectures. Finally, communication architectures can be loosely grouped into shared busbased or network-on-chip (NoC) approaches. Aside from the architecture template, constraints typically contain mapping restrictions and additional constraints on nonfunctional properties like maximum response time or minimal throughput. The synthesis step then transforms a specification into an implementation. An implementation consists of a structural model and quality numbers. The structural model is a refined model from the behavioral model under the constraints given in the specification. In addition to the implementationindependent information contained in the behavioral model, the structural model holds information about the realization of design decisions from the previous synthesis step, i.e., mapping of the behavioral model onto an architecture template. As such, a structural model is a representation of the resulting architecture as a composition of components that are internally described in the form of behavioral models for input to the next synthesis step. On top of a well-defined combination of MoCs
1While
details of supported architecture features and restrictions, as defined, e.g., by tool database formats, can differ significantly, we limit discussions and comparisons to such high-level MoA classifications in this paper.
for component-internal behavior and functional semantics, we can hence introduce the term model of structure (MoS) for separate classification of such implementation representations and their architectural or structural semantics. Again, a MoS allows characterization of the underlying abstracted semantics of a class of structural models independent of their syntax. Hence, MoSs can be used to compare expressibility and analyzability of specific implementation representations as realized by different tools. For example, at many levels, a netlist concept is used with semantics limited to describing component connectivity. At the system level, pin-accurate models combine a netlist with bus-functional component models. Furthermore, transaction-level modeling (TLM) concepts and techniques are employed to abstract away from pins and wires.2 Similar to behavioral models, structural models are often represented in a programming language, SLDL, or HDL. Quality numbers are estimated values for different implementation properties, e.g., throughput, latency, response time, area, and power consumption. In order to get such estimates, synthesis tools often use so-called performance models instead of implementing each design option.3 Performance models represent the contributions of individual elements to overall design quality in a given implementation. Basic numbers are composed based on specific semantics, e.g., in terms of annotation granularity or worst/average/best case assumptions, such that the overall quality estimates can be obtained, e.g., through simulation or static analysis. To distinguish and classify representations of quality numbers across different instances and implementations of performance models, we introduce the concept of an underlying model of performance (MoP). A MoP thereby refers to the overall accuracy and granularity in time and space. Generalizing from the detailed definitions of specific performance models, such as timing, power, or cost/area models, a MoP can be used to judge the accuracy
of the quality numbers and the computational effort to get them. Examples of simulation-based MoPs for different classes of timing granularity are cycle-accurate performance models (CAPMs), instruction-set-accurate performance models (ISAPMs), or task-accurate performance models (TAPMs) [12]. Quality numbers are often used as objective values during design-space exploration (DSE) when identifying the set of optimal or near-optimal implementations. Given a specification, the task of synthesis then generates an implementation from the specification by decision making and refinement (Fig. 2). At any level, synthesis is a process of determining the order or mapping of elements in the behavioral model in space and time, i.e., the where and when of their realization. Decision making is hence the task of computing an allocation of resources available in the platform model, a spatial binding of objects in the behavioral model onto these allocated resources, and a temporal scheduling to resolve resource contention of objects in the behavioral model bound to the same resource.
2Again,
many definitions of specific TLM variants exist, but for simplicity, we limit discussions in this paper to a general classification. 3We use the term “performance” in the
