design tools

Multimedia Processor Design Presents Synthesis Challenges To address productivity problems in the design of a multimedia chip, Equator Technologies introduced a new synthesis tool into the design flow to work in conjunction with its existing synthesizer tool. by Bryan Cope

In a perfect world, EDA tools would work as you expect them to work. But it's not a perfect world, and the tools we use to do our job rarely work as advertised. They're difficult to learn, usually don't work well together, and often seem to give us more frustration than benefits. Every year, we see new companies make claims that they've solved a big design automation problem, and sometimes they're right. Most of the time, though, they're wrong, and we all get a little more jaded. As a result, most designers aren't too keen on depleting their tool budgets to try something new. It's only at those times of deepest frustration, when deadlines are looming, that engineers take a leap of faith.

At Equator Technologies, we've been developing a multimedia processor (MMP) consisting of a VLIW (very long instruction word) DSP combined with custom interfaces for audio, video, network and telephony, and graphics. With well over a million gates, the MMP approaches many CISC CPUs in complexity. Because the system on a chip will go into PCs, we needed to reduce design cycle times to keep pace with the PC market.

Time-to-market pressures continually force us to evaluate new tools to address issues of resources and productivity in design and verification. Our design flow includes products from Avanti, Cadence, Chrysalis, Quickturn, and Synopsys . Previously, we added formal methods and emulation to improve our verification performance and reduce verification times.

One of the toughest challenges we had in putting this particular system onto a chip was synthesis productivity--the time we needed to complete synthesis and meet all requirements. We weren't convinced that we could meet the MMP's challenging timing requirements, remain within reasonable die size limits, and meet our aggressive time-to-market goals without a reduction in drive times. We needed a more efficient synthesis methodology if we were going to make a larger, faster, and more highly integrated chip than anything we had synthesized before. Consequently, we decided to take a look at a new synthesis tool, Ambit's Buildgates.

Buildgates' features allowed our team to more quickly recognize problem areas, more tightly focus our repair efforts, and more effectively use our experience and synthesis expertise to improve the optimization process.

We did not, however, abandon our original synthesis tool, Design Compiler. Instead, we developed a methodology that included both.

In using Design Compiler, we found that larger, more complex designs required us to put in increasing amounts of engineering effort and expertise. We had to write scripts, create timing budgets, and run optimizations. The number of hours we spent driving the synthesis tool toward the desired results grew not only with gate count, but with clock speed and circuit complexity as well. We were eager, therefore, to try a new synthesis tool that promised to reduce the amount of driving required, thus allowing us to focus our efforts on known problem areas.

The best of two worlds
Our first problem was the reluctance of some members of our design team. They simply couldn't believe that any other tool could perform as well as Design Compiler, let alone better. Even after having used Buildgates, some of our engineers still aren't convinced; they're still using Design Compiler. Others are learning Buildgates while continuing to use Design Compiler. In fact, we knew from the start that we needed interoperability between the two tools, so we had to develop a methodology that had room for both. Fortunately, getting Buildgates and Design Compiler to work together is a straightforward task.

Many of the commands and constructs for setting constraints for Design Compiler and Buildgates are very similar. People familiar with Design Compiler should be able to pick up Buildgates quickly, without having to learn a lot of new skills. That means it's easy to migrate scripts from one tool to the other. In addition, Buildgates supports the Tcl scripting language, which allows more powerful and flexible scripting constructs for a user to learn.

We had to make only one change to our existing synthesis flow in order to make the transition to Buildgates--editing the scripts to conform to the Buildgates style. Fortunately, Buildgates supported translation of all the important Design Compiler command pragmas that were embedded in our Verilog code. Thus moving from Design Compiler to Buildgates was quick and painless.

