Background – An Imperfect World

In an ideal world, EDA tools would represent a perfect match for the chip engineer’s needs, and their use model would be architected to match his design flow rather than the other way around. In the real, Perl-script infested world, EDA tools are islands between which users must build their own bridges. Moves toward data consistency help to some extent, but beyond that things become very cumbersome. Decisions made to address one problem, let’s say power consumption, can have an adverse affect on another, such as timing. In a world of point tools there is a distinct lack of multi-disciplinary intelligence. As a consequence, design closure when faced with the contradictory constraints of today’s multi-scenario designs, is in many cases unobtainable.

One area where this problem has been conquered is logic synthesis. When faced with multiple conflicting constraints (timing vs. area for example) synthesis tools have the visibility to make trade-offs – keeping one in mind when optimizing another. It would be unthinkable to run one tool to optimize timing and another to optimize area. But that’s what we have in areas like power and clock synchronizer setup, where optimizations made to meet power consumption targets can undo the careful efforts to make the design ‘clock domain crossing (CDC) clean’.

Is the solution to simply merge all EDA tools into one? Practicalities such as pricing aside, as consumers we’re conditioned to be skeptical of multi-purpose solutions. The solution which tries to offer everything doesn’t do anything particularly well. A better, more practical, solution would be based on the principles of consistent setup, intelligent data sharing, and unified analysis/debug as outlined in Figure 1.

Figure 1: The Unified Environment 

What we’re talking about here is another evolutionary step beyond an approach such as OpenAccess. That approach does not address the problem of conflicting objectives across the tool set. Just because your power optimization tool can co-exist with your ATPG tool doesn’t guarantee that they aren’t taking your netlist in incompatible directions.

In Figure 1, the iterations between tools represent more than mere data sharing. Instead, the idea is that one tool is intelligent enough not to break the optimizations put in place by another such that its objectives are no longer met.

A Proposal – Efficiency Through Communication

So how exactly do we make the various tools in a typical design flow less ‘anti-social’, and more willing to cooperate with other tools in the flow? The basic principle is that no one tool should ever do something to the detriment of the design. For example, power gating shouldn’t break clock domain synchronization schemes; timing optimization ‘tricks’ shouldn’t reduce test coverage, etc.

One technique to enable this is to use consistent setup between tools.  Take the example of ‘CDC aware’ power optimization – if the power optimization tool can take clock domain information on board, additional gating on asynchronous clock interfaces can be avoided.

Let’s take another case where two tools ‘share’ a responsibility. Let’s assume that the task is to ensure that clock to clock false paths are correct. The first instinct would be to simply verify the false paths using a timing exception verification tool. This, however, only covers paths between synchronous clocks, suggesting mutual exclusivity is accomplished through verifiable clock muxing for example. If the clocks are asynchronous there is likely no related logic in the clock tree to verify so formal analysis will either be inconclusive or simply noisy.

One example of a combined solution is outlined in Figure 2, where timing exceptions between synchronous clocks are verified using Atrenta’s SpyGlass^®-TXV timing exception verification tool and the correct synchronization of interfaces between asynchronous clocks is handled by the SpyGlass-CDC tool, giving complete overall coverage.

Figure 2: An approach to comprehensively verify a multi-clock design 

As a chip designer and EDA tool user, it’s imperative to see the broader picture when using any tool which modifies your design in any way. Not doing so will put you into an endless loop of trying to converge on multiple competing objectives, and potentially introduce the risk of missing a real chip killer. If the tools you are using aren’t playing ball, maybe it’s time to ask for better tools.

About the Author:  Ron Craig, Senior Marketing Manager, Atrenta 
Ron Craig has more than 15 years of experience in EDA and semiconductor design. Prior to joining Atrenta, Ron held a range of positions in design, consulting, applications and marketing at Amphion Semiconductor, Sony Semiconductor and Synopsys Inc.  Ron has a Bachelor of Engineering from The Queen’s University, Belfast.  (ron@atrenta.com)