New Methodologies Drive First-Pass SOC Success

Systems on a chip require not merely new tools and strategies, but new ways of thinking about chip design. The necessary changes are going to require much greater cooperation across the entire industry.

by Lauren Brust

As the industry moves away from an ASIC approach and embraces the system-on-a-chip (SOC) technology, we are finding the transition neither easy nor painless. While designers still require an ASIC-like look, feel, and reliability from the SOC--as well as ASIC-like economics and time to market--the increased size and complexity of the SOC leads to several design concerns at each stage of development. To increase the chances of first-pass success with an SOC design, the design community must implement a new methodology that considers all aspects of the design from concept to silicon to ensure timely, cost-effective release of future chips.

The design flow for today's SOC first defines the chip at the behavioral level, then separates it into its software and hardware components (see Figure 1). The design then passes down independent paths for either software or circuit development, which includes functional design and verification, gate- and circuit-level implementation, and physical layout. Separate design teams most often handle each stage of the design process, with paper specifications handed from one team to the next along the way. Another team unites the hardware and software designs at the end of the process, to take them into prototype. While this methodology has worked well for ASIC designs, it faces severe limitations when used for SOCs.

In fact, the increasing importance of the SOC is driving the industry in a number of different directions. Design flows must now accommodate early consideration of verification, physical layout, and testing issues. Codesign is becoming a priority. The proliferation of point tools has increased the need for industry standards; similarly, intellectual property (IP) also needs greater standardization and documentation. Combine those issues with the need for timing convergence and the maintenance of signal integrity in the shrinking geometries, and the industry clearly faces an uphill fight.

Undefined designs

Defining the design up front is critical to a design's success. Such early decisions--which include the implementation of components, solutions, IP, partitioning, and interblock timing--require a great deal of time and expertise, especially without the aid of an automated tool set. Any changes required after the approval of the specification are both difficult and risky, and become increasingly problematic as the design nears implementation. Embedded processors and microcontrollers make changes even more difficult, because changes to parameters such as timing and partitioning in one part of the design could cause other parts of the design to break. Choosing the wrong functions at an early stage means that the design will experience a major reset down the line, with no quick fix available.

In addition, the increased complexity of the chip and the integration of various functions onto a single piece of silicon make it difficult to develop a comprehensive specification that often widely dispersed designers can

Figure 1 - The traditional SOC design flow
The traditional flow moves in a primarily linear sequence, with the software and hardware sides separating at the behavioral level and not integrating until the physical level, often leading to a large number of iterations.

carry throughout the design process using the old-fashioned pencil-and-paper method. Without such a specification, however, communication within a design team--as well as through the design process and between teams from different companies--may well be inconsistent. Today's tools must, therefore, enable not only the specification of a complex SOC, but the communication of that specification throughout the entire design process. The tools should thus integrate well with all of the other tool sets used throughout the design, since improper translation between tool sets can lead to inaccuracies in the final design, with potentially disastrous results.

Co-needs

The common practice in today's design process forwards paper specifications to two design teams: one responsible for functional design of the hardware, and the other for the software development. These teams progress independently, without integrating their efforts until after either emulation or production. In the world of the system on a chip, that approach is inefficient at best.

SOCs enable a higher level of integration, which often includes embedded programmable elements such as DSPs or microcontrollers, including multiple cores. At the same time, the complexity of software development continues to rival that of hardware development. Any problems that may arise in the integration between hardware and software represent too large a setback to wait for their integration at the silicon or emulation stage. The results often threaten the final product's time to market. It's therefore important that the design of the software and hardware progress together and that verification of hardware and software happens as early in the process as possible. Early detection can correct full-system errors without increasing the time line.

To add fuel to the fire, many of today's ASIC-centered design tools inadequately consider hardware and software. In leading-edge designs, the divisions between the hardware and software pieces of the chip are growing hazier as the pieces become more tightly integrated. However, today's tools tend to separate chip functionality into hardware and software, then ignore the software throughout the methodology. The failure to fully consider the SOC as a whole places the entire design in jeopardy.

Designers want to bring in IP from all sources--an in-house source, a silicon provider, or a third party. Unfortunately, IP from disparate sources often comes in disparate forms, written in different styles and languages. Because no standard governs IP development, it becomes difficult to integrate, synthesize, and verify several pieces of IP in one SOC. Often the IP needs translation or modification before the designer can use a particular modeling or verification tool, increasing the chance of error upon implementation.

Additionally, IP modeling is often inconsistent, differing in treatments of key elements such as delays and timing models. As a result, simulation may consider some delays multiple times while failing to consider other timing delays at all. This imbalance may lead to overly optimistic timing estimates or, conversely, designs that are too conservative.

