When configurable processors first became an item of discussion in system-on-chip circles a few years ago, their promise seemed straightforward.
When configurable processors first became an item of discussion in system-on-chip circles a few years ago, their promise seemed straightforward. By configuring a CPU core with local scratchpad memory, additional specialized registers or a custom execution unit, you could accelerate the inner loops of numerically intensive applications. That, in turn, would allow you to eliminate hardwired functional blocks from the SoC or, in some cases, to improve the overall performance of the chip.
As Tensilica has demonstrated, a large array of such extended CPU cores can deliver enormous performance on a particular application while preserving some software programmability.
That was then. In today's environment, design cycles are short and markets uncertain, and there are no big margins-even on successful products-to fund risks. The key is to hop from market niche to market niche, risking as little capital as possible and obsessing over cost. This environment does not encourage architectural experimentation.
But that doesn't mean it is a bad time for configurability. ARC International CEO Carl Schlachte commented recently that one of his surprises, upon examining the company's recent design wins, was the consistent interest in configurability-not for performance, but for area and power reduction. "For many of these accounts, configurability wasn't about extending the core but about reducing it," he said.
In today's Simon Legree environment, that makes a sad sort of sense. If the design team is engaged in making incremental changes to an existing SoC to cover nearby and transient market niches, architectural upheaval is probably out of the question. So forget moving major functions from hardware-already designed, verified and cost-reduced hardware, of course-into software. Just make everything cheaper.
If you are working with a relatively static code set-and particularly if you can keep the critical inner loops static, so that those incremental changes hit only rarely traversed control- or exception-path code-there is a chance to save silicon by profiling the daylights out of the code and then shaving cache sizes, register sets and even execution unit features down to the bone.
In the case of ARC and Tensilica, that can make a difference in area. And that can make all the difference.
Ron Wilson covers microprocessors, programmable/reconfigurable logic and the chip design process. He can be reached at firstname.lastname@example.org.