Design Article

Chip makers look for a few good system-level design tools

Richard J. Tobias, Vice President, ASIC & Foundry Business Unit, System LSI Group, Toshiba America Electronic Components, Inc., San Francisco, Calif.

4/18/2003 10:14 AM EDT

Chip makers look for a few good system-level design tools

Where are the system-level design tools that we need for systems on chips? For years the semiconductor industry has been marching noisily toward the world of SoCs, but now that we are here, we find that the EDA companies have not arrived with the necessary support. The industry seems to be reverting to an era in which semiconductor vendors have to roll their own tools.

There are a few signs of EDA progress. Some EDA companies are working with system-design approaches that revolve around multiple types of buses. Several tools revolve around the AMBA bus, for example, and of course Sonics has a set of tools for their bus. In academia, the Ptolemy project led by UC Berkeley professor Ed Lee is doing interesting work on defining models of computation that govern interactions among concurrently operating components. One goal is to address the use of heterogeneous mixtures of computation models-a key requirement for designing today's SoCs at a high level of abstraction.

While these are promising signs, semiconductor vendors and their customers must design SoCs now. The system-level design tools offered by EDA companies fall far short of the mark. This article outlines those shortcomings and describes a design approach that is working at Toshiba. Nonetheless, no individual semiconductor vendor can solve the system-design puzzle. The EDA companies must catch up to the realities of today's SoC hardware and software.

In addition to inadequate system-level tools, we should note that the industry faces a shortage of designers who really grasp all the principles of system-level work. Designers know how to write RTL, and they know how to write enough C code and/or Java to get the hardware to function. But few designers understand the ramifications of various computational models and how to make tradeoffs between hardware and software implementations. Universities could do a better job in training engineers to deal with system-level concepts.

The system-level design tools on the market today are inadequate for several reasons. First, the level of abstraction at which they work is incomprehensible to most designers. It is easy to say that the designers need to learn new design concepts, but the paradigms imposed by the existing tools are not worth learning. Even when the tools work, they work only for certain computational paradigms.

The second shortcoming is that the existing tools often fail to translate their high-level representations into usable RTL or software code. The resulting designs are generally far too large and consume far too much power.

Also, existing system-level design tools are too slow, and simulations execute too slowly to test software. The best simulation speed you can hope for is on the order of thousands of cycles per second, but you need millions of cycles to run the thousands or millions of lines of code for today's SoCs.

FPGA-based prototypes offer the necessary speed, but commercial prototyping systems cost too much and are too difficult to configure. The tools that map a design's RTL representation into the FPGAs too often fail to provide adequate results.

SoCs such as communications switches have a regular, highly structured architecture. However, the typical SoC structure resembles that of a board. Like a board, these chips include many types of components (such as processors, memories, dedicated logic and I/O devices) connected by various types of buses.

A board-design metaphor thus works well for most SoCs. Designers have no trouble understanding this model, and it helps organize the necessary system-level design and programming tasks.

Without good tools to translate system-level specifications into hardware and software, the board-design approach is in some ways too much like traditional board design. That is, you design the hardware, then build a prototype and use it for developing the software. Unfortunately, fabricating sample SoCs is a lot more expensive than building one-off boards, and today's tight design cycles no longer allow the luxury of waiting until final silicon to develop the software.

Platform power

Two interlocking solutions help close the critical software gap for SoCs. The first solution is to base the SoCs on a platform approach. The second is to configure FPGA-based prototyping systems around the SoC platforms.

The platform approach enables ASIC vendors to pre-integrate a variety of IP blocks that suit certain types of applications, where the design uses the board-development design paradigm. By configuring the blocks to interact via on-chip buses, the IP can be verified in a system context and interfacing issues resolved before designers start working on a specific SoC. The ASIC vendor can also develop and verify modular software blocks that work with the IP and the chip's internal I/O structure. All together, the platform approach leverages commodity IP blocks, standardized buses, testbenches and high-level C simulation models.

System-level design tools are still important because ASIC designers need a quick way to customize the platforms. The most straightforward method is to start with a platform that includes the widest variety of IP that could conceivably be useful for a type of application, then delete the functions that are not needed for a specific application. Deleting functionality from a properly designed platform generally has the least impact on the ASIC design and verification cycle, so it is practical to implement this approach in a push-button tool flow.

The benefits of the platform carry over to the FPGA-based prototyping system. The ASIC vendor pre-maps the SoC IP onto the FPGAs and includes other standard functions (such as an ARM processor), so customers can get a specific SoC design up and running on the prototype rapidly.

Accelerated by the pre-integrated hardware and software IP plus the prototype for developing additional code, the complete SoC solution can be ready much sooner than has ever before been possible. The platform approach can thus keep us going while the industry waits for the EDA companies to catch up.





Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)

Feedback Form