In his keynote speech to DATE delegates, Professor Hugo de Man of the Catholic University of Leuven and senior research fellow with IMEC, said he expects future system-on-chip (SoC) designs to be arrays of parallel, application-specific instruction processors (ASIPs), wired together by relatively low-speed on-chip packet networks.

To parallelise the software for these devices, de Man said washing-machine software will take the original source and transform into multiple code streams that themselves exhibit a lot of data-level parallelism.

"It is better to use 100 processors at 20MHz than one at 20GHz," said de Man.

By running processors more slowly, an OS given control over supply voltages and thresholds would be able to dramatically cut power.

"If the OS is capable of reducing the supply voltage from 2 to 0.6V, you can cut power to 1.5% of the original power consumption.

He said the drive for this approach to software design will be tiny wearable computers or "transducer nodes" that run at 100Mops. They would be relatively inflexible and likely to cost less than their packaging.

They would talk to much more flexible basestation or assist nodes that make up the rest of an "ambient intelligence" for users.

"They would be 100 to 1000 times more complex than today's microprocessors. But the difference between programmable microprocessors and the intrinsic power of silicon is that silicon is more than 500 times more power efficient."

"We need 1 billion operations per second but at less than 100uW per device, so we can take energy out of the environment.

"Why do we need such computational complexity? We need extreme spectral efficiency to communicate at high speeds. We have to come extremely close to Shannon's limit," said de Man.

"By using voltage control and the washing machine, it is possible to move programmable architectures into the ambient intelligence region."

He said one project conducted at IMEC demonstrated how the software washing machine took code written to perform MPEG4 decoding on a Pentium running at up to 900MHz.

"If you take the unwashed code, it is not possible to reach 25 frames per second," he said.

After the first iteration, the optimiser produced code that could handle the 25frame/s frame rate at 300MHz. With a second run aimed at exploiting data parallelism and the MMX instruction set, the clock speed was reduced to 170MHz.