The intention of this section is to underline the differences between our exploration method and other closely related exploration methods [7, 36], and at the same time, to point point out the added advantages of our mapping method.
Our method is a simulation based exploration method, and as such it relies on: i) high-level and abstract models (representations) of both applications and architectures, ii) a repository of non-functional architecture components, iii) discrete-event component implementations (e.g.,SystemC) instead of cycle-accurate component implementations, and, finally, iv) the exploration-aimed Y-chart [14] (see Chapter 1, Section 1.2.2).
However, amongst other simulation based exploration methods mentioned earlier [7, 36], this is also a very distinctive method . The three major differences are:
1. Rather than using so-called trace-driven approach where an application process behav- ior is captured by the symbolic instruction trace, our method captures an application process behavior using a generic CDFG-like representation - symbolic program - and the corresponding sequential control trace.
2. Rather than relying on heuristic solutions for modeling OS [7], our method is able to model OS without any model-imposed restrictions.
3. As opposed to restricting the possible application domain or architecture set to only control-dependency-free applications with rudimentary or no multi-tasking software architectures at all [36], our method is not restricted in this way.
Our application model is able to separate concerns clearly: i) the data-set insensitive informa- tion is captured in symbolic programs, and ii) the data-set sensitive information is captured in sequential control traces. Changing the data-set changes only the control trace values. Yet, the symbolic programs do not need to change because they are data-set insensitive. The same single symbolic program can be reused for any data-set as long as it is produced by the appli- cation process from which the symbolic program originated. Remember that the annotated control points in the process are in 1-to-1 relation with control points within the symbolic program (see Chapter 2, Section 2.4). It is possible to establish the generality and reuse of the same single mapping for as many data-sets as desired (as long as the control structure is not changed).
Our architecture model is based on a library of generic, high-level, abstract architectural com- ponents. They represent a mix of various formalisms (Communicating Sequential Processes, Kahn PN, Synchronous Data-Flow, State-Charts, and ROOM-charts), ideas (Master-Slave Protocols, Trace-Transformations, Transactional Protocols), technologies (Data-Structures & Algorithms, Compilers & Translators, Design-Patterns, Parallel Programming by Multi- threading, Object-Orientation, and Component-Based Development), and implementations
(Open-Sources, Library-Reuse, and Discrete-Event Simulation). If, for instance, mutual- exclusion or condition-synchronization is needed, the appropriate formalisms and technolo- gies inside or in between those components support the proper architecture model specifica- tion because the components are not CSP-only or SDF-only or Kahn-only - they are hybrids. Furthermore, the roles of each component are orthogonal to the role of the other components. Thus, computation-related mapping affects one kind of component, while communication- related mapping affects the other kind of component. Finally, components are easily ex- tensible because, as explained earlier, they are able to clearly separate computation-only, communication-only, resource-sharing and resource-schedule concerns. Therefore, each en- hancement can easily be added without affecting the entire repository of components. The architecture components interpret (unroll) and refine mapped symbolic programs at run- time, making the modeling context close to the real architecture context24. Performing un-
rolling and refinement at run-time is particularly beneficial for the modeling of real system software . For run-time refinement, various synchronization issues remain open, and since they are open, they need to be closed as well. If we were to remove synchronization from the architecture, the model becomes poorer (or restricted) and, worse still, the omission of this significant component is simply overlooked. Moreover, synchronization is in general a costly operation from the performance point of view, and hence we do not exclude it from the architecture model.
Our method resembles the standard synthesis-driven mappings quite closely (see Section 4.1). Even-more, one can identify similarities with real-designs or even recode our abstract map- pings to the real (synthesizable) code. As such, our method is both iterative and waterfall- like [61]. It is not able to “prune exploration space efficiently” as for instance the method described in [36] does. Yet, it connects well with real designs; as described above there are almost no restrictions when dealing with streaming application/architecture combinations and it supports reuse to a large extent. Therefore, we believe that it is a better (more complete) candidate for efficient architecture exploration than for instance the methods [7, 36]. The reason has its roots in the product-development of today’s consumer-electronics industry; embedded designers are asked often to provide quick rough estimates of some real applica- tion standard (e.g., JPEG, MPEG-2, MPEG-4, etc.) running on some high-end MPSoC ar- chitecture (e.g.,Wasabi-like MPSoC). In such cases, an embedded system designer usually performs an example-case which represents the implementation with the most challenging ap- plication specification and maps it on the architecture exploration simulator of the designer’s choice. Now, if the simulator is too low level, this trial would require an unjustifiably greater expenditure of time and effort. This fact justifies the use of high-level abstract exploration methods such ours or any other similar [7, 36]. Nevertheless, if the exploration method can- not handle/model neither the application specification nor the architecture specification, then the method will simply be avoided. Moreover, if a designer can establish some correlation between: 1) the mapping steps he is asked to execute in the exploration method and 2) the mapping steps he has to perform in the real synthesis process, he will be in favor of this type of high-level exploration method. Our method allows for all the above:
• It is not selective with respect to mapping cases, neither from the aspect of the applica- 24Sesame, for example, really decouples trace refinement from the architecture, making the mapping layer re-
tion behavior nor from the aspect of the architecture features.
• It resembles the real synthesis flow, as in [85] as well as the real code transformations from [56], [86] and [55].
• It is easily extensible, since its components are orthogonalized - changing one compo- nent will not affect the sequencing in the others.
• It relies on discrete-event simulation, so it is fast enough (e.g., compared to cycle- accurate approaches).
• It can be easily further automated in two directions: by better pruning of design-space by generating Pareto curves [37], and by introducing an appropriate memory-hierarchy model (cache modeling).These two improvements will not affect its current robustness, generality and re-usability.
Chapter
5
Big Picture & Conclusion
What concerns me is not the way things are, but rather the way people think things are.1
5.1
Summary
The main aim of this chapter is to provide the complete view of relations between models, model representations and simulations for performance analysis as part of a Design Space Exploration (DSE) process.
Models and model representations are on a level of abstraction where flexibility, accuracy and cost of simulations are well balanced, see Figure 1.1. As shown in Figure 1.2, perfor- mance analysis is conducted on the association with each other of an application model and an architecture model. This association is in terms of model representations generated by the application model and interpreted by the architecture model, as well as in terms of transfor- mations to better match the two representations.
Our application model representations are Symbolic Programs (SP), see Chapter 2, and our SP interpreting architecture model is theArcher2model, see Chapter 3. We call the per- formance analysis approach theArcher Symbolic Program approach, or simply the SP
approach.
1The words of Epictetus -Eπικτ ητøς- (55 A.D.-ca.135 A.D.), Greek philosopher associated with the Stoics. 2TheArcherstands for ARCHitecture ExploRation.