A MARTE subset to enable application-platform co-simulation and schedulability analysis of NoC-based embedded systems

Abstract

MARTE has matured into a substantial industrially relevant profile that extends UML expressive power to support the specification and design of embedded systems. When supported by appropriate model transformation and code generation tools, MARTE forms an appropriate starting point for embedded system development.. In this paper we propose a simpler yet less powerful subset of MARTE, targeted at multiprocessor systems and amenable to early analysis (including timing) of design alternatives before committing to a particular design for implementation. We use the proposed subset of MARTE constructs to generate abstract simulation and real-time schedulability analysis models, allowing both average and worstcase performance metrics to be considered when comparing multiple design alternatives.

Analysis of buffering effects on hard real-time priority-preemptive wormhole networks

“…Figure 6 shows that the difference is never more than a few percent points. This hints that the downstream indirect interference patterns are not easily found, which explains why their effects have not been seen in previous simulation-based evaluation of SB in [17], [7]. It also clearly shows that the difference is larger in the cases with 10flit buffers, corroborating the statement made in the previous subsections that large buffers decrease the predictability of the network.…”

“…The authors do not make a clear statement about their assumptions regarding buffering and backpressure. Some of the subsequent work based on the SB analysis has assumed nodes with 2-flit buffers for each virtual channel, and a credit-based flow control to enable backpressure [17], [7]. Simulation-based experiments reported in those works provided evidence that the analysis was safe, albeit pessimistic at times.…”

End-to-end schedulability tests for multiprocessor embedded systems based on networks-on-chip with priority-preemptive arbitration

“…M1, however, has a number of unschedulable tasks, denoted by the brown crosses plotted at the upper margin of Figure 4.a (the actual worst case response times in those cases were not found, as our implementation stops iterating towards a solution once a deadline is missed). We then used the tool flow presented in [13] and the simulation models presented in [14] to obtain latency figures for the execution of the benchmark application over the platform under all three mappings. We simulated each scenario for a target time of 200 seconds, which allows for a good coverage of the application lifetime (the shortest period is of the video processing tasks, that must execute every 0.04 seconds to achieve 25 VGA frames per second, and the longest period is of 1 second for the tyre pressure control task).…”