Lately, a lot of attention has been given to reducing the time-to-market for ASIC development. In this context, the topics of design reuse and improved design methodologies are often mentioned. Moreover, different standards and approaches to design reuse and improved design methodologies have been documented in various forms recently, and by numerous organizations. It is evident from all this activity that there is more than one possible concept and outcome for reducing ASIC design time.

In the area of design reuse, there is a wide spectrum of possibilities. For instance, some companies justify the added effort to develop a robust reusable ASIC core since it will be unaltered and reused many times. Meanwhile, other companies have every expectation that an ASIC will be modified in the future, in which case the extra effort to make the design reusable can be detrimental for time-to-market constraints.

For design methodologies, new tools intended to improve overall design time or quality are continually being introduced. As well, adjustments to an existing design flow will impact ASIC development time. Looking at past ASIC design efforts to identify weaknesses in the design process can yield improvements in future development time.

In the Teradyne memory test division (Agoura Hills, CA), we examined data collected from several ASIC designs that we recently completed. To help identify some of the current ASIC reuse concerns, I'll describe the background for the ASIC design environment we worked in, the data collected from these recent ASIC development efforts, offer some conclusions and some possible future directions.

The ongoing question

Over the years, Teradyne has designed dozens of digital ASICs. In that time, we've used several vendors to fabricate our various ASIC designs. Although, to some extent, using different ASIC vendors can result in different design flows and design methodologies, we've been able to adhere to common tools and design flows. These general features allow for some degree of comparison and estimation of ASIC design parameters from one generation of ASIC to the next.

Furthermore, the unique requirements of a test-system product and the semiconductor test market impact design- for-reuse in such a way that Teradyne ASIC designs incorporate three general reuse ideas: a blend of reuse, a new design, and modified reuse. This conglomeration results from the need to add new or enhanced features along with design reuse for higher levels of integration. Consequently, some obvious trends have emerged where the size and complexityýas measured by number of gates, frequency, number of pins, team size, and design timeýhave increased. The ongoing question, however, relates to the not-so-obvious trends. Are we improving the overall time-to-market for a given level of performance?

Risk factors

We have completed eight digital ASIC designs in the past three years. At a minimum, a completed ASIC design refers to a fabricated part. However, in some cases, a completed ASIC design includes full hardware and software system-level debug. A summary of the ASICs under examination is given in the table.

Gate count was determined using the associated ASIC vendor's derivation. We recognized that minor differences in gate count could occur between different ASIC vendors for an identical ASIC. However, gate count provided a reasonable metric for the relative size of each ASIC.

Further, referring to the table, the team size refers to engineers consistently involved in the ASIC design and doesn't include people who assisted in short-duration tasks. An example of a short-duration ASIC task would be preparing a netlist for fabrication requirements.

The number of engineers on an ASIC team was relatively small for two primary reasons. First, in order to complete the planned projects, the available engineers had to be distributed among the required ASIC designs. The ASIC design framework also contributed to therelatively small team size. Specifically, a small core-team of engineers was dedicated to each ASIC design from architecture to tape-out, with assistance from internal and contract specialists. This framework provided exposure and cross-training to the core-team members and for the different aspects of ASIC design. Each team also had previous design and industry experience. In general, each team consisted of a mixture of veterans and novices. The distinction is further defined in the table notes.

We didn't have a strict definition between what constitutes new ASIC design and design reuse. In general, if an existing ASIC was going to be modified to add a new feature or enhancement, then we considered that as design reuse. On the other hand, we considered an ASIC design to be new when significantly new features were to be implementedýand there was no prior ASIC as a basis for modification.

We simulated all of the ASIC designs referenced in the table using a chip-level testbench. Ideally, we would have also performed a system-level simulation on all of the ASIC designs. In practice, the system-level simulation required input and coordination with applications, design, and software engineersýall of which had limited availability for such an effort. Additionally, since not all parts of the test-system product had simulation models, compromises to system-level simulations were necessary.

Naturally, the two major goals for each ASIC design were working silicon and on-time completion. Interestingly, the smallest ASIC had first-pass working silicon. Factors including small ASIC size, correspondingly small team size, and design reuse decreased the risk even though the engineer designing the ASIC had minimal previous experience. Clearly, the single-engineer design team incurred inherently less communication and coordination overhead. Meanwhile, the "A" ASIC had to be redone twice.