We took the netlists generated out of each of the MMP's major I/O blocks, some by Design Compiler and some by Buildgates, and used Design Compiler to create a netlist for the entire design. In this situation, there was no real advantage in using one tool over the other; the engineer doing the high-level assembly task simply knew Design Compiler better. In this process, we were able to reuse existing RTL code, design flows, models, and even recycle some existing scripts.

Major challenges
The MMP presented us with three major technical challenges: developing a standard-cell library, meeting demanding timing requirements, and creating complex clocking. Buildgates helped to solve the challenges by providing new functions. One of those was an incremental compilation capability. When running the process interactively, Buildgates can stop the compilation at any point, which Design Compiler can't do. With Buildgates, you press Control-C as you would with a Unix prompt. Buildgates responds with a prompt and a usable database that you can manipulate to change constraints, set false paths, set multicycle paths, or do anything else you would need to drive the tool. Then you can restart the tool at the break point. With Design Compiler, on the other hand, you have to wait until a compilation is completed before you can evaluate the results or experiment with different constraints. Buildgates' reporting capability is especially useful when evaluating synthesis of a design for the first time (see Figure 1).

Figure 1	On-line reporting
Buildgates' detailed reporting allows designers to quickly identify problematic areas in its netlist and significantly reduces early synthesis iterations.

Our first challenge came when creating a custom standard-cell library for the MMP design. Synthesizing certain portions of the design was taking forever. Our tools were overworking on paths that shouldn't have been problematic. The Control-C break capability and the detailed information that Buildgates provides during compilation time pointed to a library design issue. We went back to our standard-cell library designers, and with some help from Ambit's technical support, we found the places where we had set constraints so tightly that the tools couldn't meet them. We also found that paths were failing design rule fixes. The standard-cell designers went back and re-evaluated the constraints. We only discovered those problems because Buildgates provides a great deal of information during its compilation.

Meeting the MMP's demanding timing requirements without sacrificing excessive amounts of real estate was another challenging aspect. Clock rates in excess of 200 MHz were found throughout the design. Timing issues used to be our biggest productivity eater, because we expended a large amount of effort scripting the synthesizer to achieve critical timing objectives. We discovered that Buildgates typically gave us more success meeting critical timing budgets even before we used its advanced scripting capabilities.

For example, we were trying to create a complex ALU. We needed 1 ns or less to meet timing. Using our traditional flow, we spent several days experimenting with various constraint options but were unable to achieve our goal. With Buildgates, we met our goals during our initial synthesis runs without extra experimentation.

Clock support
Another challenge was the MMP's multiple asynchronous clock domains. The I/O subsystem required multiple clock frequencies ranging from 1 MHz to hundreds of megahertz. Traditionally, multiple clocks pose a challenge for synthesis tools. Some blocks had as many as four clock domains, and we knew that one of our two synthesizers would have to handle them cleanly.

Fortunately, Buildgates allows a designer to define a clock using both an ideal clock and a real clock. The designer creates the ideal clock with the theoretical ideal parameters, then sets skew with a real clock actually connected to a pin. Doing that allows the designer to create uncertainty between multiple modules that use the same clock domain.

We discovered that Buildgates boosted our productivity in two other major areas. Because of its open architecture, we could directly manipulate it and our design database, and we therefore had increased control of the synthesis. Buildgates also provided many individual optimization options that gave us more precise control over optimization efforts on areas having timing problems. It was like being given all the hand tools you need to fix your house rather than trying to fix every sticking drawer or leaky faucet with just a sledgehammer.

Figure 2	Automatic time budgeting
Buildgates' automatic time budgeting automatically generates constraints for complex hierarchies.

Buildgates' architecture gave us access to many of its internal functions. For example, the tool incorporates a number of transform commands that enable designers to go in and correct timing, optimize for area, or make design rule fixes. Using those commands, we had the ability to specify exactly what aspect of the synthesis we wanted Buildgates to work on, as well as the ability to tell it how we thought it could improve timing.

