Real-Time Mixed-Criticality Wormhole Networks Leandro Soares - - PowerPoint PPT Presentation

real time mixed criticality wormhole networks
SMART_READER_LITE
LIVE PREVIEW

Real-Time Mixed-Criticality Wormhole Networks Leandro Soares - - PowerPoint PPT Presentation

Leandro Soares Indrusiak Real-Time Mixed-Criticality Wormhole Networks Leandro Soares Indrusiak Real-Time Systems Group Department of Computer Science University of York United Kingdom 1 Real-Time Systems Group Leandro Soares Indrusiak


slide-1
SLIDE 1

1 Leandro Soares Indrusiak Real-Time Systems Group

Real-Time Mixed-Criticality Wormhole Networks

Leandro Soares Indrusiak

Real-Time Systems Group Department of Computer Science University of York United Kingdom

slide-2
SLIDE 2

2 Leandro Soares Indrusiak Real-Time Systems Group

Outline

  • Wormhole Networks
  • Networks-on-Chip
  • Real-Time Analysis
  • Mixed-Criticality Analysis
slide-3
SLIDE 3

3 Leandro Soares Indrusiak Real-Time Systems Group

Motivation

  • Multiprocessor and multicore systems

forced a shift towards communication- centric design

abundant computation resources shared communication media

  • Inter-processor communication

point-to-point bus networks

source: IBM, Intel

slide-4
SLIDE 4

4 Leandro Soares Indrusiak Real-Time Systems Group

Networks – key characteristics

  • topology

mesh, star, torus…

  • routing protocol

deterministic, adaptive…

  • arbitration

round-robin, priority preemptive, priority non- preemptive, TDM…

  • buffering

FIFO, SAFC, SAMQ, DAMQ, hot potato…

  • flow control protocol

handshake, credit-based…

  • switching protocol

circuit, store-and-forward, wormhole

slide-5
SLIDE 5

5 Leandro Soares Indrusiak Real-Time Systems Group

Networks – key characteristics

  • topology

mesh, star, torus…

  • routing protocol

deterministic, adaptive…

  • arbitration

round-robin, priority preemptive, priority non- preemptive, TDM…

  • buffering

FIFO, SAFC, SAMQ, DAMQ, hot potato…

  • flow control protocol

handshake, credit-based…

  • switching protocol

circuit, store-and-forward, wormhole

slide-6
SLIDE 6

6 Leandro Soares Indrusiak Real-Time Systems Group

Circuit Switching

Terminal

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

slide-7
SLIDE 7

7 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-8
SLIDE 8

8 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-9
SLIDE 9

9 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-10
SLIDE 10

10 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-11
SLIDE 11

11 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-12
SLIDE 12

12 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-13
SLIDE 13

13 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-14
SLIDE 14

14 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-15
SLIDE 15

15 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-16
SLIDE 16

16 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-17
SLIDE 17

17 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-18
SLIDE 18

18 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-19
SLIDE 19

19 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

A segment of reserved path is idle for a significant period

  • f time.

Circuit Switching

Terminal Terminal

Packet Header Packet Data

slide-20
SLIDE 20

20 Leandro Soares Indrusiak Real-Time Systems Group

Circuit switching

  • Packets are forwarded through dedicated paths that are

kept until the transmission is finished

  • Contention can arise when establishing a path

 no further contention once path is established

  • Temporary packet buffering in routers is not required
  • Suitable to long and infrequent messages

 time to establish a path can be high

slide-21
SLIDE 21

21 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-22
SLIDE 22

22 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-23
SLIDE 23

23 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-24
SLIDE 24

24 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-25
SLIDE 25

25 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-26
SLIDE 26

26 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-27
SLIDE 27

27 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-28
SLIDE 28

28 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-29
SLIDE 29

29 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-30
SLIDE 30

30 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-31
SLIDE 31

31 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-32
SLIDE 32

32 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-33
SLIDE 33

33 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

SAF Switching

slide-34
SLIDE 34

34 Leandro Soares Indrusiak Real-Time Systems Group

SAF Switching

  • SAF - Store And Forward
  • Routers can only forward a packet once it is completely

