System-level Modelling and Design Space Exploration for Multiprocessor Embedded System-on-chip Architectures
Modern 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.
What people are saying - Write a review
We haven't found any reviews in the usual places.
A. D. Pimentel application and architecture application events application model architecture components architecture level architecture model components architecture simulator architecture trace Artemis project behavior bound function buffer calibration Chapter co-simulation computation constraints crossover DCT task deadline deﬁned Deﬁnition design space exploration efﬁcient embedded systems event traces evolutionary algorithms Evolutionary Computation execution requirement FIFO channels Figure ﬁnd ﬁres ﬁring rules ﬁrst FPGA function genetic algorithm hardware IDCT IDF graph implementation inﬁnite input Kahn process network latency linear M-JPEG encoder mapping layer memory metrics model layer model reﬁnement MOEAs multiobjective optimization multiple mutation nondominated sets objective operations parameters Pareto-optimal Pearl pipeline platform architecture PNRunner preshift problem Proc recurring real-time task reﬁned SDF actors Section Sesame framework Sesame’s solutions SPEA2r and NSGA-IIr SPEA2R NSGA-IIR speciﬁc static priority scheduling system-level models system-level performance SystemC T.rbf(t task model task system token trace transformations triggered values vertex virtual processor Y-chart
Page 140 - E. Zitzler, M. Laumanns, and L. Thiele. SPEA2: Improving the Strength Pareto Evolutionary Algorithm for Multiobjective Optimization.
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.  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 .