What Does Sports and NoC Have in Common?

As an Oakland Raider season ticket holder I attend as many Raider home games as possible. If you have ever attended a live sporting event at a large stadium, and you travelled by car, you are probably familiar with the traffic problems that occur at the end of the game when everyone wants to leave the stadium parking lot at the same time. At most venues you will find law enforcement on hand to control the traffic. On the surface, it seems their role is to help traffic merge more efficiently since there are typically many lanes funneling down to fewer lanes over multiple stages to get through to the exit and/or onto a major highway. You should also understand that they are there to give higher priority to certain vehicles. Police and emergency vehicles have higher priority, followed by perhaps limos and busses, and then the low priority traffic (me in my car). This situation actually looks a lot like the traffic problems in a modern SoC.

As design content increases we find that the data moving about our designs is traveling relatively longer distances and is competing with other traffic in the system. To manage this, buffers and arbitrators are inserted along the way. The most obvious merge pattern occurs on the path to request data from memory, typically off-chip DRAM. In modern SoC this traffic flow is managed by the Network on Chip (NoC) IP. As the traffic cop, the NoC’s responsibility is to make sure each priority of message is handled properly. Making sure that all requests are handled on time is called managing the Quality of Service (QoS). Not all NoC implementations do this in the same way though. It is important to understand the differences when selecting a NoC.

Many NoC architectures (e.g., ARM, Arteris) use a mechanism where the initiator of a message sets the message’s priority (Initiator Based QoS). Simply put, the traffic cop believes the priority you tell him you have and sends you through accordingly without regard to what is happening downstream. If he has no higher priority traffic, he simply sends all of the cars straight through. The problem is that this traffic cop doesn’t have a radio. The flood of traffic he is sending forward may completely fill the lanes at the next intersection and no one is telling him about it. So, higher priority traffic coming from another direction will now not be able to get through the next intersection because it is full, full of lower priority traffic which is blocking the way. The solution: Use the police radio!

In addition to Initiator Based QoS, Sonic’s has NoC IP that also supports Target based QoS. In this approach, the decisions on handling priorities are made closer to the target (or endpoint) of the path. Arbitration decisions are made with knowledge of all of the traffic headed to the target. In short, the traffic cops are talking to each other over the radio (i.e. the system will not select an arbiter that cannot make forward progress). The resulting decisions then can minimize latency and improve memory efficiency. This allows dynamic allocation of the network bandwidth. This plays hand-in-hand with other mechanisms employed by Sonics including virtual channels (aka threads), non-blocking flow control, and other configuration parameters. Click the image below to see a more detailed description.

I am glad the Oakland Police Department uses their radios. It helps me exit the area quickly without impacting ambulances or other higher priority traffic. Apparently, Sonics can do the same for SoC designs as well. For more details, check out SonicsSX® and SonicGN®.