A self-avowed "software guy," Takada spoke Monday (July 11) at the Multi-Processor SoC (MPSoC) workshop. He presented SystemBuilder, a system-level design tool that works from high-level descriptions written in the C language.

"I think the difficulty in communication between hardware and software engineers is a serious obstacle for deciding appropriate hardware/software partitioning," Takada said. He noted that terminology is different, with hardware and software engineers having different meanings for words like "test" and "verification."

Further, he said, concerns are different, with hardware engineers focused primarily on performance and software engineers more concerned with managing complexity. "Both are important to both engineers, but the tradeoffs are different," Takada said. "One does not understand the other's problem."

The word "system" also has different meanings. Takada suggested a simple test: ask a hardware engineer and a software engineer to draw a "system" diagram of a mobile phone. The results will be very different, he said.

Takada noted that what the software engineer would call an "implementation" can be used as a specification by hardware engineers. A practical system-level design flow, he said, would start with a model description, move to a system-level description, and from there decompose into hardware and software development.

"Describing hardware and the software that handles it in one language can improve design productivity," Takada said. But he's not impressed with one industry solution. "I don't think SystemC is suitable for software engineers," he said. "At least, I don't like SystemC."

Nagoya University's SystemBuilder starts with a system-level description in C. Hardware/software partitioning is performed by human designers. The tool offers automatic hardware/software interface synthesis and automatic software synthesis.

SystemBuilder uses a commercial behavioral synthesis tool, Excite from Y Explorations, to generate RTL code for hardware. SystemBuilder runs hardware/software co-simulation at various levels of abstraction, and ends up with an FGPA implementation.

The basic components of the system description are functional units (FUs) of concurrent execution, and communication primitives (CPs) that provide blocking and non-blocking communications. A script describes how FUs and CPs are connected.

The C-language FUs may end up as hardware or software blocks, and users can try many different implementations in a short period of time, Takada said. He showed one example in which ten different hardware/software partitions were tried in a few hours for a JPEG decoder design, followed by performance estimation.

Takada said SystemBuilder is "now under evaluation by some companies." Meanwhile, his research group is moving on, and is seeking to describe the software/hardware interface at a higher abstraction level. "I think the current abstraction level is still too low," he said.

Takada's slides are available on line.