You’ve heard it a hundred times: “Lower the costs, complete the project on time and don’t make any mistakes.” This is the mantra of just about every product development organization in the world. Within the semiconductor industry this translates into lowering product lifecycle costs, getting designs taped out on time and avoiding bugs that require respins, according to a recent International Business Strategies (IBS) survey [1].  Achieving these formidable objectives requires design teams to continue to improve design productivity and eliminate errors in their work product.   An important component of improving productivity and reducing errors is having easy and real-time access to key project data that design teams can leverage into smarter decision making.  At the same time, there’s increasing recognition that not only the technical leaders need consistent project visibility, but business and management leaders do as well.  An unpredictable, poorly timed product release can have the same dire consequences as a very late one.  Tools and/or processes that can automate and present a common, unbiased view of key project metrics to the entire team of project stakeholders are especially valuable. That’s where visualization can help.

Sorting through the terabytes of data generated during a chip design project in order to extract the most useful information for both engineering and business groups is a non-trivial task.  Delivering that information in a manner that can be easily understood by all is key to making it useful.  By using intuitive, graphical interfaces and viewing important information pictorially, even the most complex data can be turned into useful and digestible information from which quick and correct decisions can be made.

Besides providing greater visibility for better decision-making, a well-designed GUI and reporting infrastructure tuned specifically for chip design projects enables engineering teams to ramp up on the design flow faster and better manage it. GUIs can help you locate where to add or remove resources for more efficiency and to improve communication amongst team members (including those globally-dispersed) to minimize errors.  Easy setup and automation are essential so that the design team can focus on design and not be burdened with administrative overhead. 

This article describes some of the capabilities required of a design visualization tool. While it uses Synopsys’ Lynx Design System to make the examples more concrete, the principles and benefits described apply generally to visualization tools and techniques in the broader context.

Take Back Control of Your Design Flow

There has been an exponential increase in flow complexity as the semiconductor industry continues to progress into smaller and smaller geometries. Add hierarchical designs with complex IP into the mix and it paints quite an intimidating picture for those responsible for executing ASIC design programs. Never have there been so many tools, scripts and settings and never has it been more important for them to all interoperate seamlessly.

A GUI interface that controls the design flow is a powerful way to manage this complexity. For example, a useful way of visualizing flows is in the form of a flowchart (see Figure 1). This flow diagram shows a place-and-route flow where ‘T’ indicates a flow task and ‘B’ indicates a branch in the flow enabling parallel execution of tasks.  Users can create, configure, execute, monitor and debug design flows with this easy to use interface.  In addition, the flowchart representation of the flow can be readily re-used for design experiments.

Figure 1: A graphical design flow showing a place-and-route flow. Environment enables easy creation, configuration and debug of flows

There are thousands of lines of scripts in a typical design project, but design teams typically edit only a select set of options within them. The rest can be left as sensible defaults. Rather than have design engineers wade through all of the scripts to make changes, a well designed GUI can display these scripts graphically. For example, each task (such as placement or clock tree synthesis) will have certain settings that can be modified via the GUI without requiring the users to modify scripts at all. By hiding the complexity of the flow and exposing only the most useful aspects of the design flow via the GUI, the productivity of the user is improved significantly while reducing the possibility of errors.

Finding the Best Floorplan

The quality of a floorplan can make or break a design, so it’s no surprise that a lot of effort is spent making sure that the design has a high quality floorplan. Imagine that a design engineer wants to experiment with five different floorplans. Traditionally, the engineer would have to:

1. Create five separate copies of the initial floorplan script
2. Manually edit the floorplan exploration options in each one of them
3. Create five different run areas so they all don’t overwrite each other’s results
4. Execute the five different runs one by one
5. Manually parse through the logs and reports and find out the timing results, wire length and other important metrics
6. Record the metrics in a spreadsheet to compare them side by side
7. Pick the best floorplan

Looking over the steps, the only valuable use of the design engineer’s time is the last step: picking the right floorplan! The rest can be automated.

With a powerful visualization GUI, the design engineer can manipulate tasks graphically and create copies of tasks. With a few clicks, the engineer can set up five experiments or more with relative ease. The engineer might end up with a flow where all the experiments run in parallel (see Figure 2). With floorplan experiments, 99 percent of each floorplan script is exactly the same. The engineer typically makes changes to only one or two options in the whole script. Rather than hard-coding the options, they can be passed to the script via the GUI allowing the use of the same script for multiple runs. With a few clicks and some changes to specific options, the engineer is ready to execute. That’s one half of the equation. The engineer can leverage the metrics recorded for the various floorplan runs and create a graphical report (see Figure 3) that compares all the various floorplan experiments against each other and makes a decision virtually instantly. No parsing, greping or spreadsheets.

Figure 2: An example of executing multiple floorplan alternatives in parallel.

Figure 3: Tabulated results comparing results from various floorplan experiments. Enables designers to make quick decisions on best floorplan for a design or block.

 

What Gets Measured Gets Improved