What's the function?

The magnitude and complexity of SOCs have made verification both difficult and time consuming. Compounding the problem, the current deterministic, functional verification is proving insufficient to verify SOCs. Instead, the dynamic verification process must shift to incorporate pseudo-random techniques. These techniques, which handle corner cases and exceptions, must occur more frequently to identify increasingly subtle design problems and to ensure functionality of the entire system.

Models frequently lack the accuracy needed for thorough SOC verification. Of course, models that are too detailed slow down the verification process, so designers need models of the same block available at different levels of detail. Less-detailed models enable higher-level, behavioral verification, while more detailed models support functional verification. Designers must also be able to integrate the various levels of detailed models, to allow verification of the full chip along with the individual blocks.

Figure 2 - The SOC flow compressed
The redesigned SOC flow focuses on the need for communication and codesign at every step of the process, resulting in much tighter integration and thus fewer iterations.

Another major challenge lies in team management. As chips grow, a design team requires multiple types of expertise, including more designers and verification teams. The workflow of such a large team becomes difficult to integrate and manage effectively. Such teams require a solution to enable version control and management of the levels of abstraction in order to share block information across the team.

Timing-loop closure presents one of the greatest difficulties in SOC implementation, especially during the handoff from the register-transfer-level design to the gate- and transistor-level design. The RTL design partitioning--most often manual--facilitates multidesigner teams but occurs only along functional lines and doesn't consider the effects of layout and interconnect between blocks. Often, interconnects and timing receive no consideration until physical layout with estimated models. After synthes is and layout, the design team must then optimize the design to meet the timing constraints. In today's methodology, this optimization most often demands the return to the synthesis stage with back-annotation of the parasitic delays, causing an iterative loop that makes it difficult to converge on a solution that meets the increasingly strict timing requirements.

Signal integrity is also turning more complex as the number of global nets increases and the processes shrink. While temperature, Vdd, and transistor parameters traditionally determine circuit performance, SOC designs must take into account other parasitic issues such as dielectric, conductor height, conductor width, and material composition. Faster clock and signal edge-rates are leading to greater signal coupling, while scaled power supply voltages are increasing noise levels. Simultaneously, low threshold voltages and the rising use of dynamic circuits are leading to lower noise margins. These margins in turn exacerbate crosstalk, which can cause wide variations in signal delay, speed-related errors, delays from input of the driver to the input of the receiver, and a 40-to-60 percent rise-time at the input of the receiver. The glitches or functional failures that can result often prove insidious and difficult to detect.

The upshot is that SOCs can be very expensive and their design can take much longer than expected. The increased resources and effort required, along with the higher risk associated with today's methodologies, makes it difficult to keep pace with Moore's Law. And the situation will only worsen as the number of sockets decreases and the single-socket system becomes more of a reality.

A high-level methodology

Of course, this isn't to say that SOC design is impossible. At Lucent Technologies, we recently completed an SOC for a wireless terminal. It includes a 16-bit DSP, a 32-bit µC, an error correction processor, 50,000 ASIC gates, and more than 500 Kbytes SRAM, plus flash memory, PLLs, and more than 50,000 analog components. This chip also combines multiple programmable IP blocks. It posed all of the primary SOC challenges, including the combination of existing and new IP as well as software-programmable processors.

We have discovered numerous areas that require new methodologies and improvements to allow more ASIC-like results. We thus aim at a methodology that brings higher levels of automation and integration to all levels of a design and allows the design information to flow through the entire design process, driving toward seamlessly passing relevant information across task boundaries (see Figure 2).

The use of high-level tools at the start of the design process enables the capture of the specification and intent as early as possible. Such tools enable intelligent hardware-software partitioning and behavioral-level modeling and synthesis early in the flow. A significant benefit comes from the ability to experiment with alternate solutions while at high levels of abstraction, allowing changes to occur quickly and with minimal impact on time to market. The key is for vendors to integrate important IP with these tools to take advantage of the advanced capabilities. We have partnered with our tool vendors to ensure the integration of views of the IP blocks, whether our own or our partners', with the high-level design tools.

Having the right model for the right task for all of the blocks and IP used in a design is critical, especially at the high-level design stage. Each block must have available a high-level behavioral model for early architecture and specification development, a fast and accurate model for RTL design, and a synthesizable RTL model for the inclusion of soft macros. In current methodologies, the designers produce the blocks, then must often retrofit models to the designed block. This process requires more resources and may induce errors, since the designers must reformat similar information to match the target application. As design technologies become more complicated, the models must include more types of information, meaning more variables to translate. Fortunately, emerging standards such as OLA (Open Library API) and CHDStd (Chip Hierarchical Design Standard) show the strong potential to minimize the development by standardizing the interface of library (OLA) and design data (CHDStd) across the industry, thereby restricting the representation of data to a single well-recognized format.

