Information Technology

September 29, 2006
System Driven Imperative: Design for Flexibility

Malcolm Penn

NEW DELHI -- Chip-level system design is undergoing a series of changes driven by the need to meet consumer-pressured cost and time-to-market targets. This is transforming the chip architecture, the design methodology and the implementation.

Before a design implementation decision is made a set of system functions are decided upon by the product definition team knowledge from the market requirement. A ‘function’ is an abstract view of the behaviour of the system, there is no notion of implementation at this stage. The next step is to map or assign where the functions are to be implemented within the architecture proposed.

This essential mapping process determines the performance of the design and its cost. Using experience and analysis, designers develop estimation models to allow for changes in architecture and other design exploration. This iterative process is continued until the final architecture is determined and which may mean compromises in performance and product costs.

To reduce design costs and speed the next chip design, management must ensure that re-use is built into design methodology not only at the component and microprocessor-core level, but also at the system level. To do this architectural designers will use more and more software in a fixed basic architecture to implement functions and therefore substantial re-use and trade in software IP will be seen in the future.

This fixed basic architecture is becoming known as a ‘hardware platform’ and is being used internally by large IDMs or offered on the market by ASIC and FPGA vendors, such as eASIC or Xilinx, or sold as integrated IP by chipless IP vendors, such as ARC, ARM and Tensilica.

In the future to maintain a high level of application software reuse, this hardware platform will be abstracted using a ‘software platform’ which brings together the different parts of the hardware platform with the Real Time Operating System (RTOS), the I/O subsystem, the device drivers and the communication subsystem. At such an abstraction level the software will just see a high-level interface to the hardware via the Application Program Interface (API).

As we move from 90nm geometries through 65nm to 45nm ‘re-use’ at the platform level will be a method of maintaining quality through the use of pre-tested components and IP blocks, but it will also be a method of shortening development times, meeting ‘right first time’ necessities so meeting the shorter time-to-market requirements in consumer applications.

New SoC platforms will have to be accompanied by sophisticated EDA tools that will be able to capture high-level architectural concepts and complexity at the same time being able to free the designer from the detail and effects of smaller and smaller geometries.

These shorter development times required for increasingly complex products often put pressures on the design engineers to start work on the product before the specification has been agreed. This means that the product under design must be able to be adapted to changes without the need for a re-design or the vital market window will be missed. In this modern world the design must have a degree of ‘flexibility’ and the more flexible it the more it can be reused for different applications.

The question now becomes: Will large SoC designs be possible and profitable without this flexibility and in what form will it come? What is the optimum amount of flexibility?

Future SoC design will evolve into platforms supporting certain popular algorithms or applications and will sit somewhere between purely hardware and purely software solutions. These will have to balance the four constraints of low power, high performance, low cost and ultimate flexibility. Due to the complexity of circuits, they are likely to come away from the fine-grain gate-level re-configurability of the FPGA to use a more coarse-grain structure with blocks at the ALU, memory, and multiplier, etc. level.

(The author is chairman and CEO, Future Horizons)