Given today’s multi-million gate designs, each run generates mountains of data but there are only a few key metrics, or critical pieces of data, that need to be extracted in order to ascertain the status of the design. An effective methodology to capture these key metrics is to embed the “capture” capabilities directly into the flow itself. In this way, the critical metrics data are captured automatically and consistently across the team and organization. From the designer’s perspective, this is a background task which requires no effort. Of course, the choice of which metrics to capture is vitally important. The type of information of value to the project team includes:

1)      Current stage of the design (placement, clock tree synthesis or routing)

2)      Quality of results (QoR) to indicate the quality of the design, such as worst negative slack (WNS), total negative slack (TNS), area, utilization and power

Once metrics have been extracted and saved, the next step is to display them. The objective is to make it easy to access the saved data and create meaningful reports even if the underlying design data is deleted or changed.  For example, using a global SQL database server for storage makes it easy to record and process metrics. A robust relational database implementation also inherently enables multiple projects or users to concurrently access and update metrics.

An intuitive interface to create meaningful reports from the extracted data is required if design teams are to reap the full benefit of the recorded metrics. One must be able to create reports that make sense from an ASIC design project standpoint for both the engineers as well as the management chain.  An effective solution is to use report templates that display metrics of the user’s choosing.  Figure 4 shows an example of a flow execution in a Gantt chart. With this report, design teams can understand the order in which tasks were executed, the bottlenecks in the flow and how the team is faring with respect to schedule.  For example, based on prior run experience, if a particular task is taking a long time to complete, this may indicate a possible issue with that task and may warrant an analysis of recent changes that were made to this task.

Similarly, another flow visualization example is a pie-chart of runtimes across all the blocks in the project (Figure 5).  In a single report, the team can see how they are spending their time and effort.  These reports can be exported or saved in standard file formats allowing project managers to compare tool flow runs for different blocks and identify potential issues or bottlenecks.  Ideally, the report can be saved and run many times over the course of the project to communicate the current status graphically.

Figure 4: A Gantt chart of a design flow execution offers visual feedback on execution order and potential bottlenecks.

 

Figure 5: Pie-chart reports enable tracking of time spent at each step (ie. synthesis, design planning, place and route, finish) of the flow across multiple designs or blocks.

 

What’s the Project Status?

Once a flow is deployed and design execution is in full swing, the persistent questions of “where are we?” and “when will we be done?” need to be addressed. The quintessential example is a project manager preparing for a weekly project status meeting.  Without the right tools, this manager would have one of two unenviable choices:   a) email every engineer on project for their status and cobble that together into a couple of slides (attempting to reconcile incomplete or conflicting information) or b) look through the run areas and reports and try to determine the status on his own. The worst part of either approach is that it will need to be repeated every week.

With the right metrics captured, the design manager need not trouble his team or harvest metrics himself. The manager can save his time, and sanity, by using the metrics captured to create his own, customized report. Synopsys has found a dashboard report like the one in figure 6 to be an effective means to quickly understand project status and health. This graphical report displays the critical QoR metrics across blocks and tasks with color coding to represent current progress against stated design goals.  In this format, each row represents a particular metric, such as WNS, and each column represents a step in the flow. At the intersections, one can find the value of the metric (optionally compared to its target) for a given block. Using the right color codes allows project managers to understand the project status even before looking at the numbers. For example, using the color green for a metric that has met or bettered a specification and the color red for one that has not, is effective and intuitive. Using yellow to indicate metrics that haven’t met the specification yet but are very close adds more depth to the information on the 2D dashboard. 

Figure 6: Dashboard status report

In the above dashboard status report, each cell has two values. The upper value is the actual metric extracted from the design. The lower value is the target value for the metric set by the project manager. Take power (row 4) as an example. The manager has set 2.4mW as the target power dissipation for this design with 0.05mW tolerance. When tracking power as the design progresses through the flow, the power is within limits until PlaceOpt and, therefore, is colored green. After ClockOpt, the power is greater than the target but is less than the tolerance (2.45mW) and hence this cell is colored yellow. In subsequent steps, the power has exceeded the tolerance limit and is colored red. In this way, the designer can easily pinpoint what step caused the power to exceed the acceptable tolerance and can quickly modify the design to fix it.

A Paradigm Shift

The current way of executing designs is already starting to overwhelm design teams and it’s only going to get worse as design projects continue to become more and more challenging. A new paradigm is needed to help design teams wrest back control of their designs, flows and schedules. Leveraging tools with visualization capabilities for chip design can improve all aspects of the design project, from executing flows to analyzing project status. Such tools, which are tailored to make chip designers and their managers more efficient and productive, allow design organizations to spend more effort on creating differentiating product features and be better prepared for product rollout.

 

References

[1] Design_Implementation-IBS-2010-07

 

About the author:

Aditya Ramachandran is a CAE for the Lynx Design System. Prior to joining the Lynx team at Synopsys, Aditya had 6 years of experience in ASIC methodology and technology development.

• 
• 
• 
• 
•