On-time Network On-Chip: Analysis and ArchitectureCS252 Project PresentationDai Bui

IntroductionThe 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

MotivationsCyber Physical Systems(Example from Hermann Kopetz at TU Vienna)

Need for separate flows instead of networks

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

SoCBUSFrom 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

ÆtherealFrom 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

IdeaExploit

Admission control Real-time packet scheduling Run-time configuration Spatial diversity

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

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

MiscellaneousWhen 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

Heterogeneous CommunicationBest-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

Router StructureLooks 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.

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

End-to-end DelayThe 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.

Utilization ConstraintUtilization 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

Buffer bound for each flowEach 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

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

Example 1 Results Implemented

in SystemC based loosely on Noxim

Graph for Flow 2: PE6-> PE3

Max Packet Length 3

Min Interval 8

Example 1ResultsFlow 1: PE7-

>PE23 Max Packet

Length: 4 Min

interval: 9

Flow 3: PE5->PE19 Max Packet

Length: 5 Min

Interval 7

Buffer size

Example 2 - Three flows on one linkPacket Scheduling without the step 2

ComparisonExperiments

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

Future WorkFind 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