ASIC/ASSP platform speeds development

When gate counts increase, synthesis and layout tools become stressed to their limits, revealing previously unknown tool bugs. Individual intellectual-property (IP) blocks may be new and untested. Even if some blocks have been used in previous designs, they may exhibit unexpected behaviors in the new design's architecture. The choice of processor and operating system will have a profound effect on the entire system of hardware and software.

The use of platforms can help reduce risk and improve time-to-market for such a project. In the context of using ASIC and application-specific standard-product (ASSP) designs, a "platform" is an existing chip architecture that minimizes project risk as much as possible. It does so by including as many critical system elements of the target application as possible, such as a specific processor, bus structure, support peripherals and OS support. Ideally, this architecture would have already been proven out in silicon, which reduces risk further. In an ASIC/ASSP environment, the ultimate goal is to get a working product to market as quickly as possible. Risk, as introduced from all possible sources, is the biggest obstacle to accomplishing that goal.

On any SoC project, the overall goal of the platform selection process should be to find the platform that reduces risk as much as possible on each of the following phases of the project:

-System definition. Determine what blocks are needed.

• System architecture. Determine how the blocks interact.

• System verification. Prove that solutions are not based upon incorrect assumptions.

• System implementation. Build the system.

In the definition phase, platforms help by providing predefined lists of available IP. For example, if a UART is required, an available platform device that contains a USART should not be ruled out, since the USART is a superset of the UART functionality. Likewise, if a platform device contains more blocks than are needed, it is much easier and less risky to remove excess blocks than to add unproven blocks into a design. This situation is common in many standard-product microprocessor devices that may be platform candidates.

One must also be careful not to cast assumptions as requirements. Perhaps the project requires intensive graphics generation. If we assume that this burden must fall to the main processor, we might conclude that we need 400-Mips performance in the processor. But the application might only require 50 Mips if a separate coprocessor (such as a graphics engine) is available to offload part of the work. When reviewing platform candidates, be open to different approaches to solving the problems at hand.

In the architecture phase, platform vendors have already solved the significant issues associated with bus selection topology and interconnection of IP to the bus. Current designs are so large and complex that the interconnect methodology has taken on a life of its own. Defining an architecture from scratch requires a thorough knowledge of many different bus structures in order to choose the right one and to realistically assess available bandwidth. Knowledge of bus pipelining and latencies, turnaround time, bridges and wrappers is only the beginning. The processor of choice and all IP blocks must also mate smoothly, with little or no performance loss due to architectural differences.

For example, an async hronous processor bus coupled to a synchronous bus will probably yield some coupling loss. Peripherals like an SDRAM controller may require wait states during a portion of the access cycle; ideally, such wait states should not tie up bus bandwidth. A platform device will have already addressed these complex issues and will provide a ready vehicle for performance testing in a real-world (vs. slow-simulation) environment.

In recognition of the risk factors, performance issues and increased design time required to interconnect IP, many vendors have made special efforts to solve this common challenge. A number of bus/IP interconnect choices are available to the designer today. Some approaches involve using high-speed serial links or on-chip networks for interconnect. The fact that so many vendors are trying to solve this problem is a good clue that this issue is not insignificant.

In the verification phase, we build a representation of the target system to test out interconnectivity and performan ce. Some performance metrics are very difficult to assess on paper. In multimaster designs, bus loading is very difficult to predict, especially when processors with cache are involved. Worst-case situations can generally be calculated, but typical bus availability is much harder to determine. The availability of emulation hardware does not eliminate the need to perform due-diligence calculations, but it will make it much easier to assess the actual results.

Developers who use platform silicon have the opportunity to create a design that runs much closer to actual speed and to reduce the number of gates that must be placed in FPGA. Large numbers of interconnected FPGAs will inherently run more slowly than a single large device because of clock distribution and synchronization issues between the devices, as well as the inherent delays of I/O buffers. The wide buses typical in today's designs also present a difficult problem when multiple FPGAs are used to create an emulation system. If not enough gat es are available to place all necessary IP into a single FPGA, the extremely large pin counts associated with wide buses limit the number of FPGAs that can be interconnected.

Since most designers now use multiplexed rather than tristate buses, there is a high concentration of signals at the masters (for single-layer buses) or at both the masters and the slaves (for multilayer buses). Designers who try to use an FPGA to create either a multimaster or a multilayer AHB bus will quickly find that more pins are required than are available on today's FPGAs. But if they use platform silicon that already incorporates most of the IP, it's easier to fit the remaining IP into a single FPGA device, and the number of bus signals required is reduced.

Using platform silicon also allows verification of actual performance of such critical system elements as memory controllers. It may not be enough to emulate these functions in FPGA, however, since FPGA implementations typically cannot run at the intended spe ed and do not use the specific I/O cells that will be used in the ASIC/ASSP.

Robert Fries is Manager of ASIC/ASSP Applications Engineering for Atmel Corp. (Colorado Springs, Colo.).