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.
Reprints