The tool's most powerful scripting feature is its ability to combine any or all of its transform commands into a do_optimize command. Do_optimize is basically another script containing several do_xform commands. Buildgates will iterate on the transforms specified until it achieves the desired result. If there are some buffering problems, the designer can include do_xform_buffer , and Buildgates will try to add buffering to fix timing. If there's a path that has too many loads on it, an option to include do_xform_clone , which breaks up the path, helps make timing.

There are a lot of little things we were able to instruct Buildgates to do that permitted us to focus our efforts and add our own ideas to the optimization process. We found that whenever we combined human intelligence with machine intelligence, we achieved results that neither could achieve alone. Instead of throwing the RTL code over the wall to a tool and abandoning it, our engineers were able to work cooperatively with the software.

Automatic time budgeting reduced the effort required in working with larger blocks. We didn't need to break up our design into as many smaller blocks or manually assign timing constraints to each block in the hierarchy. Optimization takes place across fewer boundaries at higher levels within the hierarchy, requiring individual designers to do much less work (see Figure 2).

Take, for example, a design with three modules and a tight timing constraint. With Design Compiler, if you can't synthesize the design as one whole block, it has to be broken into pieces that are synthesized individually. That forces designers to guess at timing requirements among the modules and also to write the scripts manually to drive the synthesis tool to meet timing. The designers have to look at all the interconnects between the modules and figure out what the relative timing should be coming out of one and moving into another and then create a set of constraints based on the estimate. That's time-consuming, especially if there are a lot of modules with a lot of interconnects. Once the percentages are determined, then the designer can kick off the three individual synthesis runs. More often than not, at least one module will not make timing. Timing between modules has to be changed and synthesis rerun. If a project is pushing timing and new technology, that's very hard to do.

Buildgates' flow, however, can read in all the modules, execute the command do_time_budget , look at all the interconnects, and based on the amount of logic in each module, assign a representative percentage of total slack to each module. For example, if you add up the blocks between two registers and module A had three gates and module B had seven, then Buildgates would allocate 30 percent of the time budget to module A and 70 percent to module B, though the algorithm is much more complex than that example. The process is automatic for Buildgates but manual, hit-or-miss for Design Compiler. Buildgates analyzes the design very quickly and creates a set of constraints to kick off the synthesis runs. The first time may not be perfect, but it comes close. After two or three iterations, the design generally meets timing. Buildgates also creates all the constraints for design rule checking. You don't have to estimate the timing budgets with the tool; it does the work for you.

In comparison, our flow using Design Compiler is often much more complex. My coworker uses Design Compiler to create constraints for one block that contains 30 hierarchical modules. He has to sit at the computer and tweak his design all day long. Buildgates, on the other hand, automatically generates constraints that give the same results in a fraction of the time. I can start Buildgates and check on it every hour to see how it's doing and continue my other work. Synthesis is my coworker's full time job, yet I'm doing the same work that he does in my spare time. That exemplifies the difference between a day of computer time versus a day of engineering time.

Looking to the future
We've found a place for both Buildgates and Design Compiler in our methodology because we've established a level of trust with both. The fact that we're learning about the advantages of Buildgates doesn't negate the value of Design Compiler. Still, we're finding that Buildgates offers more of what we need to design a complex deep-submicron IC. It allowed us to complete synthesis of the MMP interfaces very quickly. In fact, it gave me enough time to help out on the core processor portion of the design.

Although we're designing the first version of our MMP from scratch, that won't be the case in the future. We expect to be doing a lot of custom derivatives of the product over the next few years, and the majority of the blocks that will differentiate those derivatives are going to be synthesized. Buildgates is helping us to document our intellectual property for those future projects.

Bryan Cope is a member of the technical staff at Equator Technologies, Inc. in Austin, Texas. He previously worked as a system engineer at Crystal Semiconductor and IBM.

To voice an opinion on this or any Integrated System Design article, please email your message to miker@isdmag.com.

integrated system design  August 1998