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.