Using standardized design flows to cut time to tape-out – and speed design-flow evolution

By Steve Cline |  No Comments  |  Posted: July 25, 2014
Topics/Categories: IP - Design Management, EDA - IC Implementation  |  Tags: , , , ,  | Organizations: , ,

Steven Cline is a senior design automation Manager at Altera’s Austin Technology Center, focusing on design-flow automation for traditionally placed and routed blocks and custom FPGA IP used on Altera’s advanced FPGA products.Steven Cline is a senior design automation Manager at Altera’s Austin Technology Center, focusing on design-flow automation for traditionally placed and routed blocks and custom FPGA IP used on Altera’s advanced FPGA products.

Altera develops FPGAs that use the most advanced manufacturing processes available to deliver the density and performance our customers require. Recently, Altera started working with Intel as a foundry partner to access its 14nm finFET process.

It takes careful design management to develop new FPGA families on leading processes as quickly as the market demands. Altera has been using an internally developed design-management strategy, using make-based flows, to help automate the process of going from an RTL design to a GDSII tape-out. This works, but is proving to be expensive to develop, support and maintain, especially as the demands of deep submicron processes keep adding complexity to our flows.

Lynx on trial

At the end of 2013, Altera decided to try out Synopsys’ Lynx Design System, to see whether it could do a better job of supporting our rapidly evolving design flows. The design-management team had a number of concerns that they wanted to address during the trial:

  • Would it support all the third-party tools we use in our flow?
  • How good would it be at collecting design metrics and visualizing them in a dashboard so we could track the progress of a design through our flow?
  • Could it work with the foundry-specific utilities that we were introducing to work with Intel’s foundry offering?
  • Could it work with our resource-management system, our load-sharing facilities, and our implementation of IC Manage for revision control?

Here’s what we learned during the trial.

Third-party tool integration

It turns out that integrating a third-party tool into the Lynx environment is fairly straightforward. We asked one of our CAD people, who had just been trained on Lynx, to integrate Conformal LEC, a third-party equivalence checker, into the tool.

We wanted Conformal LEC to work within a flow defined by the following principles:

  • It must be able to run Conformal LEC to completion
  • It had to understand pass/fail
  • It had to be able to report errors
  • It had to be able to support us adding custom metrics to our LEC runs and report them to the Lynx dashboard

We also wanted to demonstrate that it was easy to modify the scripting environment and files necessary to control LEC, and that we could take metrics from this flow and route them to our dashboards as necessary.

Despite not having worked with Lynx before, the CAD engineer we assigned this job was able to integrate Conformal LEC, build the templates, build the scripts, automate its use, and test it to ensure metrics were being populated into the dashboard, in two days.

Integrating Intel foundry rules

As with every foundry, Intel has specific checks and utilities that it wants to run on our data. We needed to ensure that we could integrate these without Lynx getting in the way.

The integration was straightforward. In Lynx, all the process variables are already defined and available, so if you want to run a custom script and you know what variables you need to work with you can look in the system, find what you need, and re-use them. It also means that everyone is pointing to the same variable for the same process file, such as a don’t-use list, so that everyone uses the same list throughout the flow.

It was also easy to add variables to Lynx. This has the added benefit of giving you time to think about why you are adding variables. Should you be adding a variable? Is it task-specific, or something the system needs? You can answer those questions at the time you are integrating the new variables into Lynx.

Other Lynx insights

What else did we learn during the trial? The Lynx Design System seems to be well thought out – each time we needed to add something, or try a different way to control something, Lynx had an answer.

The tool is robust. It’s been more than six months, and we have yet to have a problem with Lynx.

Metric collection is easy. You can add metrics into any task script with a simple message line, which Lynx will parse from the log files. The resultant metric is then available on an SQL server that you have access to through a client and web-based application.

Design-flow evolution

What about the bigger picture? Altera’s design automation group is charged with helping the design teams get their jobs done as quickly and easily as possible. There are two ways we could achieve this: create a golden reference flow and insist everyone uses it; or offer a golden flow, but allow the design teams to modify it as they see fit – at their own risk.

We’ve taken this second approach, and found that Lynx provides a useful way of tracking the results of doing so. For example, the Lynx Design System has a consistent environment that makes it easier to support multiple users. We can give specific guidance about how to override the flow, and then see what users actually do. This means we can quickly work out how to correct any overrides that cause problems.

This approach strikes a useful balance between our efforts to make design teams’ jobs easier by standardizing the flow, and inadvertently suppressing the innovations they feel they need to do their work.

For example, IC Compiler derate tables can be overridden locally by the user. There are many reasons why this might be needed, and giving users the flexibility to change this can help them improve the optimization of their designs.

The IC Compiler derate tables used for timing are set by the project lead and delivered to the user by the Lynx flow. The user can edit their local version, but our flow will ‘audit’ this file for changes and notice if the user has deviated from the one delivered.

The script and override-control processes in Lynx include auditing, which we built into the flow, so we can see how design teams override the baseline flow, and which options and variables they changed.

This means that when we undertake a post-mortem analysis of a design project, we can have faith that a team followed the prescribed flow. It also helps us develop our golden flow - if many projects are overriding it in the same way, maybe we need to make that adjustment part of a new baseline flow.

Knowing there is a change is half the battle. We can speed up communication about changes in the default flow through local delivery of files, auditing and flow automation.

The future of Lynx at Altera

Synopsys’ Lynx Design System is now the design-flow solution of choice offered by Altera’s design automation group. It is currently being adopted by the design teams, who are working with us to debug some of the features of the place and route flow as we move to Intel’s 14nm finFET process.

We think of Lynx as an RTL to GDSII engine but it is much more. Lynx is a robust automation environment that can be used to automate any flow. Over and above RTL to GDSII we used Lynx to build a custom- and cell-based design physical-verification environment based on IC validator. We have also had interest from other design teams about using the Lynx Design System for library-characterization and modelling, and IP regressions.

The use of Lynx is making it easier to develop and maintain workflows that help our design, verification and other teams to do their work. The auditing capabilities in the tool mean that this is a dynamic process. We can use the Lynx Design System to track the evolution of our design teams’ approach to their work, and so understand how we ought to develop our golden flows to match.


Steven Cline is a senior design automation Manager at Altera’s Austin Technology Center, focusing on design-flow automation for traditionally placed and routed blocks and custom FPGA IP used on Altera’s advanced FPGA products.

Prior to Altera, Steven was a senior design engineer at Texas Instruments developing ASIC flows and working on large-scale design tape-outs, as well as a physical implementation product engineering manager and consultant at Magma Design Automation and Synopsys, respectively.

Sign up for more

If this was useful to you, why not make sure you're getting our regular digests of  Tech Design Forum's technical content? Register and receive our newsletter free.

Comments are closed.


Synopsys Cadence Design Systems Mentor - A Siemens Business
View All Sponsors