Leandro Soares Indrusiak Wormhole Networks-on-Chip PE PE PE Router R R R Core PE PE PE R R R PE PE PE Link R R R 44 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip PE PE PE R R R PE PE PE R R R PE PE PE Link R R R 45 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip arbitration PE PE PE R R R data out data in PE PE PE routing routing data out data in & & transmission transmission data out data in control control R R R data out data in PE PE PE data in data out R R R 46 Real-Time Systems Group
Leandro Soares Indrusiak NoC parallelism and scalability CPU I/O CPU CPU Multiple connections simultaneously RAM CPU CPU CPU 47 Real-Time Systems Group
Leandro Soares Indrusiak NoC performance CPU I/O CPU CPU link contention task contention leads to latency leads to latency variability variability RAM CPU CPU CPU 48 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip 49 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 50 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 51 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 52 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 53 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 54 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip packet is blocked R R R R R R Packet Header Packet Data PE PE 55 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 56 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 57 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header new packet Packet Data PE PE released 58 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 59 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 60 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 61 Real-Time Systems Group
Leandro Soares Indrusiak Wormhole Networks-on-Chip R R R R R R Packet Header Packet Data PE PE 62 Real-Time Systems Group
Leandro Soares Indrusiak 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 63 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels PE PE PE highest priority highest priority priority ID with remaining credit with remaining credit R R R PE PE PE data_out data_in … … routing routing R R R credit_out credit_in & & transmission transmission PE PE PE control control R R R … … 64 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 65 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 66 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header high priority Packet Data PE PE packet released 67 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 68 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 69 Real-Time Systems Group
Leandro Soares Indrusiak first packet is Priority preemptive virtual channels preempted R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 70 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 71 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 72 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 73 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 74 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 75 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 76 Real-Time Systems Group
Leandro Soares Indrusiak Priority preemptive virtual channels R R R wormhole NoC with priority preemptive virtual channels R R R Packet Header Packet Data PE PE 77 Real-Time Systems Group
Leandro Soares Indrusiak 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.) 78 Real-Time Systems Group
Leandro Soares Indrusiak 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.) 79 Real-Time Systems Group
Leandro Soares Indrusiak End-to-End Response Time Analysis (E2ERTA) 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. 80 Real-Time Systems Group
Leandro Soares Indrusiak End-to-End Response Time Analysis (E2ERTA) period (T) = deadline (D) response time response time of the task of the task computation 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. 81 Real-Time Systems Group
Leandro Soares Indrusiak End-to-End Response Time Analysis (E2ERTA) 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 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. 82 Real-Time Systems Group
Leandro Soares Indrusiak 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 83 Real-Time Systems Group
Leandro Soares Indrusiak End-to-End Response Time Analysis (E2ERTA) recurrence relationships can be solved iteratively until convergence require safe initial value 84 Real-Time Systems Group
Leandro Soares Indrusiak End-to-End Response Time Analysis (E2ERTA) must identify interference sets, i.e. which tasks Task j (or flows Flow j ) can preempt a given task Task i (or flow Flow i ) 85 Real-Time Systems Group
Leandro Soares Indrusiak 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. 86 Real-Time Systems Group
Leandro Soares Indrusiak Outline Wormhole Networks Networks-on-Chip Real-Time Analysis Mixed-Criticality Analysis 87 Real-Time Systems Group
Leandro Soares Indrusiak Outline Wormhole Networks Networks-on-Chip Real-Time Analysis Mixed-Criticality Analysis rant time!! 88 Real-Time Systems Group
Leandro Soares Indrusiak Outline Wormhole Networks Networks-on-Chip Real-Time Analysis Mixed-Criticality Analysis 89 Real-Time Systems Group
Leandro Soares Indrusiak 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 90 Real-Time Systems Group
Leandro Soares Indrusiak Mixed-criticality packet communication in NoCs Possible sources of uncertainty packet length R R R packet flow period C C C R R R All packet flows must be schedulable under normal mode C C C R R R Runtime monitoring detects when C C C packets go “beyond normal” e.g. packets longer than expected, or network interface injected more often than expected in normal mode 91 Real-Time Systems Group
Leandro Soares Indrusiak Mixed-criticality packet communication in NoCs Runtime monitoring detects when packets go “beyond R R R normal” C C C R R R if it is a LO-CRIT packet exceeding its C C C normal budget, reject it R R R if it is a HI-CRIT packet exceeding its normal budget, signal a mode change C C C to the NoC, aiming to notify that a service degradation to LO-CRIT mode change packets is needed so that HI-CRIT notification packets can still be scheduled despite of potential increase of interference due to overbudget packets 92 Real-Time Systems Group
Leandro Soares Indrusiak Mixed-criticality packet communication in NoCs Two mode change R R R propagation protocols C C C R R R WPMC: mode change flag “piggybacked” on packets C C C that pass through a router R R R that has changed mode C C C WPMC-FLOOD: mode change is flooded to the entire NoC A. Burns, J. Harbin, L. S. Indrusiak: A Wormhole NoC Protocol for Mixed Criticality Systems. RTSS 2014: 184-195 93 Real-Time Systems Group
Leandro Soares Indrusiak Mixed-criticality packet communication in NoCs Two mode change R R R propagation protocols C C C R R R WPMC: mode change flag “piggybacked” on packets that C C C pass through a router that has R R R changed mode C C C WPMC-FLOOD: mode change is flooded to the entire NoC L. S. Indrusiak, J. Harbin, A. Burns: Average and Worst-Case Latency Improvements in Mixed-Criticality Wormhole Networks-on-Chip. ECRTS 2015. 94 Real-Time Systems Group
Leandro Soares Indrusiak Mixed-criticality packet communication in NoCs Two HI-CRIT mode R R R arbitration schemes C C C routers that change mode R R R ignore arbitration requests of C C C LO-CRIT packets R R R C C C routers that change mode arbitrate links in criticality order (HI-CRIT then LO-CRIT), and in priority order within the same criticality A. Burns, J. Harbin, L. S. Indrusiak: A Wormhole NoC Protocol for Mixed Criticality Systems. RTSS 2014: 184-195 95 Real-Time Systems Group
Leandro Soares Indrusiak Mixed-criticality packet communication in NoCs Two HI-CRIT mode R R R arbitration schemes C C C routers that change mode R R R ignore arbitration requests of C C C LO-CRIT packets R R R C C C routers that change mode arbitrate links in criticality order (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. 96 Real-Time Systems Group
Leandro Soares Indrusiak 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. 97 Real-Time Systems Group
Leandro Soares Indrusiak 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. 98 Real-Time Systems Group
Leandro Soares Indrusiak 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. 99 Real-Time Systems Group
Leandro Soares Indrusiak 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? 100 Real-Time Systems Group
Recommend
More recommend
