1. On-time Network On-chip
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
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
Pre-empt long packets

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.
Make use of virtual channels when not reserved

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
End to end delay routing
Utilization routing

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 Flow 3: PE5- >PE19
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 -
- Worst-case delay for OTNoC is computed analytically instead of empirically

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