- Introduction
- Four Key EDA User Decisions
- How to Buy EDA Tools·Five Key Issues
- Standards Efforts·Who, What, and Why
- Personnel·The Key to EDA Support
- University Connections
- Summary
- Quick Quiz
This chapter is from the book
This chapter is from the book
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? |
)
Figure 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: |
|
|
|
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? |