received and stored

 packet acquires one link at a time

  • Router input ports must have enough buffering space to

temporarily store a complete packet

slide-35
SLIDE 35

35 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Switching

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

slide-36
SLIDE 36

36 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Switching

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

slide-37
SLIDE 37

37 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Switching

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

slide-38
SLIDE 38

38 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Switching

Switch Switch Switch Switch Switch Switch

Terminal

Packet Header Packet Data

slide-39
SLIDE 39

39 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Wormhole Switching

Terminal

Packet Header Packet Data

slide-40
SLIDE 40

40 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Wormhole Switching

Terminal

Packet Header Packet Data

slide-41
SLIDE 41

41 Leandro Soares Indrusiak Real-Time Systems Group

Switch Switch Switch Switch Switch Switch

Wormhole Switching

Terminal

Packet Header Packet Data

slide-42
SLIDE 42

42 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole switching

  • Packet is routed and forwarded as soon the header flit has

arrived

 payload flits follow header

  • Input ports does not need to buffer a complete packet

flits of a packet can be stored across multiple routers

  • Trade-off between buffer overheads and network contention
slide-43
SLIDE 43

43 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Networks-on-Chip

  • Small buffering overheads
  • f wormhole networks was

particularly attractive to a special class of resource- constrained networks: Networks-on-Chip (NoCs)

small buffers mean smaller area and lower energy dissipation

PE PE PE PE PE PE PE PE R PE R R R R R R R R

slide-44
SLIDE 44

44 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Networks-on-Chip

PE PE PE PE PE PE PE PE R PE R R R R R R R R

Core Router Link

slide-45
SLIDE 45

45 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Networks-on-Chip

PE PE PE PE PE PE PE PE R PE R R R R R R R R

Link

slide-46
SLIDE 46

46 Leandro Soares Indrusiak Real-Time Systems Group

arbitration routing & transmission control routing & transmission control

data out data in data out data in data out data in data out data in data out data in

PE PE PE PE PE PE PE PE R PE R R R R R R R R

Wormhole Networks-on-Chip

slide-47
SLIDE 47

47 Leandro Soares Indrusiak Real-Time Systems Group

NoC parallelism and scalability

CPU CPU CPU CPU RAM CPU I/O CPU

Multiple connections simultaneously

slide-48
SLIDE 48

48 Leandro Soares Indrusiak Real-Time Systems Group

NoC performance

link contention leads to latency variability

CPU CPU CPU CPU RAM CPU I/O CPU

task contention leads to latency variability

slide-49
SLIDE 49

49 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Networks-on-Chip

slide-50
SLIDE 50

50 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-51
SLIDE 51

51 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-52
SLIDE 52

52 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-53
SLIDE 53

53 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-54
SLIDE 54

54 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-55
SLIDE 55

55 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

packet is blocked Packet Header Packet Data

PE

slide-56
SLIDE 56

56 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-57
SLIDE 57

57 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-58
SLIDE 58

58 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

new packet released Packet Header Packet Data

PE

slide-59
SLIDE 59

59 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-60
SLIDE 60

60 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-61
SLIDE 61

61 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-62
SLIDE 62

62 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Wormhole Networks-on-Chip

PE

Packet Header Packet Data

PE

slide-63
SLIDE 63

63 Leandro Soares Indrusiak Real-Time Systems Group

Wormhole Networks-on-Chip

  • Packets can acquire multiple links, making

it hard to predict worst-case latency due to complex contention patterns

  • Alternative: wormhole NoCs using virtual

channels with priority preemptive arbitration

slide-64
SLIDE 64

64 Leandro Soares Indrusiak Real-Time Systems Group

Priority preemptive virtual channels

highest priority with remaining credit data_in credit_out data_out credit_in

routing & transmission control priority ID

highest priority with remaining credit

routing & transmission control

PE PE PE PE PE PE PE PE R PE R R R R R R R R

slide-65
SLIDE 65

65 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-66
SLIDE 66

66 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-67
SLIDE 67

67 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

high priority packet released

slide-68
SLIDE 68

68 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-69
SLIDE 69

69 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-70
SLIDE 70

70 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

first packet is preempted

slide-71
SLIDE 71

