How to manage a derivative SoC project

Rather than scrap their existing design tool investments and start over, many companies have opted to contain SoC development costs by adopting a "platform chip" strategy, whereby modifications to chip architecture are tailored to suit specific markets. That in turn demands that in order for SoC products to be competitive, the design process must be as efficient as humanly possible.

However, managers who attempt to deliver this efficiency inevitably slam into the same obstacle: the limitations of physical design. The term "derivative" can have a broad range of meanings and require vastly different levels of re-engineering depending on which phase of the design process is affected.

An additional digital/analog converter or a new piece of soft IP may be architecturally trivial, but adding them to an existing chip can be quite laborious from a physical design standpoint, resulting in SoC derivatives that appear completely new. This impression is compounded by the fact that physical designers have often found it difficult to reuse their work, causing the layout of the platform chip to seem like a bottom-up, back-to-the-drawing-board project"a further drag on efficiency. Grappling with the ever-burgeoning problems of design complexity poses another major challenge for those who must manage the process, not to mention the intricate details associated with working on the nanometer scale such as signal integrity, IR drop, and electromigration.

Much has been written about design reuse in software and RTL design, but tales of lessons learned in the area of physical design are hard to come by. Being the last group in the chip design chain, the physical design team is often in the pressure-cooker state of having to compensate for the schedule slips of others and get the product out the door. Before the advent of the platform or derivative SoC, this could be accomplished through the blunt-instrument tactic of throwing more people at the problem, since there was no need to worry about porting anything to the next design.

Not anymore. The improvised solutions of simpler days just won't fly in the age of SoC platform chips. The time has come to lift physical design to the same level of productivity available to software and logic engineers. Mangers need to know where the design stands at any given time and how well it is working so they can bring in the right people to solve problems, make adjustments, and keep the project moving quickly and economically.

Success dictates that managers become extremely competent in four key areas:

• Developing realistic project plans
• Assembling the right resources and managing them efficiently
• Measuring progress in a way that delivers a finished chip "on time, on cost, and on spec"
• Reusing the methods and knowledge gained from previous designs

Defining the challenges

Planning a strategy. The great Prussian general and military philosopher Clausewitz famously wrote that even the most carefully laid battle plans never survive the first encounter with the enemy. This axiom is equally true for chip project planning. The unpredictable nature of the physical design process makes the planning process inherently difficult. The enormous number of tasks necessary to complete a large physical design project must all be identified and described, while the volume of details that need to be worked out creates a significant potential for error.

One way to deal with these challenges is to create a global project plan that is predicated on much more focused, detailed plans covering very short periods of time. The global project plan will identify the major milestones and the tasks required to reach them. Based on the experience with prior versions of the SoC, the global plan can also provide a schedule estimate for a tape out date.

Trying to predict a specific date for tape out at the beginning of a large SoC project may appease upper management, but it is virtually impossible to forecast with any degree of accuracy. A better approach is to specify a probable target date with a reasonable range of time on either end. Detailed plans should be formed for smaller time increments, such as two-week intervals, and managers should expect them to be fluid and dynamic. This both takes into account the uncertainties of the process and leaves room to redirect workflow as the design evolves.

Other tools and techniques include ensuring that RTL and physical design are created in parallel, and that milestones are defined by the maturity of the netlist, IP, and layout.

Mustering and deploying resources. The complexity of a large physical design project also makes it hard to accurately and confidently plan resource requirements. For instance, a physical design team manager may find that he does not have enough expert engineers to complete his project within a reasonable amount of time, or that their areas of expertise are not the ones required. He may also discover that it is not possible for him to use his people, machines, and EDA tool licenses efficiently because he cannot predict when these resources will be needed or how they should be brought into play.

Good managers know that people are everything on a project. The right teams deployed in the right way will yield the greatest chance for success.

Measurement, assessment, and adjustment. Once a project is launched, the most crucial task for the design manager is to understand the state of the project with respect to the plan. This requires the ability to measure what has been done, assess the progress against the goals of the plan, and make any necessary adjustments.

On a complex SoC project, this process can be quite vexing. One needs to know what has been completed, and more importantly, the quality of what has been completed. Without a method for "measuring" the state of the project quickly and repeatedly, the prospects for success are sharply reduced.

