Ron interviewed Grant Martin, of Tensilica, for this article. While there's been a lot of hype from some of the C-to-RTL vendors about using C for control logic, Grant makes some good points. Here are some highlights from the article:
Grant Martin, chief scientist at configurable-processor vendor Tensilica, has for years been working on the control-logic-synthesis problem. "For the current tools, the sweet spot for ESL synthesis is still datapath logic," he says. "If there is a clear exception, it might be in the networking space, where some design teams have been using [ESL-synthesis-tool set] BlueSpec in areas such as packet-classification engines."
Martin points to several issues with C-to-RTL control-logic synthesis. One is that the strategies that have so far worked best have been less dependent on C sources and not as algorithmic in their approach as the tools for datapaths. It's not that C is a poor language for expressing control logic, Martin says. Some people are comfortable using C dialects in this way. But, in C, he points out, execution time for a control algorithm is generally not an issue. In control-logic hardware, every cycle matters.
I'll add that Bluespec is being used in many areas outside of networking -- many of them in areas traditional behavioral synthesis could never add value, given the datapath-centric focus of those tools. I think Grant hits on one key -- that control logic generation from C suffers tremendously in quality of results, primarily due to the limitations of automatic parallelization technology.
The other point I'd make is that the abstraction for control logic in these other approaches offers little over RTL. Hardware is concurrent -- but these C languages don't raise the level of abstraction of concurrency or advance design in this dimension. I think that's the ultimate issue with these approaches -- and what will impede their use for design beyond datapath centric applications.
0 comments:
Post a Comment