71 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-72
SLIDE 72

72 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-73
SLIDE 73

73 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-74
SLIDE 74

74 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-75
SLIDE 75

75 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-76
SLIDE 76

76 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-77
SLIDE 77

77 Leandro Soares Indrusiak Real-Time Systems Group

R R R R R R

Priority preemptive virtual channels

PE

wormhole NoC with priority preemptive virtual channels

Packet Header Packet Data

PE

slide-78
SLIDE 78

78 Leandro Soares Indrusiak Real-Time Systems Group

Performance evaluation

  • How to estimate performance figures for a particular

application mapped to a Network-on-Chip?

 full system prototyping

  • cores + NoC in FPGA, running OS + application
  • extremely costly setup time, can only explore few design alternatives

 accurate system simulation

  • cycle-accurate model of cores + NoC, running OS + application
  • extremely long simulation time, can only explore few design alternatives

 approximately-timed system simulation

  • approximately-timed model of cores + NoC, executing an abstract model of

the OS + application

 analytical system performance models

  • average or worst-case latency estimation for restricted application styles

(periodic independent tasks, synchronous dataflow, etc.)

slide-79
SLIDE 79

79 Leandro Soares Indrusiak Real-Time Systems Group

Performance evaluation

  • How to estimate performance figures for a particular

application mapped to a Network-on-Chip?

 full system prototyping

  • cores + NoC in FPGA, running OS + application
  • extremely costly setup time, can only explore few design alternatives

 accurate system simulation

  • cycle-accurate model of cores + NoC, running OS + application
  • extremely long simulation time, can only explore few design alternatives

 approximately-timed system simulation

  • approximately-timed model of cores + NoC, executing an abstract model of

the OS + application

 analytical system performance models

  • average or worst-case latency estimation for restricted application styles

(periodic independent tasks, synchronous dataflow, etc.)

slide-80
SLIDE 80

80 Leandro Soares Indrusiak Real-Time Systems Group

  • The worst-case end-to-end response time of a task is the longest

time consumed between its release and the moment when the last packet it transmits arrives at the destination core

  • It can be found by a specific composition of:

 worst case response time of tasks based on classical single processor schedulability analysis (Audsley et al., 1993)  worst case latency of traffic flows based on the NoC schedulability analysis (Shi and Burns, 2008)

  • It assumes that:

 the minimum inter-release time of each task (T) and its worst case computation time (C) are known  the source task only starts transmitting packets after it finishes its execution  system uses priority-preemptive arbitration

L.S. Indrusiak, “End-to-End Schedulability Tests for Multiprocessor Embedded Systems based on Networks-on-Chip with Priority-Preemptive Arbitration”, Journal of Systems Architecture, v. 60, n. 7, Aug 2014.

End-to-End Response Time Analysis (E2ERTA)

slide-81
SLIDE 81

81 Leandro Soares Indrusiak Real-Time Systems Group

End-to-End Response Time Analysis (E2ERTA)

period (T) = deadline (D) response time

  • f the task

computation response time

  • f the task

communication

L.S. Indrusiak, “End-to-End Schedulability Tests for Multiprocessor Embedded Systems based on Networks-on-Chip with Priority-Preemptive Arbitration”, Journal of Systems Architecture, v. 60, n. 7, Aug 2014.

slide-82
SLIDE 82

82 Leandro Soares Indrusiak Real-Time Systems Group

End-to-End Response Time Analysis (E2ERTA)

L.S. Indrusiak, “End-to-End Schedulability Tests for Multiprocessor Embedded Systems based on Networks-on-Chip with Priority-Preemptive Arbitration”, Journal of Systems Architecture, v. 60, n. 7, Aug 2014.

  • Deadline (D) = Period of Task (T)
  • End-to-end response time analysis:

 a task is schedulable if  a packet flow is schedulable if

  • Otherwise, system is unschedulable
slide-83
SLIDE 83

83 Leandro Soares Indrusiak Real-Time Systems Group

End-to-End Response Time Analysis (E2ERTA)

precedence relationship must solve task’s response time first, and add it as the release jitter of the flow’s response time calculation

slide-84
SLIDE 84

