Bob Eisenstadt, Principal Engineer, Alchip Technologies Inc.
Jim Bailey, Chief Operating Officer, Alchip Technologies Inc.

Application-specific IC (ASIC) design schedule estimates are often inaccurate, which impacts projections of design costs, product release dates and product revenues. Many ASIC suppliers have program management databases that are used to help estimate future ASIC design schedules. Most ASIC design schedule estimates assume there is a strong correlation between time to completion and design complexity, as measured by gate count, memory bit count and clock frequency. An internal study of ASIC design projects completed by a fabless ASIC supplier in 2008 has also revealed a strong correlation between the time from final netlist to Graphic Design System II (GDSII) release and the maturity of the company that is providing the netlist. For example, it took almost twice as long for Tier 3 companies' designs to progress from final netlist acceptance to GDSII release than it did for designs of similar complexity that were provided by Tier 1 companies. This article will present project and schedule data, discuss reasons for Tier 1 versus Tier 3 schedule variations, and propose heuristic rules to help improve schedule estimation.

The ASIC project schedule data presented in this article is based on final netlist-to-GDSII database release for projects completed by a single fabless ASIC supplier during 2008. The ASIC supplier's 2008 project database included 28 projects, of which 19 were from Tier 1 companies, four were from Tier 2 companies and five were from Tier 3 companies. Tier 1 companies are classified as large, well-established companies with major divisions and/or product groups providing and supporting multiple product lines of varying maturities. Tier 3 companies are classified as small start-up companies that are focused on developing and introducing new technologies and products. Tier 2 companies lie somewhere between Tier 1 and Tier 3, in terms of size, product maturity, product line breadth and so forth. Please refer to Table 1, which provides design and schedule data that has been averaged across companies in each tier.

Table 1. Time for Designs from Final Netlist to GDSII

The average final netlist acceptance-to-tapeout time for Tier 1, Tier 2 and Tier 3 companies was 31 days, 45 days and 61 days, respectively. The differences between Tier 1 and Tier 3 companies, including schedule delays, are more pronounced than differences involving Tier 2 companies. Therefore, this article will largely focus on analysis and comparison of Tier 1 and Tier 3 companies, as their differences are more instructive.

The data in Table 1 shows that design complexity, which is largely based on average gate count, average memory bit count and average clock frequency, is reasonably consistent across the different company tiers. The average Tier 3 gate count is 11 percent higher than the average Tier 1 gate count. If one assumes linear scaling, this would account for about three days of additional schedule delay. The average memory bit counts in Table 1 show substantial variation across the different company tiers. However, memory instance counts are relatively small, so memories have a large impact on the floor plan and die area, but would only add a few more days to the average Tier 3 schedule due to increased floor planning efforts and tool run times. The average Tier 1 clock frequency is only 8 percent greater than the average Tier 3 clock frequency, which is too small to have a significant impact on design turn times. On average, Tier 1 designs use more advanced process nodes than Tier 3 designs. This may result in minor increases in Tier 1 design cycle times due to more extensive design verification requirements, and minor increases in Tier 3 cycle times due to greater timing closure challenges with older process nodes. Overall, the differences between average Tier 1 and Tier 3 designs are too small to explain the 30-day gap between Tier 1 and Tier 3 final netlist-to-GDSII release times.

All the data in Table 1 comes from the same fabless ASIC supplier; therefore, all projects used the same design methodology and design flow with similar gate utilization and routing density targets. Furthermore, the design implementations were done with similar design teams and staffing levels that were led by the same program management team. It follows that all major design complexity and design implementation variables for Tier 1 and Tier 3 companies are too similar to explain the differences in final netlist-to-GDSII release schedules. The only remaining major variable that can explain the scheduling differences is the tier of the company releasing the final netlist. The next step is to explore the differences between Tier 1 and Tier 3 companies and their engineering teams to understand the underlying causes for the large differences in final netlist-to-GDSII release times.

There are countless major differences between Tier 1 and Tier 3 companies, including their design teams, so this article will focus on the differences that influence netlist stability and quality, which has a huge impact on netlist-to-GDSII schedules. Many Tier 1 companies' projects are based on earlier versions of existing projects plus enhancements and upgrades, which provides a stable project baseline and path to develop a high-quality netlist. Tier 1 companies often have internal physical design teams, which enables them to choose which design projects should be supported in-house and which should be outsourced to ASIC suppliers. Tier 1 internal physical design teams are much more likely to support the development of their company's most advanced design projects since these require tight engineering feedback loops. Projects that involve enhancements and/or upgrades of existing designs are more suitable for outsourcing, which means Tier 1 companies are often positioned to outsource designs that have relatively clean, stable netlists. Most Tier 1 companies also have comprehensive project definition and acceptance criteria, where project features, specifications and target market requirements are carefully reviewed and approved. Once a Tier 1 project is approved, it is very difficult to make major design changes. This results in a more stable set of design objectives, which further improves the stability and quality of Tier 1 netlists. As previously stated, most Tier 3 companies are start-ups that develop and deploy new products and technologies. By definition, new products and technologies can't rely heavily on pre-existing products and solutions. Therefore, unlike many Tier 1 companies, most Tier 3 companies don't have the luxury of leveraging existing design projects. Most Tier 3 companies also can't justify the investment in internal physical design teams and electronic design automation (EDA) place-and-route tools. Thus, the physical design work from most Tier 3 projects is outsourced regardless of design and technology maturity. To develop the customer base for their new products and technologies, small Tier 3 companies need to be nimble and flexible. For example, what would happen if critical customer XYZ agrees to sign a contract to purchase major quantities of ASICs from start-up ABC, but only if ABC's ASIC targets a different package? If start-up ABC doesn't have more attractive opportunities, ABC's design team would end up reworking their input/output (I/O) ring design to support the new package. The start-up's design specifications and netlist would need to be updated, and this would increase the Tier 3 company's final netlist-to-GDSII schedule.

