Home > Articles

  • Print
  • + Share This
This chapter is from the book

Design Flow Integration

Hugo:

The problem is this. The IC design engineers seek to assemble the best-in-class tools for their design system. This means picking one tool from vendor A, another tool from vendor B, and so on.

Most EDA tools read in one or more design files (file of design data). The tool or the designer may generate additional data and then write out an enhanced version of the design file(s).

Each tool arranges the file data in a specific way (format) for fast operation. The different tool functions are generally sequential, with the data passing from one tool to the next. (However, recent tool suites are trying to do more things concurrently.)

Most EDA tools are developed independently of each other. Design groups use various scripting or programming languages (such as Scheme, SKIL, or Perl) to stitch the tools together into a design flow. A design flow is the sequence of specific design tools used.

These scripts translate the data from one tool format to another, call up the correct files, and initiate the EDA tool operation. The scripts provide the glue that simplifies the tool design flow for the users. They also reduce the amount of tedious, error-prone manual work in running and using EDA tools.

Tool integration scripts would be easier to write if tools communicated in a standard way. However, most tools were developed independently with little concern for a standard interface or file format. (There is no standard scripting language, either, by the way.)

An analogy would be different paper filing systems. Suppose I keep a file of newspaper articles organized in three folders by date, author, and newspaper. Suppose you keep a file of articles all in one folder, arranged by date, subject, author, and article length.

I wouldn't know how to find something in your files, and you wouldn't know how to find something in mine. However, some of my articles would be of interest to you and vice versa.

With data files, the data representation (numbering, units, location, coding) may also be dissimilar. Here, I will sketch you a picture of what I mean. (See Figure 3.3.)

Tool 1 data files may have data items such as:

Name: Gate31

Netdelay: 0.3

Location: G78

Block #: 300

Chip #: ACD&

Tool 2 data files may have similar and dissimilar data items such as:

G78

Gates— 31, 33, 36

Dly— 300 psec

Revision— 88

The number and order of items and the specific data format in each file are different, and each file may have data which the other does not.

So, as you can see, even though the data items contain common information, EDA Tool 1 cannot read the data file of Tool 2. A utility program or script is required to translate the data.

Nora:

Are there no standards?

03fig03.gifFigure 3.3. Lack of Tool Interface Standards

EDA Tool Interface Standards

Hugo:

Yes and no. There are some. Standards help ease the task of assembling a workable EDA design flow.

Tool users or tool vendors, or both, usually create standards. There are always issues of vested interests, politics, resources, and competing standards groups. Other issues include testing conformance to the standard, vendor and user adoption, and so forth. Standards take years to create and may be obsolete by the time they are done!

Some standards are created after the industry fights over competing approaches. Then they settle on a standard approach, although it might not always be the best technical solution.

Other interfaces become de facto standards simply by broad acceptance and use. An example of a de facto standard is the GDSII (Graphic Design Station II) format. It is used for the graphical layout data of IC masks. (However, there is an effort to replace it with an improved and more compact standard format.)

An example of a planned EDA file standards group is the Electronic Design Interchange Format (EDIF). This is a human-readable file format developed to enable cooperating semiconductor manufacturers to exchange data. Although not intended to be an EDA tool interface, it has been widely used for that.

Vendors who offer a suite of interoperable tools also provide interfaces (often proprietary) between their tools. They may support an interface to read data in from other vendors' tools. This would bring the design data (and the customer) into their tool suite.

However, it is not usually in their interest to write data from their tools to a competitor's tool. They might lose the customer. Therefore, although many vendors claim EDIF compatibility, it has been mostly read-in only. (The company Engineering DataXpress has long provided translators and other services based on the EDIF standards.)

Nora:

So there are “semi-standards”?

Hugo:

I guess you could call them that. It's a little like railroad tracks. Historically, different railroads used different types of tracks. Each railroad “standardized” on their type of track. However, a train could not move from one company's track to another! Passengers had to switch trains.

In the 1980s, the industry really tried to create a universal interface.

Frameworks

 

The ASIC Council is a small (seven or eight members) consortium of the largest ASIC semiconductor manufacturers. In the 1980s, the council sponsored the Silicon Integration Initiative, Inc. (SI2). It worked on a universal framework into which users could easily plug in different vendor tools.

However, the result was multiple vendor proprietary frameworks, instead of a single framework standard.

Nora:

So standards have not always succeeded. Is there at least a common database for all the EDA data views?

Design Database Standards

Hugo:

A good question. The answer is—not yet, but that may be coming. Usually each tool's files have an internal arrangement of data items (data structure) optimized for that tool. The data structure affects how fast the tool works. It also affects how easily different tools can (or cannot!) exchange data.

Some vendors have a proprietary database to which all their tools can talk (interface). As more multivendor tools need to work together, a common design database becomes more important.

An open, universal database would be a great improvement for users. There are significant technical and business implications, making this a difficult standardization goal. Several existing databases or access methods are being considered in a couple of standards committees.

Nora:

Are there several standards groups?

Standards Groups

Hugo:

Yes, many of them. With new ones forming all the time, some compete with each other. As one industry pundit said, “The best thing about standards is that there are so many of them!” I'll mention just a few groups:

 
  • The Institute of Electronic and Electrical Engineers (IEEE). Primarily for hardware designers, it has developed hundreds of standards.

  • The Joint Electron Device Engineering Council (JEDEC), a division of the Electronics Industry Association (EIA). It has electronic product standards of all kinds (48 different committees).

  • The Special Interest Group on Design Automation (SIGDA) of the Association for Computing Machinery (ACM). It is for EDA professionals. (In spite of the name, this is a software group, not hardware.)

  • The Virtual Socket Interface Alliance (VSIA). For product, IC, and EDA vendors, it creates standards for system-on-chip Virtual Components (blocks of intellectual property).

  • Accellera— an EDA and designers' group. It is trying to standardize a formal verification language and a system design language. Accellera manages two prior standards groups, Open Verilog International and VHDL International.

  • Open-Access Coalition (OAC). Led by Silicon Integration Initiative (SI2), this user-backed group has established an industry-wide data model and application programming interface (API) which potentially can access any database.

Nora:

Do your people work on any standards committees?

Hugo:

Sometimes, but it takes a lot of (unpaid) time. We get involved when we need a standard to have a salable product. Sometimes we sit in just to ensure that a competitor doesn't dominate the standard to fit its product!

Nora:

Can you tell me more about your EDA staff?

  • + Share This
  • 🔖 Save To Your Account