84 Leandro Soares Indrusiak Real-Time Systems Group

End-to-End Response Time Analysis (E2ERTA)

recurrence relationships can be solved iteratively until convergence require safe initial value

slide-85
SLIDE 85

85 Leandro Soares Indrusiak Real-Time Systems Group

End-to-End Response Time Analysis (E2ERTA)

must identify interference sets, i.e. which tasks Taskj (or flows Flowj) can preempt a given task Taski (or flow Flowi)

slide-86
SLIDE 86

86 Leandro Soares Indrusiak Real-Time Systems Group

End-to-End Response Time Analysis (E2ERTA)

  • Complexity of E2ERTA scales with

size of NoC complexity of application (# tasks and # flows) and of the allocation (amount of resource contention)

  • Performance of E2ERTA is orders of magnitude

faster than the fastest available NoC simulation

  • E2ERTA has been further optimised and

hardware-accelerated

  • Y. Ma and L.S. Indrusiak, “Hardware-accelerated Response Time Analysis for Priority-Preemptive Networks-on-Chip”, in Int Symposium on

Reconfigurable Communication-centric Systems-on-Chip (ReCoSoC), 2015.

slide-87
SLIDE 87

87 Leandro Soares Indrusiak Real-Time Systems Group

Outline

  • Wormhole Networks
  • Networks-on-Chip
  • Real-Time Analysis
  • Mixed-Criticality Analysis
slide-88
SLIDE 88

88 Leandro Soares Indrusiak Real-Time Systems Group

Outline

  • Wormhole Networks
  • Networks-on-Chip
  • Real-Time Analysis
  • Mixed-Criticality Analysis

rant time!!

slide-89
SLIDE 89

89 Leandro Soares Indrusiak Real-Time Systems Group

Outline

  • Wormhole Networks
  • Networks-on-Chip
  • Real-Time Analysis
  • Mixed-Criticality Analysis
slide-90
SLIDE 90

90 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Packet flows of different levels of criticality can share the

NoC infrastructure

 Initial work considers only two levels of criticality, and packet flows are assigned a criticality level at design time: HI-CRIT or LO-CRIT  Packet flows are also assigned fixed priorities at design time

  • HI-CRIT packet flows make more conservative assumptions

about the environment and therefore have more conservative upper bounds for their resource provisions

 however, it is expected that during normal operation mode their resource usage stays within the bounds obtained using less conservative assumptions used for LO-CRIT packets

slide-91
SLIDE 91

91 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Possible sources of uncertainty

 packet length  packet flow period

  • All packet flows must be schedulable

under normal mode

  • Runtime monitoring detects when

packets go “beyond normal”

 e.g. packets longer than expected, or injected more often than expected in normal mode

C R R R R C R R C R R C R C C C C C

network interface

slide-92
SLIDE 92

92 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Runtime monitoring detects

when packets go “beyond normal”

if it is a LO-CRIT packet exceeding its normal budget, reject it if it is a HI-CRIT packet exceeding its normal budget, signal a mode change to the NoC, aiming to notify that a service degradation to LO-CRIT packets is needed so that HI-CRIT packets can still be scheduled despite

  • f potential increase of interference

due to overbudget packets C R R R R C R R C R R C R C C C C C

mode change notification

slide-93
SLIDE 93

93 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Two mode change

propagation protocols

WPMC: mode change flag “piggybacked” on packets that pass through a router that has changed mode WPMC-FLOOD: mode change is flooded to the entire NoC

C R R R R C R R C R R C R C C C C C

  • A. Burns, J. Harbin, L. S. Indrusiak: A Wormhole NoC Protocol for Mixed Criticality Systems. RTSS 2014: 184-195
slide-94
SLIDE 94

94 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Two mode change

propagation protocols

WPMC: mode change flag “piggybacked” on packets that pass through a router that has changed mode WPMC-FLOOD: mode change is flooded to the entire NoC

C R R R R C R R C R R C R C C C C C

  • L. S. Indrusiak, J. Harbin, A. Burns: Average and Worst-Case Latency Improvements in Mixed-Criticality Wormhole Networks-on-Chip. ECRTS 2015.
slide-95
SLIDE 95

95 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Two HI-CRIT mode

arbitration schemes

routers that change mode ignore arbitration requests of LO-CRIT packets routers that change mode arbitrate links in criticality order (HI-CRIT then LO-CRIT), and in priority order within the same criticality

C R R R R C R R C R R C R C C C C C

  • A. Burns, J. Harbin, L. S. Indrusiak: A Wormhole NoC Protocol for Mixed Criticality Systems. RTSS 2014: 184-195
slide-96
SLIDE 96

96 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

C R R R R C R R C R R C R C C C C C

  • Two HI-CRIT mode

arbitration schemes

routers that change mode ignore arbitration requests of LO-CRIT packets routers that change mode arbitrate links in criticality

  • rder (HI-CRIT then LO-CRIT),

and in priority order within the same criticality

  • L. S. Indrusiak, J. Harbin, A. Burns: Average and Worst-Case Latency Improvements in Mixed-Criticality Wormhole Networks-on-Chip. ECRTS 2015.
slide-97
SLIDE 97

97 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Response Time Analysis formulations for

each of the protocols were developed

  • Evaluation with synthetic flowsets (against

no criticality awareness and criticality- monotonic arbitration) and cycle-accurate NoC simulation

 WPMC-FLOOD slightly better in general, significantly better in stress scenarios

  • Less restrictive arbitration allows LO-CRIT

packets to flow when there are no HI-CRIT packets or when they are blocked due to interferences

  • A. Burns, J. Harbin, L. S. Indrusiak: A Wormhole NoC Protocol for Mixed Criticality Systems. RTSS 2014: 184-195
  • L. S. Indrusiak, J. Harbin, A. Burns: Average and Worst-Case Latency Improvements in Mixed-Criticality Wormhole Networks-on-Chip. ECRTS 2015.
slide-98
SLIDE 98

98 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Response Time Analysis formulations for

each of the protocols were developed

  • Evaluation with synthetic flowsets

(against no criticality awareness and criticality-monotonic arbitration) and cycle-accurate NoC simulation

 WPMC-FLOOD slightly better in general, significantly better in stress scenarios

  • Less restrictive arbitration allows LO-CRIT

packets to flow when there are no HI-CRIT packets or when they are blocked due to interferences

  • L. S. Indrusiak, J. Harbin, A. Burns: Average and Worst-Case Latency Improvements in Mixed-Criticality Wormhole Networks-on-Chip. ECRTS 2015.
slide-99
SLIDE 99

99 Leandro Soares Indrusiak Real-Time Systems Group

Mixed-criticality packet communication in NoCs

  • Response Time Analysis formulations for

each of the protocols were developed

  • Evaluation with synthetic flowsets (against

no criticality awareness and criticality- monotonic arbitration) and cycle-accurate NoC simulation

 WPMC-FLOOD slightly better in general, significantly better in stress scenarios

  • Less restrictive arbitration allows LO-

CRIT packets to flow when there are no HI-CRIT packets or when they are blocked due to interferences

  • L. S. Indrusiak, J. Harbin, A. Burns: Average and Worst-Case Latency Improvements in Mixed-Criticality Wormhole Networks-on-Chip. ECRTS 2015.
slide-100
SLIDE 100

100 Leandro Soares Indrusiak Real-Time Systems Group

Open questions

  • How to detect that the network has returned to

normal mode, so LO-CRIT service and guarantees can be restored?

  • Can we give reasonable guarantees in networks

with non-preemptive arbitration?

  • Can we optimise task allocation and packet

routing?

  • Benchmarks?
slide-101
SLIDE 101

101 Leandro Soares Indrusiak Real-Time Systems Group

Real-Time Mixed-Criticality Wormhole Networks

Mixed Criticality Embedded Systems on Many-Core Platforms EPSRC EP/K011626/1 Project

Leandro Soares Indrusiak, with contributions from: Alan Burns, Rob Davis, Iain Bate, James Harbin

www.cs.york.ac.uk/research/research-groups/rts/mcc www.cs.york.ac.uk/rts

MCCps - Mixed Criticality Cyber- Physical Systems EPSRC EP/P003664/1 Project