March 21, 2005 -- Those clever guys and gals at Synopsys (the ones sporting the size-16 brains with go-faster stripes that slave away in the R&D department and are only rarely let loose to see the light of day) have done it again. Their new next-generation physical design system -- IC Compiler -- boasts a veritable cornucopia of cool capabilities and features.

"But Captain, the engines can't take it!"

I know how Scotty felt. Truth to tell, my engine (brain) is getting a little wobbly around the edges as I pen these words, because I've just been exposed to the latest offering from the folks at Synopsys. This new beast -- they're calling it IC Compiler -- is a next-generation physical design system (what we laughingly used to refer to as "place-and-route" when I was a younger man) with so many facets to it that it's difficult to know where to start.

First, let's consider the problem, which is that digital chip designs (ICs, ASICs, SoCs, whatever you want to call them) are becoming horrendously complex. I know, I know, you've heard it all before, but that doesn't make it any-the-less true. Now here's an interesting point to ponder; when someone uses the term "the past" in the context of this sort of thing, my knee-jerk reaction is to think of the early 1990s. Similarly, if someone mentioned "designs circa 1999," my gut-feel would be that this was fairly recent, and that not much has changed over the last few years.

Well take me outside and spank me now because -- with regards to digital chip designs -- 1999 was another millennium in more ways than one. Let's consider a few comparisons (Table 1).

Table 1. Digital IC designs circa 1999 versus 2005

Good grief, I'd forgotten that we were only really starting to dip our toes into the deep-submicron realm at 0.35um and 0.25um in 1999; and were we really using only 3 to 4 routing layers? In those days of yore, less than a third of designs employed clock tree (CT) synthesis (the majority of clock trees were implemented by hand), and the chip resources consumed by the clocking structures were negligible compared to the rest of the design.

My goodness, how things have changed in just a few short years! Today we're at the 130 nano node moving to the 90 nano node (with a few brave souls already forging on ahead at 65 nano); and we're working with a staggering 8 or 9 tracking layers. Furthermore, all designs now use clock tree synthesis technology and the ensuing clock structures typically account for 25% of the chip's silicon real estate and 30% of its power consumption!

As another example, via resistance was pretty much negligible (compared to other problems) back in 1999. By this I mean that if you routed a track on metal layer 4, the total resistance of the track (including vias) was only 1.5x that of routing on metal layer 1. By comparison, via resistance effects are now dominant, because a track routed on layer 8 or 9 at the 90 nano node can have 5x the resistance - including the via resistances - of a similar track routed on layer 1 (this shoots up to 7x at the 65 nano node).

Enter IC Compiler {stage right with a fanfare of trumpets}

As we might imagine, all of the developments noted above are rapidly overwhelming conventional digital IC design environments and tools. Something needs to be done, and Synopsys are right out there pushing the bounds of today's design, implementation, and verification technologies. Let's kick of with a picture to help us visualize how all of the pieces fit together and to make sure that we're all tap-dancing to the same drum beat (Figure 1).

Figure 1. How IC Compiler fits into the picture

As we see, IC Compiler boasts three key technologies: extended physical synthesis, signoff-driven closure, and yield-driven design.

Extended physical synthesis: Let's start with extended physical synthesis (which Synopsys amusingly call XPS - perhaps under the misguided belief that I needed another TLA to wrap my poor brain around). The majority of today's physical implementation solutions still treat placement, clock tree synthesis, and routing as three separate steps (and only then do they think about signoff … and only then do they think about yield optimization). This is largely because these current solutions were architected in the late-1990s, when requirements were so much different to today.

But when you know that your clock tree structures are going to consume 25% of your silicon real estate and a large portion of your routing resources, then you also know that you need to take this sort of thing into account right from the get-go. In order to address this type of problem, while performing their magic, IC Compiler's placement algorithms anticipate how the clock tree synthesis algorithms will implement the clock structures. Similarly, both the placement and clock tree synthesis algorithms anticipate how the routing algorithms will lay down the tracks. And the router itself can influence the placement if it detects any problems (of course, the routing algorithms also take full account of the problems associated with via dominated path resistances), and so it goes …

Signoff-driven closure: The next key feature is signoff driven closure. PrimeTime (timing analysis) and Star-RCXT (parasitic extraction) are pretty much the yardsticks for signoff in the industry. [Note to Synopsys marketing, on the basis that Star-RCXT also takes account of inductive effects appropriate to implementing today's technologies - and will be extended to account for more sophisticated inductive effects in the future as required - wouldn't it be a good idea to call it Star-RLCXT? (Look for my invoice for this suggestion in the post)]

Other synthesis and physical implementation tools feature their own timing and extraction engines. This leads to correlation and timing-closure problems when it comes to signoff verification. This is where the folks at Synopsys have great big beaming smiles on their faces, because the extraction and delay calculation algorithms and libraries used by their implementation tools are absolutely identical to those used by Star-RCXT and PrimeTime. (FYI Since the mid-1990s, Synopsys has accumulated a regression suite of 5000+ tests that are constantly run to ensure consistency between the implementation and signoff domains).

The really interesting point here is that new capabilities in IC Compiler mean that, toward the end of the implementation process, exact (signoff) measurements are used to drive incremental optimization algorithms.

Yield-driven design: This is where things start to get really cool. In the not-so-distant past, design and implementation tools optimized only for area and timing; then it was area, timing, and power; and later it was area, timing, power, and signal integrity. Now, IC Compiler allows users to optimize for area, timing, power, signal integrity, AND yield.

For our purposes here, we can split yield considerations into two main areas: cell-based effects that happen in the silicon and poly layers (anything below the layer 1 metallization) and routing effects that occur in layer 1 metallization and above.

Thus, IC compiler's yield optimization enhancements come in several flavors. For example, we have preferred cell selections (this requires a yield-characterized design library) and routing rules. But what really made me sit up and pay attention in the context of design-for-yield is IC Compiler's bidirectional links to the downstream photo-mask synthesis applications.

Traditionally, physical implementations have simply output GDSII files that have been "thrown-over-the-wall" to the photo-mask synthesis tools. Amongst other tasks, these photo-mask applications are responsible for adding the "Mickey Mouse Ears" and related patterns that are used to augment the original GDSII files so as to make them printable, workable, and improve yield. The problem is that the photo-mask synthesis tools applied the same rules to the entire design without fear or favor. This resulted in very large, complex, and expensive masks.

The point is that not every signal is a critical one. Thus, in addition to accepting design-for-yield constraints from the photo-mask synthesis engine, IC Compiler also communicates its intent to the photo-mask synthesis tool. It does this by providing information such as "This net is really critical, while this net is only medium critical, and this net isn't critical at all." This allows the photo-mask synthesis engine to spend more time on highly-critical nets and less time on non-critical nets. According to Synopsys, this results in higher yields and a reduction from 2x to 5x in the ensuing photo-mask file sizes.

Cool Beans

It probably won't surprise you to hear that the chaps and chappesses at Synopsys are pretty happy with themselves with regard to IC Compiler. They claim it provides the best quality-of-results (QoR) in terms of speed, area, power, and yield coupled with best time-to-results (TTR), which I finally worked out means that the software itself runs faster. Well, I for one am jolly impressed, and -- in this, my first column for SoC Central -- would like to bestow my first official Max's Cool Beans award (may they use this power only for the good). Until next time, have a good one!