Panel mulls configurable, reconfigurable IP for SoCs
NEWPORT BEACH, Calif. — The debate over using two new classes of IP in SoC designs is picking up steam as IP vendors, academicians and designers grapple with issues like how to partition applications between hardware and software.
A panel of industry representatives debated the issues here during the Savant Company First International SoC Conference this week. The debate ranged widely across the promises, drawbacks and complexities of configurable CPUs and reconfigurable computing arrays as elements in a larger SoC.
Panelists included: David Fritz, vice president of marketing for SoCs at ARC International; Steve Leibson, technology evangelist at Tensilica; Nader Bagherzadeh, professor of electrical and computer engineering at the University of California at Irvine and Morpho Technologies; Ralph Weir, director of technical marketing at Elixent; and Chinh Le, CEO and CTO of LwWiz Communications Inc.
Initially the panel debated how an application should be partitioned so that some tasks are assigned to software, some to fixed hardware, and some to either software with instruction set extensions — in the case of one-time configurable CPUs — or processing-element arrays.
Panelists agreed there is art involved, but that the process is also a search for tasks that often exceed the performance range of software on a standard CPU core. Another concern is that those tasks are prone to change or uncertainty and are therefore difficult to implement in fixed hardware.
Bagherzadeh said that in the case of single-instruction, multiple-data blocks such as processor arrays, a task must have considerable data parallelism in order to benefit from the architecture. "These types of devices are wonderful for exploiting the inherent parallelism in many signal processing applications," he said. "But they are not suitable for everything. If you can't find parallelizable loops, you should consider conventional ASIC hardware."
Le countered that even when parallelism is present, highly parallel architectures were not always the answer. "We evaluated one of these architectures for an AES encryption application," he said. "It ended up taking 128 tiles and a huge amount of power to get the job done — it just wasn't feasible."
On the question of integration into the design flow, all vendors claim to fit seamlessly into a standard ASIC flow. There were some differences. ARC and Tensilica generate synthesizable RTL, generally with synthesis scripts and test benches. The Elixent array, in contrast, is compiled directly to a physical design, much like a memory instance. All of the architectures discussed also provided for scan. Elixent's Weir described a technique whereby the array could be configured as a built-in, self-test engine.
But again there were differences in details. Leibson said Tensilica's synthesis scripts were generated specifically for Artisan libraries, and that use of other libraries would require "working with the customer." Fritz similarly said that ARC was involved in developing scripts for customers, but that the customers generally had a clear idea where the critical paths were in a CPU and could plan accordingly.
Both Weir and Bagherzadeh observed that arrays, which comprise a large number of instances of identical small elements, are generally easier to implement because of their regularity and simplicity.
Le again added a note of caution. "Integration of large blocks like these are a major headache," he warned. "Imposing a bus on an SoC, for instance, is problematic. If it doesn't fit the needs of the rest of the chip, then you have to put a wrapper around it, and you'd almost just as well design your own processor. Many of these things come with fixed clocks that are tuned so that the processor will meet its speed specs. But now you have one more clock region, and a lot of fast clock boundary crossings to deal with. And even after you get the design integrated, you still have to integrate whatever test vectors they give you into your verification flow somehow. None of this is easy."
Under questioning, the panel admitted that reconfigurable solutions typically had much larger die area than equivalent fixed logic. This difference could be paid back by reuse of the reconfigurable array to perform several different functions, or by the ability of a larger, more expensive die to take the place of several different ASIC designs.
Liebson said that Tensilica had found that engineers were a very conservative lot. "They do what they already know," he said. "Engineers who really want to try something new — we call them 'new da Vincis' — make up less than a quarter of the community."
Panelists added that in partitioning a design and choosing an implementation approach, marketing input about forecasts and future needs were essential.
Some panelists suggested that configurable and reconfigurable cores could progress if sold as solutions for a particular range of problems. Others disagreed. "That really sells the technology short, because you end up not addressing all the other things that customers could have done with the architecture," Weir said.
