Future success of SoCs and platforms lies in verification

Commonly, engineers will segment their designs into portions that they have signif icant expertise in, and other portions where they rely on oth ers to provide the expertise. The engineers make as few changes as possible to the part of the design where expertise is lacking, such as processors, memories, clock functions and input/output modules, and instead concentrate their efforts on their areas of expertise.

A standard approach to this segmentation is to use "hard" cores - designs that have been pre-verified, and frozen in the state in which they have been verified. If the design is frozen, and its environment is fixed from one chip to an other, it should always work and should not require additional verification. This strategy works well with processors and some types of memories — whose functionality by definition never changes — and with analog components, which are diffi cult to re-design. But this approach does not work as well for components whose requirements or environment change.

Components with regular structures whose requirements or environme nts change in predictable ways can be created as "firm" cores. The changes to these are systematic enough that they can be generated via software and have guaranteed predictable properties. Cores such as RAMs are well suited for "firming up".

Use of hard and firm cores can significantly reduce the verification eff ort of creating a new chip. They do have some limitations, however. Hard cores are hardened in such a way that they are guaranteed only for a particular manufacturing process-the core is usually not suitable for use with a different manufacturer or different transistor size — 0.18-micron versus 0.13-micron, for example. In order to move to the latest, most cost-effective process or manufacturer, the designer must ensure that the hard core is available in the new process. Firm cores have similar constraints. However, they possess the advantage of being easier to port from one process to another and are easier to verify. As a result they tend to be more widely available than har d cores.

Soft cores fill the gap between fully verified cores a nd custom-designed logic. Soft cores are implemented as source code that requires processing (configuration, synthesis, place and route, and timing closure). Because they are not pre-processed, they can be easily ported from one manufacturing process to another, and can adapt to different environments such as clock speed and interface type.

While use of pre-verified hard and soft cores in a design is beneficial in speeding chip development, often this approach alone is insufficient to reduce develo pment time and increase first-time success of SoC designs. Much of the complexity lies in designing and verifying all of the interaction of the different system components.

The platform approach to SoC design attempts to address this issue. A pla tform is a base design with which a wide variety of devices are created. The use of a platform hardens architectural features, such as the maximum number of processors supported , the maximum available system bandwidth, and the range of speeds of the syst em interconnects. However, it leaves open implementation specifics, such as the number and variety of peripheral components and the types and sizes of memories used. It is a "soft" design, rather than a hard or firm core, which means that it can be alte red to suit the design requirements, and can be targeted to virtually any manufacturer and chip manufacturing process.

Using a SoC platform can reduce the amount of re-verification required with each design change by maintaining a consistent environm ent for each component that is added to the platform. Thus, if the component has been verified once in one version the platform, it requires only a minimum of re-verification to ensure that it will work in a different configuration of the platform. Engi neers can concentrate on system verification rather than component verification.

A platform is a framework that connects system elements including processor memory ma ps and data coherency management; dedicated memories, such as processor stacks; cloc k generation structures; and I/O control and debug structures. The platform provides a systematic interface to each of these components and a standardized method for the interaction between the components.

The advantages of using a SoC platform ma y seem obvious. So why aren't all designs created this way? The simple answer is that many SoC chips are not designed with an SoC platform as their base because the designs were evolved through "tweaking" — it is impossible to replace a design's ba se when minimal changes can be made. This is referred to as the "legacy" problem. Another reason SoC platforms are not adopted is the feeling that one's design is so unique that the investment in a platform will not pay off over the lifetime of the devic e or its derivatives. A design cycle may also be so short that the designers do not think they have time to invest in creating or obtaining a platform. Some of these reasons for not adopting a SoC platform are valid. These can be explored by determining the benefits and tradeoffs of a SoC platform.

Platform benefits, tradeoffs

The primary benefit of a SoC platform is functional isolation. Components can be isolated from each other, and thus can be independently verified. T he platform itself can be isolated from its components so that it too can be independently verified. The use of a platform assists in porting a design to a different product because of the built-in flexibility. Because it is designed to expand or contra ct to accommodate a range of components, minimal re-design and far less re-verification is needed. If a design group does not have the resources, time, or manpower to develop a flexible platform, it can be procured from a third-party intellectual propert y provider. Platforms such as Palmchip's AcurX and ARM's PrimeXSys are pre-verified and include a test bench and test suite. Third-party platforms can of fer other advantages as well. For example, the AcurX platform includes support for different proces sors, is configurable and accelerates timing closure. Benefits such as these are generally not available with a custom design.

The primary drawbacks of using an SoC platform are that it is an investment, both in terms of time and effort, or financially if a platform is being licensed from a third party. Some designs may not benefit from an SoC platform. For certain designs, it may be more expedient to develop a custom design from scratch than to retrofit it to an SoC platform.

In addition, analysis and effort must be spent to determine if the platform's features and constraints will meet the needs of a number of designs, not just those of the current design. The flexibility of the platform can also be a drawback. A flexible structure is n ot as optimized as a custom design and may not be suitable for a device that pushes the edge of the silicon's capability.

Finally, a platform includes constraints. These constraints stem from properties that require extensive modifications to change or require an excessive amount of effort to make configurable. These can include the maximum and minimum on-chip bus width, the system memory map, the number of processors and their interactions, maximum chip size and frequency, and system latency. The benefit of such constraints is that they prevent the platform from becoming unwieldy and slowing the design process instead of accelerating it.

As chips become larger and more complex, increasing productivity of IC development will necessitate some changes to design methodology. Use of hard and firm cores will continue to be important; SoC platforms will also play a strong a part. Without a platform approach, it will be impossible to verify tomorrow's SoC designs without a loss of productivity. A dapting a platform methodology will result in many products created with less effort and greater first-time success.

See related chart