Other factors, regarding the "A" ASIC that were noted, but not captured, in the table were: poor reuse documentation, issues with functionality and timing, moving to a new technology that affected the entire ASIC design, and a schedule that didn't allow for complete understanding of the base ASIC that was being reused.

Reuse versus new design

In order to get a better understanding of design reuse, we made a detailed assessment of what categories of an ASIC design were indeed reusable (see Figure 1). A brief background of the ASIC design reuse categories starts with architecture, which refers to block-diagram or system-level reuse. The percentage of architecture reused for any given ASIC design was estimated by comparing block diagrams of an existing ASIC design versus a new ASIC design and looking at the similarity of functional blocks.

Next, the program model represents the registers within the ASIC that are under software control. Again, a comparison of existing to new software-controlled registers was made to determine a percentage of reuse. This was complicated by the fact that software controlled registers in some reused ASIC designs were deleted, or added, or both. Synthesis code and testbench code are similar with respect to reuse. For these categories, the amount of code that was utilized from the existing ASIC design as a fraction of the code in the new ASIC design determined the percentage of reuse. In some instances, an existing ASIC was represented as a symbolic schematic which resulted in a zero-percent reuse of synthesis code.

There was no reuse of the CMOS tools and relatively little reuse of CMOS process for any of the ASIC designs. The tools category refers to foundry and methodology tools (for example, a design-rule check program). The CMOS process refers to the foundry and feature size for the silicon. Lastly, the team experience category relates to each particular engineer's experience with the existing or similar ASIC design.

Naturally, some category estimates were cruder than others due to the difficulty in quantifying certain aspects of an ASIC design. However, examining the average reuse-estimate for each ASIC was revealing in two respects. First, for the architecture and implementation categories identified as reusable, we saw that new

Figure 1 - Category Reuse Average

The program model, architecture, and test bench categories proved to be the most reusable areas of our designs.

ASIC designs had an average reuse estimate of below 15 percent, while reuse ASIC designs were generally above 30 percent. Thus, a measurable distinction between new and reuse ASIC design is possible. This second trend noted: for the reuse ASIC design cases, the average estimated reuse was still below 60 percent. Accordingly, even for situations considered as ASIC design reuse, there was typically more than 40 percent of new design involved.

Looking back to go forward

One criterion that we'd focused on in past ASIC designs was tracking schedule tasks and time. Reviewing past history provided valuable insight for future tasks. We created schedule templates that listed specific tasks and their associated time estimates based on past schedule data for related or similar ASIC designs (see Figure 2).

In general, there was a wide discrepancy between actual- and estimated-schedule times. In fact, the overall average underestimation was nearly 63 percent.

Surprisingly, we found that the average design time estimated for new ASIC designs was closer to actual-design time than for ASIC design reuse: 54.5 percent versus 67.5 percent respectively. Part of this result was explained by the fact that, initially, we believed that less uncertainty existed in the ASIC design reuse cases. After all, we knew more about the existing designs to be modified than the start-from-scratch new designs. Using this theory, we paid less attention to schedule estimates for reuse ASIC design. However, as was discussed previously, we discovered that even in reuse cases there was a fair amount of new design.

In addition, there was a common issue for all the ASIC designs that contributed to actual design times exceeding estimated design times. Specifically, we largely underestimated the time in physical design required to achieve timing closure and to eliminate manufacturing-rule violations. In reviewing the individual ASIC efforts, there were a number of reasons for the physical-design schedule disparities. For the most part, on this round of ASIC designs, we became much more involved in physical design than in the past due to a planned change in methodology. Since physical-design issues were new to us, gaining experience and understanding required time not originally planned for.

An example from a representative ASIC design provides more detail. In the case of the "D" ASIC (see Table), we estimated the physical-design time to be three to five weeks, though it actually took 8 weeks. The biggest delay came from correcting slew violations. Aside from clock distribution, we didn't do much advanced planning in the area of signal fan-out. Although the available software tool performed adequately in correcting large fan-out nets, it didn't do so for nets that went to 10 or less inputs. As a result, we needed to manually increase the drive level of cells, or add additional cells, to drive nets with a small number of inputs that had a large-capacitance load due to a long overall net length. The difficulty was compounded because each physical-design iteration often had more slew violations introduced as a result of adding new cells to the design. The "D" ASIC team also discovered that there was an undocumented requirement to improve observability of a scan-chain element, thus adding to the original time estimate.

