Design Methodology

The pressures of time-to-market are now requiring companies to rush products to market. The Intel Pentium problem showed how important complete testing is to a company's financial well being and image as a leading edge high tech company. The desire for early product shipments and the short market windows requires prototype hardware to be available long before the final product ships. These time pressures are making designers build hardware prototypes of their circuitry for use in larger system level prototypes.

Language-based simulation tools enabled designs to be completed and evaluated in software thus eliminating the need for hardware prototypes. Now that systems are too large, too complex, and too fast for software to simulate at the system level, hardware prototyping is re-emerging as a necessary adjunct to the design process. In addition, more complex systems need a hardware platform for associated software to exercise, especially in embedded systems where firmware may differentiate the product. Thus, a design must be functional before final ASICs are available. "Formerly prototypes were simple," says Douglas Fairbairn, general manager of the Alta Group of Cadence Design Systems (Foster City, CA). "Now they are part of a continuum of design and modeling technologies."

What to do about the non-existent hardware Although it seems productive to start building hardware for a system, generally it is better to analyze alternatives in the hardware-software mix and different architectures to achieve a desired system definition. Circuit implementation accounts for about 20 percent of total design time. The balance is spent building, debugging, performing system level integration, and adjusting the hardware and software design flows to accommodate changes in the design intent.

"A question is how to bring the problem of the software integration closer to the front of the process," says Mitch Weaver, director of engineering, hardware/software system division of Mentor Graphics Corp. (Wilsonville, OR). "The prototyping process needs to incorporate methods to address the software development costs and timing at the same time the hardware is developed. The complexity of verifying software in the prototype phase in telecomm and consumer equipment can amount to 10 million lines of code, in a 32-bit machine running at 100 MIPs. The prototyping integration is complicated by the new ASIC, new hardware and new code all coming together at one time."

"Designers need to address changes in methodologies and behaviors to improve productivity," says Baruch Deutsch, product line manager, Alta Group of Cadence Design Systems (Foster City, CA). "The keys to this are to start from libraries you can trust, prototype into various end units and most importantly, only work to capture the design after determining what you need to build. The problem of wanting to start building hardware before completing the design intent and architectural analyses can cause the mix of hardware and software in a system to be less than optimal. Just because the software can be redone for less than an ASIC, does not mean that the amount of software should increase".

An issue to consider before developing a hardware prototype is the need for an ASIC surrogate. Manpower and equipment costs must be weighed against schedule and need for the hardware (see "Co-Verification Strategies in Hardware-Software Co-Design" in the July 1995 issue of Integrated System Design , and "Bridging the Gap to Software" in the Sept. 1994 issue of ASIC & EDA ). Some companies, notably Chip Express and Xilinx , have developed software models to evaluate costs and relative benefits of various alternatives to hardware development.

"First, make sure to evaluate the level of effort and cost to do a prototype," suggests Barry Marsh, ASIC marketing director of Fujitsu Microelectronics (San Jose, CA). "Make sure the parts are really needed and worth the time and effort. It may be that the extra time and effort to develop a additional working prototype (ahead of the silicon ) may be greater than the value of the prototype. The net result may be to have two understaffed projects rather than only one fully staffed project. Second, understand the extra time and effort and cost to learn and use the additional tools."

The place to start, states Patrick Scaglia, vice president of Cadence Berkeley Labs (San Jose, CA), is the architectural level. "For man/machine interfaces a virtual prototype will allow designer to test system, and let users test and interact with the prototype," he observes. "The designer needs to have the prototype as close as possible to real time, as close as possible to the final real product. You don't want to generate 0's and 1's, but need to see the final form. It helps to carry over specs, test beds throughout the design process."

Rapid prototypes methodologies start with an understanding of the top level system requirements. Analyses of different implementations must be completed before beginning hardware development. If the methodologies and behaviors in the current design environment do not allow this, the entire design cycle will be extended by the iterations as the software and hardware are integrated.

The Advanced Research Projects Agency (ARPA) has a program for Rapid Prototyping of Application Specific Signal Processors (RASSP). It dramatically improves how embedded signal processors are designed, upgraded, manufactured and supported. Many of its tools and methodologies can be transferred from the military to commercial development.

