7.4 Industrial Applicability: Motor Control Case-Study
7.4.4 Mapping
As mentioned above, we will consider two different inter-processor communi-cation styles for the motor control use-case. In the first style (single-beat see Fig. 7.11b), for realizing inter-processor communication between actors which are mapped to different tiles, we use the SRI andLMU resources, while in the second style (burst transfer see Fig. 7.11a) the SPB, DMA, SRI and LMU are used.
10Typically, a DMA Transaction consists of a number of Transfers, which in its turn consists of a number of Moves. A Move is the basic action of the DMA reading from one (or group of) memory cell(s) and writing to another.
SENS
fCLB FOC
sCLB MON
ACT
VOT
s_FOC_SENS_sc s_FOC_SENS
s_MCU_STM SENS2VOT1
s_MCU_STM s_MCU_STM
2 2
2
2 2
SENS2sCLB0 SENS2sCLB1
s_FOC_SENS_sc
sCLB2MON
VCU_CMDS
s_I_ST_CLB b_POS_SENS_STATUS
s_MON f_OFFSET_VEC
12
12
12 12
12
12 11
11
1
1
9
9
9
9
19
19 17
4
4 11
11 5
s_FOC
6 6
10
5
SENS2VOT0
17 fCLB2MON
10
6 6
2
(a) Burst-transfer-aware SDFG SENS
fCLB FOC
sCLB MON
ACT
VOT
s_FOC_SENS_sc s_FOC_SENS
s_MCU_STM SENS2VOT
s_MCU_STM s_MCU_STM
2 2
2
2
2 2
SENS2sCLB
s_FOC_SENS_sc
sCLB2MON
VCU_CMDS
s_I_ST_CLB b_POS_SENS_STATUS
s_MON f_OFFSET_VEC
12
12
12 12
23
1
1
9
9
9
9
19
19 17
4
4 16
16
s_FOC
6 6
10
17 6 fCLB2MON
10
23 6
(b) Single-beat-aware SDFG
Figure 7.10: Mapping-aware SDFG
PFlash LMU
SRI
SPB DMA
Shared FIFO buffers for inter-processor communication SENS2fCLB, SENS2sCLB0, SENS2FOC, SENS2sCLB1, SENS2VOT0, SENS2VOT1, VOT2sCLB, VOT2MON, MON2VOT, sCLB2VOT, MON2fCLB, fCLB2MON, sCLB2fCLB,FOC2ACT
M/S M
S S
Tile0
D I
M/S
M
Tile2 M/S
M Tile1
I M/S
M Startup Code
SENS ACT FOC VOT sCLB MON
D
S Sensor Addresses
Actuator Addresses
I
Environment Interface 1
4 3
5 2
fCLB
D
Private FIFO buffers sCLB2MON, fCLB2FOC, fCLB2VOT, VOT2FOC
(a) With burst-transfer inter-processor communication via DMA
LMU PFlash
SRI
SPB
S S
Tile0
D I
M/S
M
Tile2 M/S
M
Tile1
I M/S
M
Startup Code
ACT
SENS FOC VOT sCLB MON
D
S Sensor Addresses
Actuator Addresses
I
Environment Interface
1 5
fCLB
D
(b) With single-beat inter-processor communication via SRI
Figure 7.11: Mapping the motor control SDFG to Aurix platform
Fig.7.11shows the two styles with a possible mapping11 of the motor con-trol use-case:
1. Mapping actor(s)SENSandACTtoTile0,fCLB,FOCandVOTtoTile1, sCLB, andMONtoTile2.
Obviously, for performance reasons, edges fCLB2VOT, fCLB2FOC, VOT2FOC, sCLB2MON0and
sCLB2MON1should be mapped to the local private memories of their cor-responding tiles (fCLB2VOT, fCLB2FOC, VOT2FOCto private memory ofTile1and
sCLB2MON0, sCLB2MON1 to that ofTile2) while all other edges (since they invoke inter-processor communication) are mapped to the shared LMU, which can be accessed via interconnects either through the con-figuration (SPB, DMA, SRI, LMU) as shown in Fig. 7.11a or through configuration(SRI, LMU)as depicted in Fig.7.11b.
Fig.7.10shows mapping-aware SDFGs12, where depending on the inter-processor communication style, changes are applied on the SDFG edges (with corresponding ports’ rates) to fit this style. Tab. 7.8 depicts the transformations applied for each style. In the case of a DMA-based inter-processor communication style, a burst transfer of 16 tokens per transfer restricts the maximum transferable data to 12 tokens (each of 32 bytes size) per transfer13. The burst-transfer aware SDFG shows how at every edge a maximal amount of 12 tokens (the number of tokens transfered on every edge is depicted in brackets), whereas by the single-beat style this restriction does not exist, allowing edges with rates beyond 12.
2. Calculating a static-order schedule for the SDFG as follows:
(SENS)(fCLB)(FOC)(VOT)(sCLB)(MON)(ACT)
3. No need for choosing a hierarchical scheduling strategy since we are only considering one SDFG.
7.4.5 BCET/WCET Analysis of Software Components on single PEs With the help of Simulink Coder (R2011-b), we are able to generate target C code from the Simulink motor-control model which then manually customize to make compliant to the SDF semantics of the translated SDFG (see pseudo-code
11This mapping was suggested by the MotorBrain team [MotorBrain Consortium, 2013] for its parallelization advantages.
12In both figures,sCLB2MON0, sCLB2MON1are merged (for optimizations purpose) to one edge (sCLB2MON) with the number of tokens being summed up. This optimization can be made preserving semantics, since these two edges are mapped to the same private memory.
13Four tokens are reserved for the FIFO queue implementation-specific control tokens.
Table 7.8: Burst-aware and single-beat-aware SDFG transformations Original SDFG Burst-aware SDFG Single-beat-aware SDFG b EMERG STOP (1)
s MCU STATUS (5) VCU CMDS (11)
SENS2VOT0 (6) SENS2VOT1 (11)
SENS2VOT (17) s I SENS MON (11)
s T SENS (12)
SENS2sCLB0 (11)
SENS2sCLB1 (12) SENS2sCLB (23) s FOC SENS sc (5)
b POS SENS CLB (5) fCLB2MON (10) fCLB2MON (10)
implementation of SDFGs in Sect.6.5). The generated C code is cross-compiled using theHitex compiler(v4.6.2.0 [Hitex Inc., 2013]) and can be executed on the Tricore 1.6P processors.
In this step, each SDF actor’s C code generated from Simulink and cross-compiled for the platform should be statically analyzed to obtain its BCET/WCET when executed on the single processors of type TC1.6P. The same analysis should be performed for the communication drivers of the plat-form that are used to establish the FIFO-style message passing communica-tion between actors. Yet, available commercial WCET analyzers (such as aiT [Ferdinand and Heckmann, 2004]) still do not support the RT analysis of the SW components on novel processors in novel platforms such as the Aurix (up to the date the experiments were made). Due to this fact, we used (minimal/-maximal) execution times measured when running our software components on an accurate virtual-hardware platform model of the Aurix (see Sect. 7.4.6).
Thereby the virtual platform enables early flexible and accurate measurements of the system timings without having the hardware available. These execution times are then passed over and annotated in the formal MoP representation and used to configure the TA templates of our analysis framework from (see Sect.7.4.7) in order to validate the SUA against its real-time requirements.
With the above decision made, care should be taken when considering the results achieved via our formal analysis, since these are no longer valid upper bounds on the application execution time, as they depend on measured timings instead of WCET timings. But since the annotated timings in the formal MoP of SDF2TA (see Sect.6.4) are the worst-case measured timings bounds, our claim stating that“the measured WCET times should always be below the ones computed by our SDF2TA tool” still holds, and will be shown in the following section.
Host PC
Matlab WorkSpace
Simulink Model TC1.6P
TC27x VP
Sensor1 = *(REG32 sensorAddress);
Sensor2 = …
SensorActor.c
EnvironmentInterface PM
sensorAddress actuatorAddress
startMatlab syncMatlab closeMatlab
Intercept function call(s)
Sensor(s) Actuator (s)
Cross Compilation
SPB
IRQ
Pause/
Continue
startMatlab
closeMatlab syncMatlab
Engine.h
Figure 7.12: VPIL simulation setup for Aurix platform (based on [Poppen, F. and Gr ¨uttner, K., 2012])