Last week at the monthly IEEE Computer Society meeting in Silicon Valley, Sonics founder and CTO Drew Wingard discussed the evolving SoC. He started by displaying a chart of the key components in an Apple iPhone 4S with their prices:
- Flash memory $24
- LCD $19
- Touch screen $16
- SoCs (2) $13-$15 each
It’s ironic, said Wingard, that the components that cost the most to develop and require the most expensive fabrication facilities (the SoCs) cost the least. That we can develop these SoCs at all, and offer them to system developers like Apple as such a low cost is a testament to the continued improvement in design techniques and design tools. One such technique, noted Wingard, is the use of IP. The average SoC design is now nearing 50 IP cores, he said, and many designs are approaching 100 cores. These cores are mostly heterogeneous.
Core usage is increasing because we cannot afford to design each new chip from scratch. Gate-level abstraction has been great to this point but design complexity is now forcing the issue and IP cores represent the next level up for design representation.
Another reason for the increase in the number of cores used per SoC design is because the architectures that win (according to Wingard) are distributed. Quality of results improves as we move tasks to individual processors that are specialized for the assigned task and Moore’s Law is giving us the transistors we need to change from centralized processing to more distributed architectural designs.
However, processing alone doesn’t get the job done. You also need to move data. When system designs were more centralized, a single DMA controller might be tasked with most of the data movement, freeing the central processor to perform more computation. “Centralized DMA is largely gone,” said Wingard. Most large IP blocks now incorporate their own DMA facilities, but this design approach leads to massive amounts of inter-block traffic from diverse sources. It also leads to different traffic profiles that depend on a system’s operating mode.
Most of that traffic is now directed at the one SDRAM in the system. Common system designs that use this single-SDRAM model include cost-sensitive designs such as HDTVs, game consoles, and mobile phones. Although developing system designs with a single SDRAM or SDRAM array produces the lowest-cost system, it also places a huge burden on the SDRAM and its interface port. And SDRAMs interface protocols have many complex rules for moving data into and out of the SDRAM. Violate any rule and the SDRAM may hiccup—that means lost data. In most cases, lost data is a bad thing. A very bad thing.
Wingard then noted that traffic to and from SDRAMs fell into two broad categories: a control pattern and a data pattern. The data pattern involves large data blocks such as video frames that must arrive at the right frequency although the latency might itself be variable. The control pattern has a bandwidth requirement, to keep processors fed with instructions, but instruction caches largely buffer processors from latency variability as long as the bandwidth requirements are met.
All of this discussion led to Wingard’s point, which was that IP-block interconnect is itself an IP block. The interconnect’s job is to meet the bandwidth and latency requirements of all the processing blocks on the SoC. Increasingly, said Wingard, buses cannot meet this requirement.
Wingard’s talk was the year’s last technical presentation for the Silicon Valley chapter of the IEEE Computer Society. It’s been a very strong year of presentations for the chapter and if you reside in Silicon Valley, you might want to consider attending when the talks resume in 2012.