To be sure, there were also unique issues for the ASIC designs that contributed to the discrepancy between actual and estimated development time. For example, in the case of the new "D" and "Ca" ASIC designs, the definition phase took longer than anticipated. These ASIC designs were started as the entire product was being defined. As a result, the ASIC design specifications and requirements changed frequently, causing unplanned time for analysis and design updates. These changes were especially detrimental when they occurred later in the ASIC development since the amount of design data had increased from the beginning.

Figure 2 - Actual versus estimated ASIC design time

Interestingly, the average estimated design time for new asic designs was closer to the actual design time than the estimated design time for reuse designs.

Where does the time go?

It's reasonable to expect that ASIC design schedule estimates become less accurate as the anticipated time to complete the ASIC increases. For example, the longer it takes to complete synthesis, the more chance there is for the cell library to change, adding more unplanned time to absorb the change. Knowing which tasks take longer provides a divide-and-conquer opportunity to improve schedule estimates.

To begin with, we divided the ASIC development into six broad classifications. The definition classification pertained to architectural decisions, block diagrams, and data collection. The implementation classification was for synthesisýincluding generating constraints, source code, and associated scripts. The test classification dealt with tasks related to creating, modifying, and executing testbenches and test vectors. It also covered timing verification. The process classification related to methodology issues (for instance, concept and design reviews). The vendor classification covered such things as transferring netlists, executing design-rule check software, and parts of the physical-design phase. It should be noted that we didn't strictly define these categories from the outset, so the data is not precise. As well, we had difficulty tracking the time spent in the physical-design phase since a significant portion was done by engineers outside the core ASIC design team. There were a number of iterations during this phase.

We weren't surprised to find that definition for design reuse took less overall-time than new designs since design reuse already had some elements of the ASIC defined. Similarly, it made sense that design-reuse test took a greater percentage of the overall schedule than new design because design reuse required the understanding, modifying, and executing of extensive- regression testing. The vendor category for design reuse was approximately double the average for new ASIC designs, partially explained by lack of a crisp distinction between the categories. For example, physical-design time may have been tracked in the "other" category. Additional explanation comes from the fact that for all but one of the design-reuse ASIC cases, a new technology was targeted. Subsequently, extra time was spent in accommodating the requirements of the succeeding technology. For example, since trouble with timing closure due to the layout of the "A" ASIC was not anticipated, it took even more time to solve than if the problem had been identified from the start.

No slam dunk

Once we analyzed the results of these ASIC designs, it was apparent that there were unique issues for each ASIC that had a negative impact on time to market. There were also key issues affecting time-to-market that were common to the ASIC designs in general. Logically, a future focus on improving the common time to market issues will provide the most leverage. Thus, although we did not identify a "slam dunk" fix for a more rapid time to market, our next round of ASIC development will provide focus on the following:

• There's a lot of "new" in design reuse. Don't assume that modifications to an existing design are trivial. As well, unless you know that the prior design was properly documented for reuse, allow time for learning and finding mistakes in prior, suspect documentation. For the test-system business that Teradyne addresses, ASIC designs tend to be modified more than strictly reused. In other words, it is more efficient to document and complete a design for modification than to invest the substantial extra time for added documentation, increased design robustness, and the additional process discipline required for rigorous design reuse.
• Properly size the ASIC design team. The team sizes for the given complexity of ASIC designs were too small to effectively complete the required tasks on schedule. Further, it's almost universal that the number and intensity of tasks are initially underestimated. So, this increase places an even greater load on an already small team. For the future, our goal is to have less ASIC designs due to higher integration, with subsequently more team members, concentrating on specific tasks.
• Don't underestimate the time required for physical design. Initially, we gave a lot more thought to logical design than to physical design. As well, the extent of our involvement in physical design was not well understood and we brought minimal experience to this aspect of ASIC design. In the future, each ASIC team will have engineers dedicated to physical design.
• Create simple and well-defined tracking categories. We created schedule templates for this round of ASIC designs. However, we gave minimal consideration to how this data would be used for future improvements. For example, we didn't have a distinct category defined for tracking the time spent in physical design. In the future, ASIC schedule templates will include physical design as a defined tracking category. And, as significant new categories emerge, they will be identified and defined as well.