As device densities increase rapidly beyond the scope of existing tools, new and dramatically different electronic design automation (EDA) methods and technologies must be developed to support them. Designers no longer use tools from a single vendor. Instead, they rely on best-of-class point tools from multiple vendors to support their designs. This enables designers to fully take advantage of the different feature strengths at various stages in their design flow. Because this trend will only increase in the future, EDA vendors must work to design future tools for greater compatibility and integration beyond simple sharing of compatible file formats. The ease with which information can be exchanged between tools will directly impact a designer's overall productivity.
Today, designers benefit from the ability to write scripts that drive tools in a flow. In the near future, there will be an even greater demand to gain exposure to tools within a flow. This would enable EDA companies and computer-aided design (CAD) managers to not only control every aspect of the tool operation, but also support a seamless flow between the tools for the designer. That means EDA tools must have a rich and open application programming interface (API) capable of allowing vendors and CAD managers to build communication links between the tools in their design flow. As a result, designers would be free to concentrate on the actual design rather than the "glue" between the tools.
Increasing design size further necessitates an open API because as designs grow, designers face the problem of how to debug them efficiently. Research shows that designers spend most of their time in verification, trying to simulate and debug their designs. As designers use different tools in their design flow, one major concern (and a productivity hog) is the time spent trying to locate the problem. Designs undergo multiple translations as they pass through different tools in a design flow. For example, an error found at the timing analysis stage might actually have originated at the design entry stage. To fix this problem, designers must spend valuable time tracing their way back to the original design entry file through a series of tools.
Information Must Be Shared If the tools could actually "talk" to each other, this problem would be alleviated substantially. Then, tools could cross-probe from themselves to other tools and automatically locate the original sources of errors. This tactic is contingent upon the willingness of EDA vendors to share information between tools.Tool integration is necessary. There are problems, however, associated with conventional EDA design flows that rely on exchanging design information via files. Different capabilities and technologies are presently available to the EDA tool developers. Ultimately, these technologies can allow tool interaction that extends far beyond shared file formats and standard languages.
Today, designers are used to mixing and matching point tools from different EDA vendors. It's not uncommon, for example, to see designers using a synthesis tool, simulation tool, place-and-route tool, and timing analysis tool from different vendors. One designer might perform design entry in vendor A's tools, synthesis in vendor B's tools, and back-end operations with vendor C's tools. The common theme here is that the tools should all recognize a standard file format. Usually, that format is EDIF. Most EDA tools process hardware description language (HDL) netlists or a schematic and translate them to an EDIF netlist to be passed on to other tools.
A common problem encountered by designers is the learning curve associated with understanding the different file formats and how each tool receives them. Even though tools A and B in the design flow can accept an EDIF netlist, for example, tool A in the design flow might only recognize EDIF 2.0.0, whereas tool B might only accept EDIF 3.0.0. Other tools might require a Verilog or VHDL netlist instead of one written in the EDIF format. Some might not even support the latest version of a file format, such as VHDL 93.
In most instances, the onus is on the designer to know what tools will accept which formats, and then to instruct the tool to generate compatible files. If a designer uses a static timing analysis and a simulation tool in a design flow, each accepting various flavors of EDIF, VHDL, or Verilog, then he or she must remember to generate the appropriate netlists.
Ideally, EDA tools would know what kind of netlist to generate or import based on their knowledge of other tools in the design flow. But unfortunately, this usually isn't the case.
While EDIF is probably adequate for passing information between tools in a flow, it's an extremely difficult language to debug. Most design tools do provide a debugging environment, but designers would prefer to change their designs in the original source file instead of at an intermediate stage. Therefore, working with EDIF poses the challenge of debugging the problem and locating its original source. When the original source has been through many design tools and translations, it can become undecipherable. Node names might not be preserved across tools and internal names may be generated in a format that's local to one tool, but alien to another. Many times, designers have to spend a good portion of their time tracking down the changes across these tools.
Tools Must Be Customized Another problem is that designers not only have to learn the different tools in the design flow, but also need to make them work in the same design environment as well. It would be useful if the designer could stay in the domain of his or her choice and drive other tools from within that domain. To accomplish this, tools must be customized to launch other applications and pass constraints and assignments seamlessly in addition to the actual exchange of design netlist information. Designers would then be able to concentrate on actual design issues rather than spending time trying to learn new tools and file formats.Based on the discussion so far, it's obvious that one basic problem vendors face is how to get tools to talk to each other without any user intervention. One solution is to provide a seamless integration between EDA tools that goes beyond the "files only" capability. EDA vendors could, for example, define a generic interface between the tools in the design flow, thereby enabling a code-level integration between the tools.
In the best-case scenario, the EDA interface would be comprised of two major components: a set of external files and a set of interface functions for each tool. The external files would include the design sources, ancillary files, and cross-reference files. The set of interface functions might be a pre-defined API (a set of functions and subroutines). This API would enable the host EDA application to talk to other client applications and share information seamlessly via function calls. It would also enable better user control of the project from various places in the design flow. Here, project is defined as the entire set of design files that describes the hardware to be implemented.
Some definitions which you may find useful in this discussion are:
External files: These comprise industry-standard design source file formats like VHDL, Verilog, and EDIF. In addition, ancillary files and cross-reference files are included.
Design source files: These files are the actual netlists or schematics with design information that can be imported and exported by the tools. They are usually industry-standard file formats as shown in the Table.
Ancillary files: This type of file is associated with a particular design project, but isn't a part of the design source. For instance, while the design information is passed on via EDIF between the tools, the constraints or assignments can be passed on via a separate file. Although the ancillary file isn't a design source, it's essential to the design process. Some examples of ancillary files are constraint files, initialization files, and project setting files.
Cross-reference file: This is a file that's used to communicate information about the actual design source to an EDA tool down-line in the flow. For example, when EDA tools process design netlists, they introduce new information, such as node names or signal names, that might actually be a representation of a port or a signal in the original source. This information usually isn't represented in an easily readable manner. In other words, as these are only intermediate netlists and not true design sources, users looking at an intermediate netlist might not be able to tell if a particular node is actually mapped to a signal in their design source.
Therefore, EDA tools should output a cross-reference file too. This file could contain mapping information between the signals or components used in the original design source and the internally generated signal and component names in the intermediate netlists. Using this cross-reference file, an EDA tool could use API calls to uniquely identify user-specified objects from the intermediate netlists to the original design source.
Ideally, the file should contain the name of the original design entity and any component instantiated in the design, with the instance names generated by the EDA tool. It should also have the mapping information to the instance names in the source, along with the line number of that instance. Additionally, the cross-reference file should contain information about the actual tool that generated the file and the location of the source file used. If the original source is behavioral, it must map to a block of code, instead of a single line. In this case, it would contain the start and end line, as well as column numbers where appropriate. Using this information, the designer or the EDA tool can then pull up the original design source in a text or schematic editor with the line number or the component highlighted. If an object is synthesized from multiple sources, the cross-reference file can indicate this, so the EDA tool would know where to locate the instance of the node name.
An example of a cross-reference file for Altera's Quartus design development tool can be found in Figure 1. In this case, the input is a schematic drawn in Viewlogic's Viewdraw. The cross-reference file indicates the vendor, the editor used for design entry, the netlist information, and the location of the source file. Now, any EDA tool can use this information to locate in the original design source file. Because the design entry tool is specified, the design can be opened in the editor and highlighted accordingly.
While every other segment of the software industry has been quick to embrace the advances in software standards that enable integration, the EDA tools industry has been reluctant to adopt this approach. A positive example of this integration is the ability to enable web browsers to read PDF files from within Netscape Navigator using a plug-in from Adobe Systems. The user doesn't have to worry about the PDF format or the version of the file, because the two tools—in this case, the browser and the Adobe Acrobat viewer—can "talk" to each other.
No such integration exists in the EDA industry today. One can easily imagine encapsulating a place-and-route tool inside of a synthesis tool much like the "plug-in" approach adopted by the web browser companies. Or if the user chooses, the place-and-route application can run "quietly" in the background, suppressing the user interface element of the application while still enabling the user to reside in the domain of the synthesis tool of his or her choice.
Generic Functions Needed To enable this kind of integration and address portability issues across different platforms and tools, EDA companies must first define a set of common API functions. These API functions need to be generic enough that any EDA vendor or CAD manager who wants to seamlessly integrate a particular tool in the design flow will be able to understand and use it. At the same time, though, it must also conform to a common standard like Microsoft's Component Object Model (COM). Utilized as a common API, it would allow EDA vendors to create tools that easily interface with one another.The API could be a set of interface functions, like a collection of abstract base classes, that only prescribe the functions and don't carry any implementation. Because the API would be implemented on a standard interface, such as COM, irrelevant data would be hidden from the client application. This allows the EDA client application to develop the interface based on an understanding of this API only, and not the complete underlying data structure that might be proprietary in nature. The EDA vendor could then distribute an API with a set of function prototypes for developing the interface.
The components of the API must be designed based on the functionality it serves. The various tasks involved in designing with a tool in a flow can be divided into different sections, each with its own functions. We can easily imagine an API to have at least four sets of function prototypes.
One is the project information API. This can be used to control the design project. It would contain the functions for opening and closing projects, as well as adding or deleting project level properties. An example would be the addition or deletion of files.
Another is the device database API. This would contain the functions to query the device database in the EDA tools. For instance, a simulation tool can query the synthesis tool via this API and get the timing information for back-annotation during timing verification. There would be no need to output an SDF file, as is the usual case.
Third is the assignments and constraints API. This API would be used to pass constraints and assignments across various tools. A synthesis tool, for example, could use this API to pass timing or area constraints to the place-and-route tool. The user can stay within the domain of the synthesis tool, and then drive the place-and-route process by passing the assignments made in the synthesis tool via this API.
Last is the project control API. This would contain the functions that control the project. It could be used to start and stop simulation or compilations, to cross-probe or trace errors back to a tool used earlier in the design flow, or to monitor the progress of any given tool and process the messages it generates. It would also contain procedures to interactively control compilation or simulation from another tool in the flow via a command line.
How would these APIs work together? The project information API could be employed to create information about the project, such as the directory structure or the design files. The device database API would be implemented to get device information to make assignments in the design entry or synthesis tool. The assignments and constraints API would then be called up to pass the constraints specified in the design entry tool to other tools in the pipeline. The project control API might be further used to control the launching and processing of either the compilation or simulation across the tools in the flow.
An example of the assignments and constraints API in the Quartus tool is shown in Figure 2. In this example, the API is used to direct Quartus to pass timing information back to the synthesis tool via either a device database or via an optional SDF file.
API Benefits A tremendous benefit of having code-level integration between files appears in the back-end design flow process. In current design flows, designers often must wait for an entire cycle of synthesis and place-and-route before they know if the result meets performance and/or device utilization requirements. Some design flows make timing information available directly after synthesis, but this information is generally an estimate. Any changes that the designer makes to meet these goals must be made on the design files, or in the form of assignments or constraints. These need to be processed from the beginning and run through the synthesis and place-and-route processes in order for the alterations to be evaluated.
This design iteration can occupy a disproportionately large part of the overall design process. This iteration could be shortened considerably by using code-level integration between the synthesis and the place-and-route tool. In that case, the synthesis tool runs a first pass at the design and sends the information to the place-and-route tool via the API and design files. The place-and-route tool performs an initial placement and feeds back the information to the synthesis tool. The designer can then analyze the results and make changes to either the design source or the synthesis tool settings and re-iterate the process.
Because designers don't have to wait for the place-and-route tool to finish processing, they can save valuable time during the design cycle. The synthesis tool uses the APIs to gather run-time information from the placement tool and allows designers to act accordingly. Alternatively, the synthesis tool can be programmed via the project control API to change some algorithms automatically based on the preliminary results from the placement tool. The exchange of information can be at two or three different stages of processing based on some initial placement of information, or the availability of better estimates after final placement. An iterative compile within Quartus and the elements involved in the interaction between the synthesis tool and the compiler is also illustrated in Figure 2.
As the average design size increases, so does the complexity of the design flow. To alleviate the problem of incompatible file formats and reduce the time spent locating problems within the design, EDA vendors must agree on a common API to share information across the tools in a design flow. This API should allow for a seamless interface between tools, with the user interface elements customizable by the user. Through this approach, designers will be able to achieve improved quality of results in a shorter time.
It's imperative that EDA vendors come together for this cause to promote an API for tool interoperability. One such API defined by Altera Corp., called Nativelink, is currently in use at companies like Synopsys, Viewlogic, Mentor Graphics, and Synplicity. With the release of Quartus, this API is now available for other EDA companies or CAD managers who choose to integrate the tool in their design flow.