As chip designers, we take register-transfer-level logical synthesis for granted today. And that's a good thing. That means that we are all comfortable with it. I remember back in the early '90s when I was a synthesis apostle seeking engineering converts to just try RTL synthesis. That was hard! Designers just didn't trust RTL synthesis. We've come a long way since then. Nowadays, everyone thinks they know everything there is to know about RTL logical synthesis.

But tools change after 15 years, and I realized the other day while teaching a logical synthesis workshop, how much the "rules" for RTL synthesis have really changed, with the advent of new synthesis tools, increased abilities of the physical back-end tools, better compute resources and faster operating systems. Further, designs are still getting bigger and more complex, IP reuse/integration is more prevalent, wires dominate the delay equation, low power is becoming a huge factor--all this in the face of ever-shrinking schedules and design teams. I've noticed something else, too: RTL physical-synthesis tools (tools that take RTL and synthesize it as well as place it) can't do as good of a job as an RTL logical synthesis tool working with a gate-level physical-synthesis tool. It's taken several years to prove this, but today it all starts with a good netlist from your favorite RTL logical synthesis tool.

Here are some ways to take advantage of modern synthesis technology.

Do

• Perform top-down synthesis at the chip level or at the same level of your physical implementation. The tools have the capacity and run-time improvements for it. This allows you to simplify constraint management, reduce the number of synthesis scripts needed to compile the design (as well as reduce the number of synthesis licenses) and gives the synthesis tool more visibility into the interoperability characteristics (fan-out, load, timing) between blocks in the hierarchy during optimization. Using a top-down approach also removes the dependency on having good timing budgets and constraints.

• Overconstrain individual critical paths, not the clock objects! Today's tools can pinpoint where to apply an additional delay to overconstrain a specific path in the design that might require extra margin to accommodate physical implementation problems. If you overconstrain a clock object, it will cause unnecessary timing optimization to all parts of the design that use that clock object, including those that might already meet timing in the physical implementation of the design.

• De-emphasize the I/O paths, get register-to-register paths to max out. Find out what your core logic can do. Often, I/O timing creates a bottleneck for the rest of the design's timing optimization. The core logic usually can run at a faster clock speed than the I/Os, so focus on that during synthesis. Relax the timing constraints on your I/O paths so that the synthesis tool can focus on achieving the maximum speed on its reg-to-reg paths. Then, when you get the register-to-register path speed you need, you can concentrate on your I/O constraints or make microarchitecture changes to the I/O paths to achieve their maximum performance.

• Get rid of wire-load models, use physical information for resistance and capacitance of nets. Fan-out-based wire-load models are insufficient to model wire timing. Even custom wire-load models are "static" and ineffective if the size of the design's modules changes during optimization. Today's synthesis tools can read in physical libraries to better model and dynamically adjust the physical timing for RTL-to-gates synthesis.

• Identify functional false paths in the design. Paths that exist in the design, but are never energized, are functional false paths. These paths can interfere with optimization by acting as a decoy to the optimization engine. Synthesis tools are static timing-based tools. Static timing is based on connectivity, not functionality. Timing reports will show critical timing paths based on connectivity, whether they are functional or not. You can potentially eliminate many critical paths in a design by identifying the functional false paths. The earlier you identify, the more efficient timing closure will be. This can be done manually (you've got to really know your design), or specialized tools can help automate this.

Don't

• Turn off new sequential optimization techniques. If it's a logic equivalency issue, update your logic equivalence scripts. Equivalence-checking tools have also made great strides in better understanding synthesis optimizations. This means that previously unverifiable optimizations like register retiming and boundary optimization, as well as data path optimizations and sequential optimizations, can now be verified through simple text-based communication between synthesis and equivalence checking.

• Overconstrain the design. When we started a long time ago, we'd suggest overconstraining the design by 10 percent of the clock period so that there'd be some margin when you got into the physical implementation. Well, that number grew to 20 percent, and some customers have told us they've used even larger numbers or big wire-load models to build in margin. What I've found is that some designs are so overconstrained that, yes, they do meet their timing goals post-clock tree synthesis, but at a serious area cost that might not have been necessary. Specify realistic constraints for your clocks, and pay attention to your I/O constraints--and see what type of area you can save by using realistic constraints.

• Measure your success post-synthesis--you've got to take the design and physically implement it to find out if the area savings can be maintained while achieving your timing goals. If you have critical paths post-CTS, use the pinpoint constraint method mentioned in the "do's" section to constrain them.

• Worry about hold times during RTL synthesis. With modern process technologies, it is more appropriate to do this during physical implementation. Factors like clock skew need to be accounted for to properly fix hold-time violations. Until the design is physically implemented and the clock tree is synthesized, you won't know where the hold-time fixes really are needed.

• Worry about design rule constraints. Focus on achieving your timing, power and area goals during synthesis. You can still specify what your DRCs are for a design during synthesis, but don't worry if they are all not perfectly satisfied by the logical synthesis tools. Today's modern physical implementation tools are designed to fix DRCs during the physical implementation stage with actual placement and wires present. By de-emphasizing DRCs, the RTL logical synthesis tools can focus on speed.

• Limit your library cell choices. Modern synthesis tools create logic structures based on your constraints and the characteristics of the target library. Providing a richer set of library cells will give the tool more ability to optimize and balance your timing, power and area goals, delivering a better netlist for physical implementation.

By Jack Marshall, senior technical leader, Synthesis Core Competency Group, Cadence Design Systems Inc. (jackm@cadence. com)

    See related chart