There are also major structural differences between Tier 1 and Tier 3 companies. Tier 1 companies have usually already completed similar design projects, so they have existing design flows and cohesive design teams. Tier 3 companies often develop and debug their design flows in tandem with building their design teams. Furthermore, Tier 1 companies have more access to engineering resources and EDA tools; and over time, many have learned to staff ASIC projects at reasonable levels. Many Tier 1 companies' staff engineers have narrow but deep design expertise, but most projects include a few key engineers and/or managers with wide, deep experience that direct the design team and pull the project together. To preserve cash flow and manage the scarcity of funding, Tier 3 companies must minimize expenses. Most Tier 3 companies also have a few key engineers and/or managers with wide, deep experience that pull projects together. However, additional engineering and EDA tool resources are usually very scarce. It follows that Tier 3 design teams don't have the necessary bandwidth to run as many systematic and exhaustive design checks as Tier 1 companies, which impacts the stability and quality of Tier 3 final netlists. In addition, the lack of resources at Tier 3 companies also limits their verification, debug and problem-solving bandwidth, further delaying their netlist release-to-GDSII tapeout schedules.

Heuristic rules that can help improve the schedule estimation process will now be presented. Schedule estimation is often a quirky subject since interest in project schedule accuracy, or realism, is largely dependent on a company's culture and the dynamics between sales/marketing teams and design engineering teams. Schedule estimation accuracy spans from firms consistently using highly optimistic best-case scenarios and assumptions, to firms striving to maximize schedule accuracy and predictability. If one is fortunate enough to work in a company that prefers accurate, realistic schedules, then as a first cut, start with Tier 1-style schedule estimates, which are based on gate count, frequency and memory bit count. If this first cut schedule estimate is for a Tier 2 or Tier 3 company, then factor in an appropriate amount of upward scaling. For example, a Tier 2 company that has disciplined, well-staffed marketing and engineering teams should have schedule estimates that are closer to a Tier 1's schedule estimates. A Tier 3 company that has scarce engineering resources should have longer design schedules, so their projects should need more schedule scaling. If one works for a company that generates schedules based on cascaded assumptions and highly optimistic best-case scenarios, then improving schedule estimation accuracy will be far more problematic. There will probably be strong internal resistance to the sudden shift from highly optimistic schedule estimates to realistic schedule estimates. Initial efforts to improve schedule estimation accuracy should focus on shifting from highly optimistic best-case schedule scenarios to very aggressive but feasible schedule scenarios. The previous discussion tends to reflect poorly on the engineering, marketing and sales teams of Tier 2 and Tier 3 companies. However, most of the design, marketing and sales teams at these companies are very dedicated and try to make strong contributions regardless of their company's circumstance. Much of the disparity among Tier 1, Tier 2 and Tier 3 schedules is due to circumstances well beyond the control of the design, marketing and sales teams. Efforts to improve underlying ASIC design turn times are more likely to succeed when the focus is on planning and problem solving, rather than on confrontation.

In conclusion, final netlist-to-GDSII release and schedule data for 28 company designs was presented. These 28 companies were grouped into Tier 1, Tier 2 and Tier 3 categories, and the average design complexity was similar across designs within the different company tiers. An ASIC supplier's turn time from final netlist-to-GDSII release to a foundry was fastest for Tier 1 companies and took approximately 50 percent longer for Tier 2 companies and 100 percent longer for Tier 3 companies. This suggests modifying existing approaches used to estimate final netlist-to-GDSII schedules that are solely based on gate count, memory bit count and clock frequency, and trying to scale schedules upwards to account for designs from Tier 2 and Tier 3 companies. Companies and their ASIC engineering teams differ in many ways, so judgment will be needed to tailor schedule scaling on a case-by-case basis. Interesting topics for further study include design schedule completion times across company tiers for front-end design projects, as well as projects starting from initial netlist acceptance-to-GDSII release.

About the Authors

Bob Eisenstadt is a principal engineer with Alchip Technologies Inc. Bob previously worked in a wide variety of design and consulting positions at VLSI Technology, Radius, SGI, 3dfx, Silicon Image, Virtual Silicon and Qthink IC Designs. Bob holds a B.S.E.E. from Cornell University and an M.S.E.E. and MBA from Santa Clara University. Bob Eisenstadt can be reached at bob@alchip.com.

Jim Bailey has been with Alchip Technologies Inc. since 2007. Prior to Alchip, he worked for Virage Logic, Cadence and ETA Systems. Jim has held such positions as general manager, vice president of field operations and, most recently, chief operating officer. Jim holds a B.S. and B.A. from St. Cloud University in St. Cloud, Minnesota. Jim Bailey can be reached at jim.bailey@alchip.com.

http://www.gsaglobal.org/forum/2009/3/articles_eisenstadt.asp