Tools For Reprogrammability -> Platform-based design ups productivity

As the name suggests, this design philosophy allows the user to build and configure a system-on-chip (SoC) design around a stable core platform and connect using standard buses. This is not a new philosophy-system integrators have been doing this for years with VME racks. As processors become more complex, it is quicker and more accurate to buy expertly designed processor boards, allowing the design team to focus on the unique aspects of the design that create the most value and differentiation. These same factors are emerging for SoC design.

The new generation of processors used in SoC designs have increased in complexity to the extent that ensuring optimal design of the surrounding logic is key to achieving the maximum processor performance. To assist the design groups, processor vendors are now beginning to supply configurable designs that include memory and many common peripherals optimized for use with the processor core, and some standard connection ports onto which additional user-designed logic can be quickly added. For example, OKI Electric Industry Co. Ltd., a developer of high-end solution platforms, claims a substantial increase in designer productivity by using its microPlat design.

"Our customers have to spend a lot of time and resources optimizing the design around the processor to ensure maximum processor performance and functionality-even though this is not the most important part of their design. Now, we have created a complete, optimized processor subsystem to allow our customers to deploy instantly a highly optimized solution around which their embedded designs can be created with confidence," said Masasuke Kishi, general manager of OKI's silicon platform architecture department.

Remaining with the VME analogy, the emergence of hierarchical, efficient SoC bus standards (ARM's Amba, IBM's Core Connect) has encouraged processor vendors to adopt these as standard buses for their processor subsystems. In addition, many IP providers have begun to supply IP with processor interfaces conforming to these standards. For example, Mentor Graphics' IP business unit, Inventra, now supplies its USB design with an Amba advanced high-performance (AHB) interface.

The adoption of standard high-performance buses by IP vendors has been triggered by a third important factor in the emergence of platform-based design. The leading-edge commercial IP has reached new levels of design complexity. For instance, many of the new Bluetooth modules now being incorporated into SoC designs are processor-based designs in their own ri ght.

The increased data-processing capabilities require efficient data-transfer mechanisms to ensure efficient system integration. As IP capabilities and complexity continue to rise, we can expect to see increased use of complex bus standards to facilitate rapid and efficient system integration.

PBD is not a methodology to achieve a complete SoC design. Instead, it allows the processor-centric part of the system to be created, configured and verified quickly. This allows the design team to focus on the creation of the differentiated, value-added parts of the design. The potential productivity gains available by adopting PBD do not result in a complete change in the EDA tool chain; however, there will be a noticeable change of emphasis.

Design capture is more akin to joining building blocks together rather than traditional schematic or language capture. Designers will select a core platform that may offer most of the basic capabilities required by the design, as well as add memory opti ons and peripherals. Each of the building blocks has to be configured, often in unique or design-specific ways. So a flexible configuration methodology is required, leaving the tools to automatically generate all of the interconnect, decode logic and develop the bus bridges required to make the peripheral work with a core platform. However, generating interconnect is just one facet of the platform design creation process. Adding a peripheral to a core platform implies a design process specific to the type of SoC design team member.

For instance, the test and integration engineer requires a first-level diagnostics program to execute on the design to ensure the design will boot and function correctly. PBD tools will generate this type of program automatically from the same database from which the RTL design was created.

If a peripheral is replaced with a functionally equivalent module that has a completely different footprint, perhaps there are a different number of memory-mapped registers or a different bus interconnect. PBD tools will regenerate both the hardware design and the diagnostics code automatically to account for such design changes. In short, the PBD tools account for the implications of design additions or changes through many aspects of the design process.

However, in most designs, an efficient design capture does not always equate to an efficient design cycle. Capturing designs more quickly can lead to an exponential increase in design verification tasks. This is especially true for SoC designs, where many verification tools are highly customized during the design capture process to work with the design.

A key part of PBD methodology is not only to generate complete hardware and software designs but to generate the custom execution environments required to verify the designs. Each set of verification tools customized for a particular design is called an execution environment. Most design groups will require multiple execution environments to complete the verificatio n of a design. Each environment will support a different combination of tools and verification targets, and offer different levels of accuracy and performance.

Some tools will be used by multiple execution environments. For instance, the Xray debugger is used throughout Mentor's PBD tool flow. For hardware designers, formatting commands are added to Xray and automatically executed to track hardware-specific changes in the memory configuration of the design for use in the seamless hardware-software co-verification tools.

Software developers use the Xray debugger with high-level functional models of the peripherals instead of the HDL models. Thus, formatting commands are not appropriate for this environment, which allows very rapid simulation of the whole platform design.

Hardware design formatting commands are automatically generated by the platform tools and are automatically updated if the memory or peripheral configuration of the design changes.

PBD to ols will generate and customize tools based on the design data gathered during the capture phase. As soon as the platform design has been created, a range of customized verification environments can be generated for use by the verification team.

If design changes are made, all of the execution environments can be regenerated automatically to work with them. For example, one IP block could be replaced by another that is functionally equivalent but has a different memory-mapped register set.

One key concept for PBD verification is adaptive functional test. Incorporating large IP blocks in a design is a significant functional-test challenge. Though the IP will have been proven functional in a standalone environment, platform designers must revalidate functionality within the context of the platform design.

Typically, the types of problems that surface within a design will be a combination of hardware and software problems. Perhaps two high-bandwidth peripherals ha ve been selected for the design but when activated together, they overload the bus bandwidth. Or, due to the load being placed on the processor servicing one of the peripherals, the level of service to the second peripheral drops below an acceptable level.

To reduce the amount of manual functional-test development required to validate a design, functional tests are likely to be delivered alongside the IP hardware and software design in a context- and design-independent format. The platform tools will be responsible for mapping the functional tests onto different designs and onto the same design at different levels of abstraction. This means the same tests can be executed within different execution environments.

As IP designs increase in size, it is expected that the functional tests that validate the IP will grow exponentially to the point where the test suite is massively larger than the design. It is anticipated that the functional-test suite development will emerge as a niche industry with in the EDA/IP world, where many telecom functional tests are delivered in device- and abstraction-independent formats already.

Overall, software designers will benefit as much, if not more, from PBD as hardware designers. In the near future, we can expect to see complete operating systems built and reconfigured automatically for individual designs.