Mark A. Richards, Advanced Research Projects Agency (ARPA), Electronic Systems Technology Office (Arlington, VA) writes "RASSP is not simply a program to develop electronic design automation (EDA) tools for embedded digital signal processors (DSPs). The best tools in the world will not achieve good results if they are used poorly, or if they are used to design a poorly conceived product. Achieving the RASSP program goals will require a coordinated approach to signal processor architecture; design methodology; and electronic design infrastructure, which includes such items as EDA, reuse libraries, and enterprise networking."

James Saultz, RASSP Program Director, Lockheed Martin (Camden, NJ) says "The levels of sophistication in systems is getting too high for only hardware and software developments. The program goals are to develop virtual prototypes, getting a system developed with no breadboards. This is an attempt to capture the system requirements and decompose them to hardware and software. EDA tools only address the design aspects but do not really interface to the manufacturing requirements. Although it was initiated for large multiprocessing applications, RASSP has potential for commercial applications as a base for a design methodology."

Without going into implementation details, the reader must evaluate various technologies available for prototyping. Some considerations include the number of prototype units needed, type of units needed, and choice of a particular methodology. Appraisal of new and existing tools and technologies for a rapid prototyping environment, should include ease of use and ease of changes. The technology for the hardware should have extensions for protoduction, the pilot run units for production shipments.

Figure 1 indicates relative performance levels for different tools and hardware. No method should be considered while totally excluding others. An example of a system requiring a full prototype is a cellular phone. Mapping an entire cellular phone into an ASIC emulator is not easy or realistic. The cellular phone has a DSP, either a standard product, or special core, a microcontroller, analog, high-speed analog, RF and other digital functions. All of the components are essential to properly model the phone operations. The form factor is an additional problem.

Available tools range from hardware simulation accelerators, to FPGAs for critical paths and FPID to allow relocatable interconnections and programmable probing, ASIC emulators, and custom emulator boards with bonded out cores and standard packaged parts. See side bar for more details on reprogrammable devices.

Figure 1. The different prototyping methodologies can process a wide range of system level clock cycles per second.

A problem with hardware technologies is their inability to meet system performance and operating requirements. Major sources of speed loss are improper I/O drivers, and additional wire loading from packaging and PCB interconnections. Programmable devices have speed, signal integrity, gate density, interconnect density, and I/O limits which require careful partitioning and multiple cuts at circuitry. The emulators provide a rich environment for debug and system integration.

Steve Goldman, Product marketing manager for Paradigm products, Zycad Corp. (Fremont, CA) says "Prototypes are developed for a number of reasons. The main reason is to perform a functional check to find problems and to confirm that the design performs its function to design requirements. "

Dasha Estes, director of product marketing, Quickturn Design Systems Inc. (Mt. View, CA) says "clocking-- especially multiple clocks, is difficult, since simulation assumes all clock edges are isochronous, but in most systems, clock edges are asynchronous. This can cause difficulty in getting prototypes to operate. Initialization is always a problem."

Geoffrey Bunza, vice president of engineering, Eagle Design Automation (Beaverton, OR) says "most systems designs are not new from the ground up--85 percent are redesigns. The migration from virtual prototypes to actual hardware is like the step from synthesis to an ASIC, there are no more intermediate steps available to optimize."

Henry Verheyen, vice president of engineering, Aptix (San Jose, CA) "The differences between prototypes and emulators is the difference between system and architecture evaluation(s) and functional verification. Designers need to evaluate the level of work versus the cost versus the value of the work. The time and cost to develop an accurate MPEG decoder model is very high versus the ability to get a working chip (set) to perform the actual function."

Standard prototypes allow functional checks in systems running a few megahertz. If you need a part with the proper form factor and system level speed for evaluation and system integrations, you may push your ASIC vendor for a fast turnaround on your wafers. Chip Express can make a Laser Programmable Gate Array (LPGA) in a day, while other ASIC vendors can, for a premium, make parts in as little as a week. Though a high risk and expensive option, its value is quickly achieving a final system configuration.

Even if the chip is not completely functional, having a few partially good die allows detailed analysis of complex system-chip-software interactions at full speed. Full-speed operation allows millions of system clock cycles to run in minutes, while providing a truer indication of chip delays and timing. The partial prototype may not meet all of the SDF files and timing constraints, due to the differences in wire loading caused by the inoperable sections, but can be a valuable test and validation link.