Functional verification

Some new verification techniques also show promise. Formal verification, using both equivalency checking and model checking, is helping design teams find problems earlier in the process. Equivalency checking looks to see if two circuits function similarly, by decomposing them into primitives to see if they are similar. The technique greatly reduces the risks stemming from modifications made late in the design cycle to optimize for timing or to accommodate an ECO. Model checking uses a high-level representation of a circuit, then ensures that, based on its primitives, the circuit will perform a given function. Though less mature than equivalency checking, model checking can cover corner cases more thoroughly, supporting a design that is correct by intention and not by brute force verification. Model checking also enables the design team to establish what verification tests to run and how to functionally verify the circuit.

Several new static verification tools--which can run in conjunction with standard verification tools--have reached the market. Some of the RTL analysis tools evaluate code coverage, providing a speedy way to ensure that verification exercises each piece of the code. Code coverage data helps designers to determine whether a piece of code is necessary, or whether a major piece of functionality escaped verification. Other tools grade the vectors, identifying which vectors exercise the most code and should accompany the design into fabrication. Automation of such functions can facilitate quicker testing at the fab, resulting in a faster time to market. Other RTL tools pinpoint difficult circuit structures, such as gated clocks, to ensure that the design has taken them into account. After identifying and analyzing the circuit structures, the design team can determine their benefits or pitfalls and thus their proper usage.

Models and tools now available for hardware/software codesign and coverification ease integration and operability. System- and function-level teams coordinate in the use of these tools to guarantee the top-to-bottom verification of the embedded software and the interfaces between the hardware and software. Similarly, emerging test-bench automation tools are simplifying the management of vector creation. The tools work well late in the design cycle, but ideally the design team uses the tools them from the beginning of the process and throughout the project to reap their full benefits.

Perfect timing

Timing-loop closure poses one of the major challenges to the implementation of systems on chips. Relying on the current procedure of placement and routing followed by optimization can present unpredictable outcomes for large SOC designs because of the complexity of the designs.

Several new processes are improving the estimations for timing-loop closure, most importantly the use of floorplanning up front in the design process. Designers previously estimated the loading and impact of the physical design through the characteristics of the circuit, but floorplanning can attend to other timing-related factors such as the number of wires and wire length. During the floorplanning stage, the functional designer should act as a consultant, to pass on design information that a standard ASIC design handoff can't capture. Such communication can help to ensure frequent first-pass timing convergence.

Wireload models have also helped with timing-loop closure. Wireload models depend on statistical data taken from a variety of sample designs. A single capacitance value represents a wireload model for a given fanout. Some of the models are area-wireload models, where the capacitance value varies according to the area of the circuit. The accuracy of the wireload model depends on how well it mimics the prelayout design to achieve a precise postlayout result. One current issue is how to accurately generate wireload models; one wireload model doesn't fit all design problems. Designers are pursuing many options, including design-specific wireload models. The problem with such models is that the statistical sam-ple depends on one design, potentially leading to greater errors.

Our solution is to offer several tuned wireload models, enabling the designer to select a model that most closely mimics the design. First, the designer develops the "wiring profile" of the chip through floorplanning, then uses the profile to benchmark against the standard wireload model. If the match isn't sufficient, the user chooses from a library of wireload models based on a significant amount of data, rather than on a single-instance custom wireload model. Using this technique, we've experienced better matching of prelayout to postlayout results over custom wireload models.

Naturally, along with timing comes signal integrity, the complexity of which makes this a difficult and time-consuming piece of the verification puzzle. In response, we have developed Web-based tools that automatically analyze factors such as clock skew, crosstalk, and interconnect delays. Our designers simply check a list of options and feed their files to a central supercomputer that performs the analysis automatically and returns the results in a three-dimensional, color-coded format that allows for easy review and correction. These tools allow us to test and correct the signal integrity of a design in hours rather than days, and we have also experienced greater success in going to silicon. Our goal for the end of the year 2000 is to be able to test all aspects of signal integrity in a complete SOC design in an unattended overnight run.

Fast emulation

Once the design work is complete, the designer needs a way to verify the total system. Traditionally, this effort has cost at least as much in time and money as any portion of the design process. If a design goes to mask and doesn't function properly, the required respin can add several months to the design process and cost as much as $250,000.

