Hardware Reference
In-Depth Information
single ADRES core). This particular configuration executes the MPEG4 encoder at
220 MHz and provides a frame rate of 15 fps .
The MPSoC platform with seven ADRES cores is over-dimensioned for the min-
imal requirement of 15 fps for each video stream needed by the CSU to operate
correctly. In fact for executing 3 MPEG4 encoders at 15 fpss , 3 ADRES cores would
be enough. The availability of different parallel versions provides to the RRM the
possibility to allocate the remaining resources to minimize the platform power con-
sumption. In particular, the RRM under the minimal requirements steadily selects
a configuration with 3 resources for the right and central cameras. The RRM takes
this decision since the MPEG4 encoder running on 3 cores can be executed at about
100 MHz, obtaining the same QoS and saving more than 5 mW of power consumption
(per 10 frames).
We can also observe that whenever a solution which matches all QoS requirements
exists, this is correctly identified by the priority-based RRM. In fact, from Figs. 9.8 b
and 9.6 it is possible to notice that there is a QoS penalty only when all cameras
require more than 15 fps . In fact, providing more than 15 fps requires as least three
ADRES cores. Thus, due to resource constraints, when all video streams require
more than 15 fps , the frame rate of the lowest priority stream has to be relaxed.
9.5
Conclusions
In this Chapter we presented an application of the RRM to the management of
resources dedicated to a multiple-stream MPEG4 encoder chip within a Automotive
Cognitive Safety System scenario.
First of all the MPEG4 encoder application has been presented together with the
specific use case requirements. The design space identified by the run-time tunable
parameters has been considered to be too huge to be explored exhaustively during
the design time DSE phase. This is the reason for performing a heuristic optimization
within an integrated DSE framework which provides optimization algorithms and
RSM techniques as the ones described in Chaps. 3 and 4.
For enabling this design-time optimization phase, a multi-simulator framework
was adopted. We showed that a High Level Simulator (HLSim) can be used to
quickly evaluate performance indices of many candidate operating configurations.
These obtained performance results are validated with cycle accurate simulations.
Once the Pareto optimal operating configurations are identified, the RRM previ-
ously proposed in Chap. 5 has been proven to be effective at identifying an operating
configuration for each of the multiple video stream. In the experiments, the RRM
always identified a configuration which is able to satisfy all constraints when this
solution exists. When the QoS requirements are too high to be matched with the
available resources, the priority based algorithm can still identify a solution to the
problem by relaxing the constraint on the application having the lowest priority.
Note that the techniques for run-time resource management discussed in this
Chapter are valid when ample design time information of all the running applications
Search WWH ::




Custom Search