On-time Network On-Chip: Analysis and Architecture

1. On-time Network On-Chip: Analysis and Architecture CS252 Project Presentation Dai Bui

2. Introduction The project aims at providing predictable timing delay for network on chip communication paradigm Purpose is not only to improve network speed Packet worst-case delay should be estimated analytically instead of empirically

3. Motivations Cyber Physical Systems (Example from Hermann Kopetz at TU Vienna) Need for separate flows instead of networks

4. QNoC • From Technion • Asynchronous communication • Support multiple service levels: • Seems to be suitable for soft real-time applications like video streaming • But what happens when multiple real-time flows have to share the same link? • Non deterministic behaviors for flows • So we need to keep track of the number of guaranteed flows and its demand on on each link

5. SoCBUS • From University of Linkoping • Guarantee real-time properties by setting up a path when sending: • Initiate a path by sending a setting up packet • The path will be locked until all data have been sent • After that the path is unlocked • Drawbacks: • What happens if we have two real-time flows on the same link? • Other traffic is blocked. This seems to be a good solution when sending a large bulk of data but not good for a periodic, non-continuous flows • Bad link utilization due to link locking

6. Æthereal • From NXP • Try to employ the conflict free routing-> no packet is dropped • Avoid conflict between two packets on the same link by delaying one packet • Drawback: • Global scheduling of packets  inflexible, difficult to scale • Partial design-time scheduling -> not suitable for multi-core

7. Idea • Exploit • Admission control • Real-time packet scheduling • Run-time configuration • Spatial diversity

8. Design Goals Multiple real-time flows can be multiplexed on one link Utilize the spatial data paths between sources and nodes to avoid the conflicts between real-time flows Does not block links completely as SoCBUS, best-effort flows still can travel links used by real-time flows Avoid unpredicted behaviors networks as in QNoC, when there are multiple real-time flows suddenly travelling on the same link and their total bandwidth exceeds the bandwidth of the link. The admission control in our architecture can prevent that. Senders should always know if their required specifications for their communications can be met or not Provide a reconfigurable state for real-time flows on a network, we do not need to pre-calculate that at design time as in Æthereal, which is really not suitable for the multi-core architecture Verifiable for critical systems

9. Path Setup Protocol • Sender initiates a new real-time flow by sending its REQUEST to the master node with its specifications about the new flow: end-to-end delay, max packet length, minimum interval between packets, … • The master node computes the delay constraints and specifications of the new flow against its knowledge about previously reserved flows • If it can not find a path, it send back to the requested node a REJECT • If there is any possible path, it sends SETUP command to routers on the path to reconfigure the routers (possibly modify configurations for other flows as well) • It waits for all routers to receive this command and ACKs from these routers • It sends back to the requested node an ACCEPT

10. Miscellaneous When a real-time flow is not needed, its path can be torn. Path tear-up protocol is almost the same as path setup protocol but with reversed commands. Each real-time flow is uniquely identified by a flow ID, this is embedded in each real-time packet so that routers on the path can identified the packets Master node interacts with other routers about flows using this ID

11. Heterogeneous Communication Best-effort packets are preemptible by real-time packets. Real-time packets are not preemptible No acknowledgement for real-time flits since the scheduling mechanism will make sure that the buffer size for real-time flows is bounded (based on specifications) Double the speed of a packet since no ACK mechanism is needed

12. Router Structure Looks the same as virtual channels routers When a packet is identified by the flow ID, the router will put it in a designated FIFO queue. The previously reserved information of a flow will tell the router which port packets of a flow will be forwarded to.

13. Delay Model and Fixed Priority Scheduler • Delay bound of a packet of flow f on out going edge e of a node is defined as the total of the queueing time at that node plus the propagation time for the head flit of a packet to reach next node • Fixed Priority Scheduler: • Step 1: Mature packets are scheduled first. Packets of flows with highest priority are selected to forwarded first. • Step 2(optional): Immature packets can be forwarded if there is no mature packets. • Queueing delay by fixed-priority scheduler • Where Oe(g) is the order function (to compare priority) of flows on edge e. There is no notion of global priority • Details of the proof is in the report

14. End-to-end Delay • The end-to-end delay has to be larger than the total delay at each edge on the path • Assume that because it takes one cycle to transmit a flit in a NoC.

15. Utilization Constraint • Utilization of each link when shared by multiple flows must not greater than 1 • Where tf is the minimum interval between two successive packets of flow f

16. Buffer bound for each flow Each flow has a buffer bound at each node: With some constrains, the sufficient buffer size will be smaller than 2 packet-size. In some cases, buffer size is just 1 packet size

17. Routing • Always deadlock-free • Test example • Three flows • Flow 1: PE7-> PE23 • Flow 2: PE6-> PE3 • Flow 3: PE5-> PE19 • Exhaustive depth first search • Routing example • Routing algorithm is based on XY routing • Flow 3 comes last (the request packet reach the master node last • When the routing algorithm for it reach the link from PE7->PE8, the link can not afford 3 flows due to utilization of it will be greater than 1 • Link from PE7->Pe12 is then selected

18. Example 1 Results • Implemented in SystemC based loosely on Noxim • Graph for Flow 2: PE6-> PE3 • Max Packet Length 3 • Min Interval 8

19. Example 1Results • Flow 1: PE7->PE23 • Max Packet Length: 4 • Min interval: 9 • Flow 3: PE5->PE19 • Max Packet Length: 5 • Min Interval 7

20. Buffer size

21. Example 2 - Three flows on one link Packet Scheduling without the step 2

22. Comparison • Experiments • The same total input buffer size of 10 flits for all protocols • Packet size = 5 flits • For real-time NoC, we restrict two real-time flows per link and exploit spatial diversity of paths in NoC

23. Future Work • Find a better optimization for delays and path in network • Integrate with real-time processors like PRET to form a real-time multi-core processor • Understand how it can support the Byzantine Generals problem for fault-tolerance • Suitable for PTIDES • No packet reordering • Bounded communication delay