As an alternative, we are using laser-programmable system chips (LPSCs), which combine the benefits of laser-programmable gate arrays (LPGAs) and standard cells in a single system chip solution. Basically a two-layer-metal programmable gate array, the LPGA can be programmed through either mask or laser technology, with a compiler to automate the core generation process. Using a mask prototyping flow, we can modify metal layers four and five at a cost of less than $50,000 per iteration. For single-piece prototypes, laser programming can occur in less than a week for about one-fifth of the expense and time required for an all-level change. Once the system verification is complete, the mask process can turn out volume product of the new design using the base created for prototyping.

Many of the design issues become more manageable in a hierarchical SOC design methodology. Managing complexity and tough deep submicron issues at the block level and then integrating the blocks at the chip level fulfills the design needs of an SOC methodology. A hierarchical approach can bring in blocks from IP sources or from previous designs without the need to merge the complete detailed view into the design flow. One key lies in strict modeling standards, which produce design systems and libraries that encourage design reuse and hierarchical design. The design methods also support chip-level integration, including mixed-mode simulation for single simulation with models at various levels of abstraction. The procedure allows the coverification of large, complex cores along with ASIC logic and system software. Chip assembly methods also support the hierarchical physical design using block-level place-and-route methodologies.

New horizons

While the industry has taken several steps to approach SOC success at the first pass, areas such as integration, modeling, IP, and verification still need a great deal of work.

Customers generally want tighter integration with the silicon provider throughout the entire design and verification process. Under the current methodology, the designer often develops a system specification that includes a system definition, IP selection, and partitioning--then hands off the specification to the silicon provider. Until the completion of the silicon, the process minimally involves the customer. Chip complexity and size make it difficult to hand off an entire knowledge base during various stages in the process. Modern design flows no longer support a well-defined front end and back end with simple handoffs of netlists and timing constraints. Dedicated silicon providers must now enter the process as early as system specification, and continue to work closely with the customer throughout the functional definition and verification.

The industry must also work to create an interface standard for industry-wide high-level modeling. Such standards would enable designers to define the design at the highest level, then feed the information down through the process into specification and partitioning tools, as well as to the simulation and verification tools further down in the process. High-level system modeling using C and C++, currently used only internally by systems designers, is receiving more attention from EDA vendors as a possible solution to the standardization puzzle. C makes an attractive option because most designers know C, and C runs faster than behavioral languages. C also integrates well into VHDL and Verilog. Once a standard is established, vendors can pursue tools to address high-level design and synthesis. In any case, standards are critical.

Additional formal verification methods will ensure that design teams define as many problem areas as possible before moving to silicon. At the same time, because of the critical need to perform verification expending minimal time and resources, RTL analysis must occur earlier in the process. Timing verification should automatically analyze all types of circuits. While today's timing verification methods are successful for synchronous, single-clock designs, they don't consider hierarchical chip-level verification and interblock interfaces for asynchronous or multiclock design. Since the process isn't automated, designers must review a multitude of flagged areas and fix problem spots, a process that requires a great deal of time and effort and which generates increased potential for user error--especially when under a deadline. Likewise, tools must automate the testing of SOC structures.

Timing-loop closure requires a means for allowing designers to better estimate the effects of the physical design earlier in the process. Also needed is a means for adjusting the timing in the physical design, to allow the design or verification tool to address inaccuracies that may exist. Such a method demands the tight integration and easy passage of information among high-level definition tools, through modeling and simulation. While certain tool vendors enable the passing of these timing algorithms between tools within their own suites, the industry requires the ability to pass timing information between tools regardless of the vendor, thus enabling designers to choose the tools they consider best in class. Standards are currently evolving, but must emerge quickly in a final form to realize the benefits for the industry.

Finally, the silicon community lacks strong support of IP blocks. The ability to reuse previously designed and proven blocks, often with functions driven by standards, is essential to achieving SOC integration. Providers must understand that they need to deliver IP as complete packages supporting verification at all levels as well as timing and physical modeling. Current offerings or libraries are often incomplete, leading to customer frustration and design delays.

The challenges will continue to mount as higher levels of silicon integration bring more of the complete system onto a single chip. For the near future, creating competitive designs will require the development of stronger design methodologies today and the partnering with providers able to fill in the gaps and address the next set of design tool solutions. We need to continue to integrate the full set of capabilities into a coherent, seamless flow. With new design systems and methodologies in place, the industry will be able to produce next-generation SOCs faster and cheaper, enabling the customer to receive the greatest return on investment and best optimize the time-to-market window for their latest product designs.

Lauren Brust is director of design systems and methods for Lucent Technologies' Microelectronics Group in Allentown, Penn. She has worked with Lucent/AT&T for 20 years. Her previous responsibilities have included IC design, standard cell library design, FPGA software development, and design systems and methods.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to jeff@isdmag.com.