The answer is fast iterative design. This technique is similar to large software projects that compile and run regressions every night. By building the full-chip design frequently and measuring the results, one can exactly gauge the quality of the design at any point in the project with little cost. Tools are emerging to automate the GDSII construction process that are much more automated than traditional scripted environments.

The realities of reuse. At the highest levels of the SoC physical design process, very little of the design environment infrastructure can be used for more than one project. This is especially true if derivative designs are created by several groups in different geographical locations. And even at the lower levels, specific scripts tend to be customized for a specific design and may prove useful only to the person who originally wrote them. It is the rare physical design team that can afford the additional resources required to make environments and scripts reusable by engineers working on the next derivative.

Improving reuse requires the right tools. Resources are becoming available to make reuse in physical design not just possible, but practical.

The design maturity workflow model

To improve predictability, quality, and throughput, the design manager needs to create a workflow that recognizes that chip designs mature over time. The underlying assumption in the design maturity model is that the RTL, IP and chip's physical design are all being designed concurrently. Each team is refining and correcting their respective part of the design.

In a traditional concurrent model as shown in Figure 1, the physical design process doesn't begin in earnest until after the other parts of the design process have begun. The physical design team receives the front-end design team's partially completed work. They know they have to live with changing design attributes (netlist, IP, specs) until the tape is shipped off to the mask shop. The physical design team's work will often continue for a significant amount of time after the "front end" work is complete.

To improve the traditional concurrent workflow, we have defined a four-phase design maturity model. This model is at the heart of the project planning and measurement process. Each phase begins with the deliverables appropriate to that phase.

Team activities specific to the respective phase carry the physical design process towards its goals, which are the deliverables for the next phase of the physical design process. A phase is concluded when all goals for that phase have been achieved. It is quite common for overlap in phases to occur for varying components and goals of the design.

The design maturity workflow model breaks down the SoC design process into four successive standard phases: Setup, Convergence, Refinement, and Closing. The following chart describes the start of phase deliverables and goals for each phase — all of which can be adjusted to suit the requirements of a specific derivative or "from scratch" SoC project. The deliverables and goals (milestones) along with the associated dependencies may be entered into a standard Gantt chart to a level of detail desired by the design manager or project leader.

People and team structure

The team structure for conventional hierarchical physical design has individual blocks assigned to certain engineers, who then are responsible for their blocks throughout the entire workflow. We have found it more effective to use an approach that focuses on chip-level design, which a fast iterative design methodology affords. In so doing, it is most effective to organize a team as follows.

The core team should be comprised of:

• A top-level engineer, who has the final responsibility for top-level engineering, including pad ring, power, and floorplan.
• A timing analysis engineer who is responsible for overall chip timing closure.
• An analysis engineer who has a broad area of responsibility with physical verification, timing analysis, and power analysis.

• Die size and number of place and route blocks
• Clocking strategy and the number of clocks
• Custom work and the handmade aspects of the SoC design process
• Quality (analysis required)
• Project goals
• Schedule

The peak team size will most likely occur during the convergence phase when blocks are frequently built, analyzed, tweaked, and rebuilt. Ideally, the team size should begin to taper down in the refinement phase, when certain people are hammering out the last few problems.

The individuals on a typical SoC design team might play the following roles with particular tasks and responsibilities:

• A chip lead provides the required strong technical leadership and has the overall responsibility for the chip design. This individual might not have enough time leftover to work on the chip itself.
• The top-level engineer has the final responsibility for top-level engineering, including pad, power, and top floorplan.
• Two place and route engineers are responsible for the place and route blocks on the chip.
• The timing analysis engineer is responsible for timing constraints and simple verification.
• The analysis engineer has a broad area of responsibility with formal verification, timing, EM, and IR analysis.

The simple fact is that you do not really know where you are on your chip project until you have built it using your sign off tools and, just as importantly, analyzed those build results. Only then can you run your analysis tools to determine where you really are. In a conventional flow, this step is labor intensive; it can take three, six or even nine weeks to assemble the full chip for a complex SoC.

The solution to this problem is to automate chip construction so that you can build the chip overnight. This is exactly what RTL and software teams do: recompile their code overnight. A similar 24-hour construction capability has only recently become available to physical designers. By building and analyzing the results more frequently, a tighter iteration loop can occur with the front-end team realizing a significant schedule savings.

Project reuse

A primary shortcoming in physical design is that there is little physical design knowledge reuse from project to project. Without some team continuity, reuse pretty much starts and ends with "hard" macros. In addition to having at least one individual from the old team on the new team, derivative chip design needs reuse of the following:

