`Careful with that instruction, Eugene'

Electronics Times, July 24, 2000

Chris Edwards looks at the democratisation of processor design

Processor design has suddenly become a democratic process. It's no longer restricted to the high priesthood of full-custom designers. Anyone armed with a synthesis tool and a reason for doing it can build a microprocessor. The problem is, you are going to have to build the software tools as well.

It is not going to be fun running up a processor design only to get screams from the software development team: "Aaaaagh! We haven't got time to code up for a load of weird instructions. Go back and implement something we can use."

Yet there are compelling reasons to use a custom processor. Dedicated hardware is inflexible and increasingly risky to design. Ten years ago, if you got it wrong, you could wheel in a PLD and apply a digital BandAid. Today, you may be able to fix some things with the help of an FPGA in a medium-volume design or by making small changes in the upper metal layers of a high-volume custom chip, if you are lucky.

Tomorrow, you are likely to be stuck with whatever mistakes appear in the logic. Not only that, but the economics for implementing systems-on- chip mean that many designers are going to have to reuse entire chips across projects, or at least large parts of a design. By implementing key functions in hardware but making it possible to reorganise them with software, the flexibility needed can be achieved.

Roger Shepherd, manager of advanced architectures for STMicroelectronics' (ST) microcores division, said: "Our thinking at the moment is that we want to use the processor to implement functions that we would otherwise implement in hardware."

Mark Edwards, hardware manager of the EWAN business unit at Cisco, said: "In communications applications, a lot of customisation has to happen. There are new traffic management algorithms and applications that customers want to put on. And the protocols themselves are evolving. Having a lot of hardware perform those functions is ineffective with regard to reusability."

The attraction of software control does not mean that programmable approaches will replace all forms of hardware. There are serious die size and cost considerations to think about, particularly in advanced consumer designs.

Shepherd said: "You are up against the economics all the time. The consumer people will fight over a cent. There is some value to flexibility but there is a limit. As we move forward, once a programmable solution becomes economic, all the other benefits will come out."

The key to designing processors that can replace hardware lies in optimisation. The architecture has to be highly tuned to the application. That means being able to explore a variety of architectures and simulate what effect adding a parallel execution unit or a new instruction has. In general, most developers will never have to develop a processor from scratch: there are ones you can customise.

The first companies into the market for customisable processors, such as ARC and Tensilica, have built simulation environments that let designers see the effect of adding new instructions or complete coprocessors.

James Hakewill, director of product engineering at ARC, said: "You can add instructions to an extensible instruction-set simulator. You can try different approaches long before you get to hardware."

For its parallel DSP architecture, German start-up Systemonic has built an environment that lets designers change the number of execution units in a base very long instruction word (VLIW) processor and add their own datapaths.

Dr Michael Bolle, co-founder and vice-president of engineering for Systemonic, said: "The design flow is based on an architectural database. It defines how many registers we use, how many processor slices and how many architectural-specific units there are. We then generate automatically the instruction set simulator, the debugger and the development environment for hardware-software co-design."

Hewlett-Packard (HP) and ST are co-operating on a project to build customisable VLIW processors for embedded designs and the tools to go with them. Shepherd said: "The technology that HP has developed lets you build two things very quickly: optimising VLIW compilers and a fast executing simulator."

The compiler is the missing link in the development of custom processors. The current crop of tools will generate functions that act as wrappers for new instructions. Compilers are not yet clever enough to recognise blocks of C code and insert custom instructions at the right point.

"We have a lot of algorithms in C," said Cisco's Edwards. "There are eight million lines of code in IOS [Cisco's network operating system]. We want to deploy certain C algorithms in parallel hardware. That will need a lot of automation. A lot is being done manually now and that's not a pleasant experience."

By automatically generating what are known as intrinsic functions, the tools that companies such as ARC and Tensilica have developed make it possible for the compiler to perform some optimisations.