2.7 Summary
3.1.1 Media Sharing with Local ID Management
Fig. 3.1 presents an example of the flexible communication media sharing by using the local ID-tag organization and management. The local ID-tag reconfiguration and man-agement in the XHiNoC are made autonomously by packet headers at runtime during application execution time. The figure shows one example of many possible local ID slot configurations and shows a small 2D 3×2 mesh NoC topology (6 NoC routers i.e. Rk, where k ∈ {1,2,3,4,5,6}). Seven messages, i.e. message A, B, C, D, E, F and G are routed in the networks and share the communication resources. MessageB for instance is injected from router nodeR4 with local ID-tag1and is accepted or ejected in the router nodeR3 with local ID-tag0. On the next remaining intermediate downstream links, the messageBreserves local ID-tag1and0, successively, until it reaches its destination node (R3). During transmission in the intermediate links, the local ID-tag of each message is updated and mapped properly to allow resource communication sharing with other flits of different messages in interleaving manner. For example, in the link connecting East port ofR4 and West port of R5, the local ID-tag of the message B is 2. While the others messages, i.e. messageAand messageDreserve local ID-tag0and local ID-tag1 respec-tively. Thus, three messages share the link with three different local ID tags. There is no restriction such that every message must be allocated to a certain local ID slot. The local ID slot reservation made by every message depends on the current status of the local ID slots, they are free or have been reserved by other messages.
In order to support such flexible method to share the communication media, a policy must be applied to guarantee correct routing path and proper flits forwarding of each message. A few rule that must implemented in the proposed methodology is explained in the following.
1. Flits belonging to the same message or data stream will always have the same lo-cal ID-tag. In oder words, different flits belonging to different message will have different local ID-tags on every local communication link.
2. The ID-tag of each message will be updated each time it enters a new communica-tion resource (link). Two parameters, i.e. previous ID-tag in the previous link and input port number from which a message comes can be used to index a reserved local ID tag.
3. A local ID-tag that has been reserved by a message cannot be used by other mes-sages until the message has terminated the reservation of the local ID-tag.
00 11
000000 000000 111111 111111
0000 1111
0000 00 1111
11 000000
111111
000000 111111
0000 0000 1111 1111
1
2 0
R2
0
R5
E W
W
S S N
N
L L
0 0
1 0 2 Msg.D Msg.E
Msg.D 0
Msg.E
Msg.G
Msg.G 1
0
E
2 0
1 2
210 0
0
0
0
0 0
0 0
0 0
1
1
0 BA
C D
E
F G
A F
G C
R1
R4 R5 R6
B 0
E 0 0 2 1
R2 R3
D 0
id E
M 0 1 2 3
on R2 North port L W N
1 S
E G D Msg.
1 1
Routing Rervation Table Msg.
D G E
id west north local
id old
1
0 1
0 0 from port new
2 M at South port ID slot table on R5
Fig. 3.1: Flexible concept view of the communication media share with local ID-tag management.
Based on the policy and rules to implement the proposed flexible communication me-dia share methodology, few implementation consequence must be fulfilled to support the concept. Firstly, the need for a specific packet format to transport message through the network, and secondly, the need for local ID slots, which must be implemented over all local communication link, where a message allocated to a local ID slotkon a current link will use the slotkas its ID-tag on the link.
Fig.3.2(a)presents the generic specific packet format of the XHiNoC. A message or a streaming data is divided intoflow control digitscalledflit. The definitions of the flits are described in Def.3.1, Def.3.2and Def.3.3, respectively. The total bit-width of each flit of the message or streaming data isbtotal =btype+btag +bword, wherebtypeis the bit-width of the flit type field, btag is the bit-width of the id-tag field and bword is the bit width of the data word.
Unicast message/stream is single packet that consists of one header flit, databody flits, and one tail flit, while a multicast message/stream consists of more than one header flits, where the number of header flits depends on (equals to) the number of the multicast destination nodes. Even if the size of the message/stream is extremely large, it has only one tail flit. In other words, a message or data stream is assembled in a single packet.
Definition 3.1 (Data Flit) A data flit (flow control digit) coming from input port n is repre-sented as Fn(type, ID). It consists of a data word with additional flit type field (type) and local ID-tag field. Each flit will always bring a data word together with its type and its local (See Fig.3.2(a)).
3.1 DESIGNCONCEPT 53 Definition 3.2 (Flit type) The typefield represents the type of each flit. The flit typecan be a header, a databody or a tail flit (type∈εtype|εtype={header, databody, tail, response}).
Based on the Def. 3.2, the types of flits can be identified into four types that are de-scribed in the following.
• Headerflit is a flit that is attached in the probe of a message. As the leading flit, the address of the destination node is written on the bit-field of the flit. The header flit initiates the ID slot reservation including routing table slot reservation and ID tag updating function. The header flit is used basically to establish routing path or to configure connection.
• Databodyflit is identified as the payload data of a message/stream. Hence, the sub-stantial word of the message is injected into the NoC as databody flits.
• Tailflit is used to mark the end of a message/stream. The tail flit can bring a sub-stantial word of the message or a special information or non-substantive word. The tail flit is basically used to close the routing path or to terminate the connection.
• Response flit is used when a connection-oriented guaranteed-service communica-tion protocol is implemented in the NoC router, where the response flit is sent by a destination node to inform the source node about the status of the connection, i.e.
successful or fail. When a best-effort data communication protocol is implemented, the response flit is used to initiate data retransmission when data drop mechanism is allowed, because one free ID tag in the acquired link cannot be allocated for the message, since all available ID slots have been reserved by other messages (runout of ID slots).
Definition 3.3 (Flit ID-tag) ID-tag field present on each flit is a local label (ID-tag) to indicate and differentiate the flit from different flits. Flits belonging to the same message or streaming data will always have the same local ID-tag on each communication linkLi,j ∈Λ. The value of the local ID-tag is defined as ID ∈ Γ|Γ = {0,1,2,· · · , Nslot−1}whereNslot is number of available ID slot on communication linkLi,j ∈Λ. See also later the definition of the local ID slot in Def.3.4.
Definition 3.4 (Local ID Slots) Each communication linkLi,j ∈ Λ hasNslotnumber of avail-able local ID slots, which is defined as a set Ωi,j j Γ (See Def. 3.3). If an assumption is made such that all communication links has the same number of available ID slots, then we will have Ωi,j jΩ. We define a single local ID slotk ∈Ω, wherek = Nslot−1is reserved for packet flow control purpose, and the usable ID slots are∀k ∈Ω∩k6=Nslot−1.
Fig.3.2(b)presents the concept view of a communication linkLi,j of the XHiNoC con-necting routerRiandRj. A flit flowing through the linkLi,j is exhibited asFij(type, ID).
Based on Def.3.3and Def. 3.4, a message allocated to an ID slotk ∈ Ωwill then use the slot number k as its local ID-tag (ID = k). Fig. 3.2(b) give us insight that the flows of message flits on the linkLi,j is controlled by configuring the ID slot table at the output port of the routerRi and the routing reservation table at the input port of the routerRj.
... ... ...
DBod DBod
ID−tag ID−tag
Resp Tail ID−tag
Head ID−tag Source Addr.
’1111’
Payload Data
Source Addr.
Extension
Extension Extension
Address field
Type ID field Extension field
Payload Data Dest. Addr.
Dest. Addr.
Dataword Control bits
(a) Generic Packet Format
Nslot−2
slot−1 N Nslot−2
slot−1 N
Fn (type,Id) Fn (type,Id)
2
1 1
2
R Rj
Li,j
ID−tag Routing 0 1 2
type,Id Inport New ID
0 1 2 old ID
ID Slot In
Local ID slots
Ωk,i Ωi,j Ωi,j D
Routing Resrv. Table, T Table, S
i
Om Fi,j( In
In
Noutp Noutp
−1 Ninp
inp−1
N )
(b) ID slots of Local Link
Fig. 3.2: The specific packet format and local ID slots.