Standard design environment. An environment with standard directory structure and naming conventions enables team members to navigate the physical design process and find relevant data with ease. Standardized design of SoCs and blocks provides instant familiarity with chip and block design for physical design teams.

Addressing these four needs makes it possible for physical design knowledge from prior projects to be easily transferred and modified to suit new projects.

Conclusion

The design maturity model provides an excellent way to plan and systematically measure where the design is at any point in the process. Matching the correct team, both size and skill set, to the SoC plan is also required to assure success and maximize the overall project efficiency. A fast iterative design style makes measurement easy and enables engineers to do what they do best" solve problems, while allowing design managers to make the necessary plan adjustments that always occur on a complex SoC project.

Case study
10M gates, 225MHz, in 20 weeks

This SoC project was primarily intended to be a productized version of the initial design that was fabricated. While some new and updated hardware IP was incorporated into the design, the focus of the efforts was to insure that all design quality criteria were met in this second version of the chip. Specifically, timing closure, including crosstalk effects and robust EM/IR analysis, were objectives that had to be achieved. As is usually the case, schedule was also of paramount concern.

Planning
Although the planning for this project was based on the design maturity milestones, it was also unique in that this version of the SoC was a limited redesign of the prior version. Many input design deliverables were able to reach a higher level of maturity earlier than in a traditional concurrent design, but there were deliverables such as final timing constraints that followed the typical pattern of not being finalized until the design was almost ready to tape out.

The original schedule was broken down as follows:

In a more traditional concurrent design, the setup phase would be shorter and the convergence phase would be longer than shown above. The schedule above was based on the fact that the physical design process was started mid December (generally a poor time to start a project) and hence the project would not hit full stride until early January. It also considered the high quality of the initial deliverables, which were the final outputs from the prior version of the design.

Resources
The project team was structured as follows:

Project Lead Engineer

• Day to day technical coordination of the project
• Overall responsibility for timing closure

Top-level Engineer

• Padring, power grid design, pre-routes, overall chip floorplan, full chip DRC/LVS

IP Librarian

• IP inspection, library creation, DRC/LVS of IP

Place and Route Engineers

• One for high speed interface block
• One for clock distribution module and top-level clock distribution
• Two for other place and route blocks

Timing Engineers

• One for high speed interface block
• One for overall timing closure

Analysis Engineers

• Two for tasks such as formal verification, EM/IR, DRC/LVS

The team utilized the ReShape hierarchical floorplanning, optimization, and automated build environment. All project source data was under configuration management using Perforce. The underlying place and route tool was the Astro suite from Synopsys. PrimeTime SI was used for timing analysis, and Mentor Graphics Calibre was utilized for physical verification. The server pool consisted of primarily high performance Linux servers, although Sun servers were utilized for those jobs requiring large amount of memory. LSF was the queuing environment.

Project "temperature readings"
Each design maturity model phase of the project required certain criteria to be achieved before continuing into the next phase. In some cases the criteria applied to the entire design, while in other cases it was applicable to individual place and route blocks. To accurately determine whether a milestone had been met, we built full-chip and/or block-level GDSII using the production place and route tools and performed the appropriate analyses.

On this project, ReShape's PD Builder and PD Optimizer facilitated rapid full-chip GDSII builds from revised netlists and/or modified design specifications. The team was able to rebuild the design from netlist two to three times per week to run analysis tools such as PrimeTime SI, Formality, AstroRail, and Calibre. This rapid and accurate feedback enabled the team to uncover issues as early as the setup phase.

Final results
The design taped out in 20 weeks, four weeks later than the original plan, but meeting all of the stringent quality requirements. This delay was due to a variety of typical factors including some late deliverables, the usual EDA tool issues, very late stage ECOs, and certainly some execution problems on the part of the physical design team. Overall, the project was viewed as a success and produced the high quality silicon that the customer required. The chip came back from the fab and worked across the temperature and voltage range.

Lane Albanese has over 15 years experience in integrated circuit design and design management. He has worked for Raytheon, Number Nine Visual Technology, and Philips Semiconductors. During his five and a half year tenure at Philips, Lane was the Director of IC Engineering for the group that designed the PNX8500 Set-top Box and Digital Television SOC, which won the EDA Consortium 2002 Design Achievement Award.