System-level Modelling and Design Space Exploration for Multiprocessor Embedded System-on-chip ArchitecturesModern embedded systems come with contradictory design constraints. On one hand, these systems often target mass production and battery-based devices, and therefore should be cheap and power efficient. On the other hand, they still need to show high (sometimes real-time) performance, and often support multiple applications and standards which requires high programmability. This wide spectrum of design requirements leads to complex heterogeneous System-on-Chip (SoC) architectures -- consisting of several types of processors from fully programmable microprocessors to configurable processing cores and customized hardware components, integrated on a single chip. This study targets such multiprocessor embedded systems and strives to develop algorithms, methods, and tools to deal with a number of fundamental problems which are encountered by the system designers during the early design stages. |
Common terms and phrases
abstraction actors algorithm application events application model approach architecture model behavior block called channels Chapter co-simulation communication computation condition constraints cost crossover decision defined Definition design space discussion elements embedded systems encoder environment evaluation example execution experiments exploration FIFO Figure firing first framework function further given graph hardware implementation input Kahn process latency latter layer M-JPEG mapping layer means memory method metrics MOEAs multiobjective multiple mutation node NSGA-IIR objective obtained operations optimization parameters Pearl performance pipeline pixel platform port possible priority problem Proc process network processor provides real-time refined refinement represent requirement respect rules scheduling Sesame shown simulation single solutions SPEA2r specific static step system-level Table task task system tion token trace transformations triggered values vertex vertices write
Popular passages
Page 140 - E. Zitzler, M. Laumanns, and L. Thiele. SPEA2: Improving the Strength Pareto Evolutionary Algorithm for Multiobjective Optimization.
Page 135 - F. Balarin, E. Sentovich, M. Chiodo, P. Giusto, H. Hsieh, B. Tabbara, A. Jurecska, L. Lavagno, C. Passerone, K. Suzuki, and A.
Page 113 - Further detail is beyond the scope of this chapter and the interested reader is directed to these two references.
Page 37 - Teich et al. [8] partition this problem into two steps: the selection of the architecture (allocation), and the mapping of the algorithm onto the selected architecture in space (binding) and time (scheduling). In their framework, they only consider cost and speed of the architecture, power consumption is ignored.
Page 111 - Ti constitutes a legal triggering sequence for Tj. In other words, a legal triggering sequence for T is obtained by merging together (ordered by triggering times, with ties broken arbitrarily) legal triggering sequences of the constituting tasks. The...
Page 89 - In all experiments, we have processed 500 blocks of input data. In the first experiment, the processing elements PE2 and PE3 operate at block level and no refinement is performed. This gives us performance results for single and double buffer implementations, ie where the double buffer is a 2-entry buffer so that the producer can write to it and the consumer can read from it, simultaneously.
Page 84 - Figure 4.12, respectively). The computational execute operations are not refined, they are simply forwarded to the architecture model layer. This type of refinement not only reveals the system-bottlenecks due to synchronizations, but also makes it possible to correct them by reordering the refined operations (eg, early checking for data/room or merging multiple costly synchronizations). In this case, SDF actors represent these refined architecture-level operations. So, by sim...
Page 39 - Sesame needs an explicit mapping step to relate these models for cosimulation. In this step, the designer decides for each application process and FIFO channel a destination architecture model component to simulate its workload. Thus, this step is one of the most important stages in the design process, since the final success of the design is highly dependent on these mapping choices. In Figure 3.1, we illustrate this mapping step on a very simple example.
Page 76 - Alternatively, we can also schedule the IDF actors in a semi-static manner. To do so, the application model should first generate the entire application traces and store them into trace files (if their size permits this) prior to the architectural simulation. This static scheduling mechanism is a well-known technique in Ptolemy and has been proven to be very useful for system simulation [16].