Analog issues: how to do a mixed signal prototype Prototyping methods described thus far reflect digital implementations. Analog and digital functions have been difficult to integrate because of their differing characteristics and signal domains, and differences in simulation environments. IMP Inc. (San Jose, CA) developed the EPAC devices to address the analog requirements of designers.

EPAC's most important aspect is its analog building blocks in a digital domain with programmable analog characteristics. Kang Chan, staff engineer at Xerox Corp. (El Segundo, CA) says he is trying to use EPAC to replace parts of a future analog and digital chip but cannot replace a complete analog system. He created a trial design in about 20-30 minutes to demonstrate functionality.

How to test the prototypes Before tape-out, and before wafer fabrication, the design team starts system debug and test development. The time working with a final system hardware prototype will yield significant details of circuit operation over what was available in simulations. A computer or processor based product may need an infinite number of vectors to check all its allowed states.

For some technologies, making contact to the ASIC pins is inherent in the vehicle. Besides software testing capabilities, logic accelerators and emulators offer cable connections to a logic analyzer. Stand alone FPGAs and other packaged parts require an interface from the packaged part to the test equipment.

Greg Peters, new product manager in the logic analyzer group at HP (Colorado Springs, CO) notes that the main function of logic analyzers is to probe the pins. The biggest problem is designers cannot trust the data. The worst case is the part works when the logic analyzer probes are connected, and does not when the are not.

Kent Dahlgren, director of marketing, I-Cube (Santa Clara, CA) says "A Field-Programmable Interconnect Device (FPID) makes an excellent interface to a logic analyzer, since its crossbar interconnections capability enables any pin to be connected to any other pin. The problem is the lack of software to quickly and easily reconfigure the FPID to move the logic analyzer probes to any other locations within the interconnection space."

Joe Bagliere, senior vice president sales and marketing at Emulation Technology (Santa Clara, CA) says that most of their customers need a way to get to parts on a board. One issue is the number of package pins continues to increase. The next level of interconnect density will go to a newer package. For pin counts over 300, the package of choice will be pin grid array (PGA), but will migrate to a ball grid array (BGA). For package pin over 400, the only forseeable package is the BGA.

Hardware - software interactions In the ASIC industry, virtually all fabricated silicon chips successfully execute their test vectors but less than half works in the system. The software-hardware interface may contribute to system integration failures as the ASIC-board interfaces notes Bunza of Eagle Design Automation. In developing an architecture, you must consider debug part of the design. You must build testability and verification capabilities into the IC and into the system.

R. Chandramouli, director of ESTA products, RASSP program at LogicVision (San Jose, CA) says "one problem is how to map Built-In Self-Test (BIST) into sections of a chip. This is easier in memories and other regular structures." As synthesis make gate level design more transparent, we need tools to generate new models and add the test structures to the design at the RTL level, he asserts. This leads to fewer changes and is easier to implement. "We need more transparency so the tools do most of the work."

Dan Hafemen, vice president engineering , IKOS Systems Inc. (Cupertino, CA) says in designing their own ASICs, they perform extensive simulations. They don't run software on their system, thus don't have the co-design problems. Hafeman says they use full scan in their ASIC designs. The scans are shifted out in either the simulated or the real chips and compared. Software examines variables in the chain and identifies which bits in the scan chain map to the variables, that identify individual registers.

Successful systems have a bottoms-up verification methodology to confirm all lower levels are bug free before going to the next higher level. If you don't take the rigor of this process the bug-fix throughput gets lower. The goal is to never find a bug at any higher level.

Hardware-software integration takes up to half of the design cycle. To address this problem, many companies are making from 10-20 prototypes so the software teams can integrate more code in parallel. A number of companies can convert an FPGA, or a number of FPGAs to a hard wafer. This addresses added delays resulting from interconnections and extra I/O buffers of signals going on and off multiple chips. It also fits the design in a single package which can be mounted in the system. This accommodates extra units needed for customer evaluations and first customer shipments.

The range of prototyping technologies allows a design team to work together on several phases of hardware, software and hardware-software integration. Hardware options are not mutually exclusive, except in a total cost budget item, and can enhance the team's ability to debug the ASIC and the physical and software interfaces. The best overall methodologies work from a top-down perspective and incrementally implement the prototype with bottom-up validation.

Tets Maniwa is a technical editor for Integrated System Design.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  September 1995