Speeding Tickets

By Frank Ferro
Speed sells. Bells and whistles are always intriguing and fun to have, but the driver for new products is usually speed. We want to move our phones to the 4G network for faster download speeds, or replace our 802.11g home router with the new 802.11n, we want a PC with a dual-core processor to replace the single-core processor, and the list goes on. Clearly speed is an easy way to get the attention of consumers…and it usually closes the deal.

But is faster always better? In some cases, absolutely. We all remember switching to high-speed cable or DSL from dial-up. After a day of using a high-speed Internet connection there was no turning back. Other times, however, the benefits of increased speed might not be so obvious. In the case of the 802.11n wireless router, one vendor boasts a 12X speed improvement over 802.11g. This speed boost, however, may not offer any advantage to homeowners with DSL or cable since the typical download speed is about 5Mbps (on a good day). The ‘old’ 802.11g router could handle about 10 to 12Mbps of actual throughput, so having 150Mbps data rate available does not help—especially if you’re only doing e-mail and surfing the Web (although, as former WiFi Alliance Board member, I will say the 802.11n router does give much better range.)

So let’s examine speed as it relates to the SoCs that power all of our smart devices. There have been a lot of new processor announcements with speeds ranging from 1GHz to 2GHz with two, three and even four processor cores. There are also new and faster GPUs, DSPs, video processors and so on. Given the availability of these high-speed processors, the question is how can we take advantage of this to improve the end user experience.

I use the word experience, because faster processors may not always translate into a “better” user experience. One of the main design goals of cell phone manufacturers was and still is battery life—longer standby and talk time. But compare the standby time of a voice-only phone (yes, they are still in use with our parents and grandparents!) of more than one week to a smart phone which usually only about one to two days. The same design goal is still battery life, but standby time of smart phones has taken us back to the early days of cell phones with only one to two days. It seems we are more than willing to tradeoff standby time for bells and whistles—more radios (Bluetooth, WiFi, FM) and bigger and better displays, video, audio, VoIP, etc. So clearly running faster helps manage all these features, but it compromises and drains battery life.

So how can the SoC designer take advantage of new processors without having to run at maximum speed, i.e., consuming the most power? How can you find the correct balance of running at the minimum speed, yet still meet the application requirements? The answer is concurrency. Looking at the architecture of most SoCs you will find that access to memory is the common link in the system. Running the CPU or GPU faster while the memory can’t keep up is clearly a waste of speed and power. To solve this problem, designers will “over-provision” the system to ensure that all use cases are met. This design approach may allow you to get the chip out faster, but at the high cost of gate count, which means increased idle and leakage power. It also means more active power because processors will have to “stay awake” longer while waiting for memory.

SoC designers are now realizing that to get the most out of the system they must be cognizant of how all these high-speed cores are connected. QoS has emerged as one method to help manage data streams. This allows certain tasks to have priority of the system resources over other tasks (e.g. the processor over the I/O). But even the best QoS schemes can break down in the presence of heavy traffic. If everyone wants priority, no one truly gets it. To limit this effect, some methods will meter the traffic coming into the network, such as stop lights at the entrance to a highway, while others will limit the number of open transactions. Metering or limiting the traffic can be “unfriendly” at the system level because the application software has to wait, which means you have to wait.

To get true concurrency, what is needed is a system that does not block traffic coming into the network and has the intelligence to create “virtual” paths through the network. Using QoS schemes in combinations with non-blocking flow control will have the benefit of reducing system resources, creating optimal paths for data to seamlessly flow. As mentioned earlier, the memory is usually the main point of contention. With a non-blocking scheme based on “target” flow control or the memory as the point of flow management, much higher efficiency can be achieved because the memory has the most knowledge of the task it is performing. Therefore, it can better multiplex traffic for maximum utilization. In addition, all the other I/O devices are working the same way, which maximizes efficiency. Along with non-blocking flow control, a system that can create virtual paths or multiplexing traffic on independent flow control through the system makes optimal use of system resources without redundancy.

Employing a non-blocking flow control with virtual channels translates to an overall increase in concurrency, thereby increasing the system bandwidth. There are numerous advantages of increased bandwidth, including lowering the system clock because over provisioning is reduced or not needed. It also has the positive effect of reducing buffer sizes in the network because there are less potential data flow conflicts. This reduces the gate count, thereby reducing power and cost. Finally you will save power—the processors can sleep longer because there is less waiting for memory.

In this case, taking it slower can be better. That’s something you don’t often hear people say anymore.

–Frank Ferro is director of marketing at Sonics.