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-gt 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 -gt 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-gt PE23
• Flow 2 PE6-gt PE3
• Flow 3 PE5-gt 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-gtPE8, the link can not afford 3 flows
  due to utilization of it will be greater than 1
• Link from PE7-gtPe12 is then selected

18
Example 1 Results

• Implemented in SystemC based loosely on Noxim
• Graph for Flow 2 PE6-gt PE3
• Max Packet Length 3
• Min Interval 8

19
Example 1Results

• Flow 1 PE7-gtPE23
• Max Packet Length 4
• Min interval 9
• Flow 3 PE5-gtPE19
• 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