Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

When infrastructure is essence: Open-Silicon automates the flow

Posted: 16 Sep 2005 ?? ?Print Version ?Bookmark and Share

Keywords:open-silicon inc.? methodology? tool? ic catalyst? design module?

To some engineers, "methodology" simply means a general approach to design. To others, it suggests a specific sequence of events, perhaps even a specific sequence of particular tools and completion criteria.

But in the most abstract sense, methodology should refer to all of the inputs and events that shape the final design. This wider definition includes not just design files, but also coding practices, switch settings, scripts, procedures for dealing with exceptions and results from runs, and the specifics of management involvement in the design flow.

Organizations also vary in the degree to which they formalize the layers of methodology. In some teams, what happens between a senior designer and the tools!changes in switch settings, directives or constraints, interpretation of warning messages, tracking of errors!is a purely personal matter. In others, task assignments, license use and server allocation are up to the individual managers or are simply first come, first served.

For Open-Silicon Inc., these aren't personal matters. "We want to be able to document 90 percent predictability and 100 percent reliability on our designs," said president and CEO Naveed Sherwani. "To achieve that, we can't rely on the skills of individuals to only make positive changes in the methodology. We have to have a single, disciplined process from design inception to end of life."

"Discipline" in this case doesn't stop at training and personal responsibility: it means automating all of the decisions and control flows that happen in support of the data as it moves through the design process. That effort has been undertaken by a team led by director of engineering for methodology Ravi Srinivasan.

Srinivasan's team pulled together a number of major components for the task, including a commercial workflow package, a knowledge-based system and a proprietary graphical user interface. The overall package, which the team calls IC Catalyst, provides, in Srinivasan's words, "a complete workflow automation environment, including revision and version control, measurement of results, and notifications to management and designers."

The package is composed of three modules: Design, Silicon and Technology. The Design Module, already deployed at Open-Silicon's facility in Bangalore, India, governs events and flows within the Open-Silicon design process. The Silicon Module, still in development, will similarly govern transactions involving vendors: foundry information, prototype management, test generation and release to production. The Technology Module will identify technological changes and adjust IC Catalyst to respond.

Peeling back the covers on the Design Module indicates the depth to which IC Catalyst automates the design process. The module includes four major subsections: configuration, flow, resource and program management. Together, the tools and practices create an automated system that begins running when the customer design first touches the Open-Silicon process and continues to guide every step until the design's end of life.

Configuration management addresses what many designers see as the most critical issue: version control!not just of tools, but of settings, directives and scripts-revision control, data integrity and security. A foundation layer in the Design Module provides default switch settings for all the tools used in the flow. For the switches marked critical, if a designer alters the default settings, the project manager is notified so that the decision to deviate from the standard flow can be reviewed.

At the end of a tool run in which switches have been altered, the flow system is triggered, causing the results of the step to be captured by the knowledge-based system and compared against results for other similar designs. If the results are notably better, the settings used are captured and integrated into the defaults. This lets designers wax creative during the exploration phase while still protecting the integrity of the flow. Because all settings are treated as managed data sets right along with the design data, the flow system can re-create exactly the result of any experiment the design team performs. It is also responsible for dependency tracking, so that an engineering change order ripples through the design correctly without forcing a complete rebuild.

This comparison process depends on a characterization done at the beginning of the flow that categorizes the design according to a set of about 20 parameters that have been distilled from Open-Silicon's experience in ASIC implementation.

In parallel with these processes, the resource system checks out licenses and servers task by task, influencing the workflow to make sure that everything stays on schedule, but with a minimum of resources.

"In most design shops, license utilization runs at about 20 percent," Srinivasan said. "We are running at 80 percent simply by scheduling tasks to keep all the licenses in use as much as possible and avoiding peak loads."

Extensive reporting and outcome estimation power the program subsystem, a management tool that gives both the project manager and the customer hour-by-hour, task-by-task visibility into the project. Results, successful or not, are reported, so that both manager and customer know just where the process stands on any given day. This is vital, according to engineering VP Satya Gupta, because if a customer sees a design bog down in a particular area, changes can be offered to get the process back on track. This is far more effective than having the design team beat their heads against a wall until word trickles back to the RTL designers that a module isn't placing or routing.

Another aspect of the program subsystem is cost reporting. By eliminating iterations due to version issues, inappropriate or incompatible switch settings, stray constraints and all the other non-design issues that bedevil real-world design teams, Open-Silicon hopes to drive down the cost of each design.

Another benefit of IC Catalyst is of particular importance to Sherwani. Since the entire system!including accumulated knowledge of the designers, the pattern of management interactions and details of version control!is on a disk, Open-Silicon can pick the entire Bangalore design center up and replicate it in another location, such as China or Latin America. This gives the fabless ASIC company something of the leverage enjoyed by a conventional chip company. Open-Silicon can increase revenue by adding readily available skilled designers.

For Sherwani, formalizing every detail of the design process and restricting designers' choices to those that are actually needed for the design constitute a key business strategy. And it appears to be a satisfying way of life for the designers. "We have lost only two designers out of a staff of 63 in Bangalore," Sherwani said.

The CEO believes that the model will also work well in other cultures, but not in Silicon Valley. "Silicon Valley rewards breadth of experience, not depth," he said. "No one wants to do the same task often enough to get good at it.

"In the end, that is why Silicon Valley will lose the global competition."

- Ron Wilson

EE Times

Article Comments - When infrastructure is essence: Open...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top