Digital Implementation

Five-Minute Tutorial: Change The Background Color Of EDI

Kari — Wed, 08 Feb 2012 16:39:00 GMT

Today's tutorial could probably be called a One-Minute Tutorial, since it's so quick. This is something that came across our internal expert alias, and I figured it's something that most people may not know about. Did you know that you can change the background color of your Encounter Digital Implementation (EDI) design window?

Here's how. In your EDI session, enter the following command:

   setLayerPreference bg -color {<color_name>|color_value}

For example:

   setLayerPreference bg -color white

To set it back to the default, use:

   setLayerPreference bg -color black

You can also use color values, like #000000 (black), #ffffff (white), #ff0000 (red), etc.

If you prefer to use color names, like I do, how do you know what names are legal? You can find a list in a file called rgb.txt, which for sun4v machines, should be in the /usr/X/lib/X11 directory, and for lnx86 machines, should be in the /usr/X11R6/lib/X11 directory. Ask your favorite IT person if you need help finding this file. I found mine to have some color names to rival that of the local paint store. (Papaya Whip, anyone?)

Why would you want to change the background color of EDI? Well, although most people are used to the black background, some folks might be used to a white background based on other tools they have used, or a white background might be better for printing out a snapshot of the design, depending on how you print or plot. And some folks just like to be unique and have colors different than everyone else. To those people, I say: don't ever change. You are the ones who make the world interesting and fun!

Thanks to Susan Zhao for the original Cadence Online Support solution.

- Kari Summers

Five-Minute Tutorial: Multiple View-Only Windows In EDI

Kari — Wed, 25 Jan 2012 16:09:00 GMT

Have you ever had a situation where you want to compare two (or more) different areas of a design, so you end up zooming in to one area, then to the other area, then back and forth as you look at various objects and layers, trying to recall the differences? Have you ever brought up two separate Encounter Digital Implementation (EDI) sessions to make this easier? Then today's tutorial is for you!

There is a way to bring up multiple view-only windows of your design during your current EDI session. Under the Tools menu, click on Design Viewer. A new view-only window will come up with your design in it. You can start as many Design Viewer windows as you like to make your task easier. You can place them side-by-side and compare different areas of the design quickly and easily.

Now, the most common thing to do when looking over a design is to turn various layers and objects on and off. You will notice that it's a pain to go back to your main EDI window to use the Layer Control panel, so it's worth reminding everyone that the Layer Control Panel can be undocked! Just put your mouse on the Layer Control bar, left-click, and drag the panel outside of the EDI window. Now you can place it wherever you like on your desktop and more easily use your view-only windows.

Like the Design Viewer? You may also be interested in this:

Five-Minute Tutorial: The Encounter Digital Implementation Cell Viewer

- Kari Summers

Five-Minute Tutorial: Avoid SI Problems With Better Pin Placement In Encounter Digital Implementation (EDI)

Kari — Wed, 18 Jan 2012 15:09:00 GMT

I know we're over halfway through January already (where does the time go?), but Happy New Year everyone! I hope 2012 is a good one for your business and your chip designs, and let's hope the Mayans just ran out of ink when they were finishing the calendar for this year.

Today I'd like to highlight an option of the assignPtnPin command that was added in Encounter Digital Implementation System (EDI) 10.1. This option is called -improveSI. Sounds intriguing and helpful, right? Let's see how it works:

If you use the command assignPtnPin -improveSI, then the pin assignment will attempt to place pins such that pins on the same layer are not on adjacent tracks. Also the pin assignment will attempt to place pins such that you don't have pins on top of each other in consecutive preferred-direction layers.

For example, if one pin is placed in M4, then the -improveSI option will attempt not to place another M4 pin on the closest track to either side of the first pin, and will also attempt not to place an M6 or M2 pin in the same spot as the original M4 pin.

I keep saying "attempt" because I'm guessing that legal placement will trump -improveSI, so if you have lots of pins on a small block, or have strict limits on pin layers, following the -improveSI rules may not always be possible.

I have not used this option myself yet, so give it a try and report back how you like it!

Here are some other tips to avoid SI problems:

Five-Minute Tutorial: Fixing SI Victim Nets

Five-Minute Tutorial: Setting Up Clock Routing Rules

- Kari Summers

CDNLive! Silicon Valley 2012 Abstracts Due November 11th, 2011

BobD — Wed, 02 Nov 2011 19:00:00 GMT

The Call for Papers for CDNLive! Silicon Valley 2012 is open now through Friday November 11th, 2012. CDNLive! is the Cadence users group conference. It provides an opportunity to present and listen to presentations from folks who use Cadence software to get their jobs done. Next year's conference is being held March 13-14 2012 at the Doubletree San Jose.

I've attended a number of these events in the past, both as a customer and as a co-presenter along with customers. The thing I like most is connected with other people in the world who have been working with the same hyper-specific design challenges as I've been. The design community itself is pretty tight knit, but when you're able to meet someone who's been working with writing TCL in Encounter for 10 years to solve interesting problems (just like I have!) it can make for a very enjoyable conversation.

Customers I talk to are often at a loss as to what topic to present on -- even ones who have done some incredible things with our software over the years. Don't sell yourself short. The best presentations describe how you applied Cadence technology (usually a collection of different pieces of functionality) to solve your real world design challenges.

Here are some suggested topics and here is an archive of presentations from last year's conference.

For more information visit the CDNLive! Silicon Valley 2012 part of our website.

I look forward to seeing you there!

-Bob Dwyer

Encounter Quick Tip: Dimming the Display with F12

BobD — Fri, 30 Sep 2011 16:00:00 GMT

I remember when I first started working with the Cooper & Chyan Technology (CCT) router back in the day. It had this great feature where you could darken the display for everything in the design other than what you had selected. This was particularly useful when you were trying to route a net because it focused your eyes on the task at hand while still providing visibility to the rest of the design that you had to avoid bumping into when making wiring edits.

We've had a similar feature in Encounter for quite some time but a lot of people don't know about it. Here's how it works...

In the design below I've selected one net with the "selectNet" command. Can you see it highlighted in the design below? Neither can I, because the white it is highlighted in is so similar to the color used for M4 and M6 routing:

To help make the selected objects more visible, go to Edit->Dim Background (which is bound to the F12 key):

The selected objects should remain bright while non-selected objects will be dimmed, giving focus to the selected objects:

This works for any selected object in the design. Give it a try next time you're having trouble seeing an object in the design.

Hope this helps.

-Bob Dwyer

Encounter Quick Tip: Finding Available Cell Masters with dbGet

BobD — Wed, 28 Sep 2011 18:00:00 GMT

When you first start using dbGet, many of your queries branch off the "top" keyword and then traverse to "insts" or "nets". These searches return a list of all the instances or nets in the design. But sometimes it's necessary to query the available cell masters -- some of which may or may not be instantiated.

Common reasons for needing this are for finding things like well taps, end caps, antenna diodes and filler cells. You have a hunch what these cells are called for the library you're working on and you'd like to search through all of the cell masters currently loaded in the design.

Say for example you want to tell the tool which cells should be used as fillers. (Fillers are physical-only instances added after placement to fill gaps between standard cells to provide standard cell rail and well continuity). You can have a hunch they're called FILL-"something". Here's how to use dbGet to find the names of all the cell masters available that match FILL*:

encounter 1> dbGet head.allCells.name FILL*
FILL1 FILL16 FILL2 FILL32 FILL4 FILL64 FILL8

You can pass the output directly to setFillerMode, then call addFiller to add the instances to the design:

encounter 2> setFillerMode -core [dbGet head.allCells.name FILL*]
encounter 3> addFiller

Although "top" is by far the common dbGet starting point, the "head" pointer provides a link to technology information like layers, vias and more. Give it a look next time you're seeking to find technology information rather than design-specific data.

For more information on dbGet check out this post on Getting Started with dbGet.

Hope this helps.

-Bob Dwyer

Five-Minute Tutorial: The Encounter Digital Implementation Cell Viewer

Kari — Wed, 10 Aug 2011 16:00:00 GMT

How many times have you wanted to look at a certain standard cell in the Encounter Digital Implementation (EDI) system, so you go hunting around the design to find one, or use the Design Browser to find one? Then you turn off the nets and special nets to see only the contents of the cell. Or, maybe the cell type you wanted to look at is not even in your netlist currently. Maybe you want to look at an INVX4, but there are only INVX2s and INVX8s in your design.

There is a little-known utility inside EDI called the Cell Viewer. It's available under the Tools menu:

When you start the Cell Viewer, a window will come up with a list of the cells that were loaded in the session (not just the ones that appear in the netlist) as well as a graphical window that will show the LEF view of the cell:

Standard cells are pretty easy to look at, since the LEFs have very few layers of metal. But what if you're looking at a RAM that has more metal layers? You may want to turn various layers on or off as you're examining the cell. This can be done with the Layer Control panel that you use all the time in EDI. If you happen to have a lot of things on your screen (and let's face it, what engineer doesn't?) it can be annoying to click in the EDI window to turn layers on/off. And then, the cell viewer gets sent to the background.

Here's how to fix that: un-dock the Layer Control panel! Yes, this is also a little-known feature of EDI, but you can click and drag the panel right where it says Layer Control, place it next to your Cell Viewer window, and go back and forth without windows getting lost behind one another.

I hope you find both the Cell Viewer and the Layer Control un-docking to be useful!

- Kari Summers

Five-Minute Tutorial: Finding EDI Videos

Kari — Thu, 14 Jul 2011 18:00:00 GMT

I've seen a few requests in the forums asking about EDI videos. Today I will show you how to find them on the Cadence Support website.

First, go to support.cadence.com. One of the menus across the top is called "Resources". Hover your mouse over this menu and click "Video Library" near the bottom:

On the next page that comes up, click "View all content for all products" in the lower-right:

On the resulting page, choose "Select Products" and click the blue "edit" text:

A box will come up where you can select Encounter Digital Implementation and add it to your list of selected products:

Finally, hit the "UPDATE" button, and a list of about 20 EDI videos will appear.

There's sure to be something in this list that will interest you. Enjoy watching!

Kari Summers

Five-Minute Tutorial: Save Time With The Right Mouse Button

Kari — Mon, 27 Jun 2011 20:00:00 GMT

How many times have you done this: you want to flip or rotate a cell in your design, so you select it and hit the Q key. The Attribute Editor form pops up, you choose the orientation you want in the Orientation drop-down box, then hit OK or Apply. I know I have done this countless times in my years of chip design.

What if I told you there was a faster, easier way? Well, there is - and it's hidden under the Right Mouse Button.

Position your cursor over the cell you want to rotate or flip (that's right - you don't even have to select it), and press the Right Mouse Button (hereafter referred to as RMB). You'll see a list of stuff you can do:

Notice the Rotate and Flip commands.

Another nice feature available via the RMB is cell swapping. For this one, select the two cells whose locations you'd like to swap. Then press the RMB, and you'll see that the Swap Instances option is no longer grayed out:

Isn't that much easier than grabbing one instance, moving it somewhere out of the way, then moving the other instance into its place, and then finally moving the original instance into the space vacated by the second instance? Absolutely.

I encourage you to check out the other shortcuts available by clicking the RMB, like Align and Edit Halo. What's available may depend on where your mouse is or what's selected. Remember the RMB for time-saving shortcuts to your design work!

Kari Summers

Five-Minute Tutorial: Find A Pin's Transition Time

Kari — Thu, 16 Jun 2011 18:00:00 GMT

How many times while working in Encounter Digital Implementation system have you wanted to find the transition time on a certain pin? How did you go about finding it? Here are some ways I know that I've used:

If I knew the pin was failing the max_transition constraint, hunt it down in the .tran violation report.
Try to find the pin somewhere in my timing reports and look at the slew column.
Use (gasp!) undocumented commands (unsupported and therefore sometimes unreliable).

Well, there's an easier, cleaner, faster way. The report_constraint command! This is an oft-forgotten little gem that can be very handy. It's worth reading about all of its features in the documentation, but today I wanted to highlight how it can be used to find the transition violation of any pin. Just specify the constraint we want to report (max transition) and the pin:

report_constraint -drv_violation_type max_transition i_BUFX2/Z

And you'll see results something like this:

Check type : max_transition
---------------------------
Pin : i_BUFX2/Z       View : func_ss_0p90v_125c_rcworst

max_transition :     0.400
- Transition Time:     0.322
-----------------------------------------------------
      slack          :     0.078

I bet some of you out there are using this very command for other useful checks -- share your favorites with us in the comments, please!

- Kari Summers

Five-Minute Tutorial: Avoiding The Use Of FILL1 Cells

Kari — Wed, 25 May 2011 17:00:00 GMT

A new thing that we're seeing with some 45nm libraries is the rule that single-wide filler cells should not be used. At first, this may seem like a difficult thing to ensure in your design flow, but Encounter Digital Implementation system has the ability to handle this. You just have to know the right settings -- and today you'll learn them in five minutes or less.

First, we need to tell the placer that we don't want any gaps between cells that would be the size of a single-wide filler cell. In this example, a single-wide filler is 0.14um wide, so we want the minimum gap to be at least twice that, 0.28um. We also want to set the effort level to high, which means that the placer (or refinePlace in the later parts of the flow) can move cells between rows in order to avoid single-wide gaps. If for some reason you want cells to stay on the same row, set this to medium -- but be aware that all violations may not be able to be fixed.

   setPlaceMode -fillerGapEffort high -fillerGapMinGap 0.28

Next, we want to make sure that no FILL1 cells get added when we do our filler cell step. Make sure you don't list the FILL1 cell from your library! Some libraries are leaving the FILL1 cell out completely, so you wouldn't even be able to include it, but some still have a FILL1 cell, so you need to be careful. Make sure you include a FILL3 cell if there is one -- it can be tempting to only use the 2/4/8/16 sizes. The -fitGap parameter is what's really important here; this will tell addFiller to use different combinations of filler cells as needed to avoid single-wide gaps. For example, if there is a 5-site-wide gap that needs filler cells, instead of the standard method of using a FILL4 and then having a single-width gap, addFiller will see that the single-width gap can be avoided by using a FILL3 and a FILL2.

   setFillerMode -corePrefix FILL -core {FILL16 FILL8 FILL4 FILL3 FILL2} -fitGap true

Let's say you've finished your design and you want to check if there really are any single-width gaps left. That's easy too:

   checkFiller -reportGap 0.14 -highlight

(For a bit more on the checkFiller command and a few other neat things, see this previous blog entry.)

Bonus: Oh no -- what if you're already halfway done with your design and you just found out about this requirement? Relax - all is not lost. There is another command that may help you save the day. Two things to be aware of, however: the command does not move cells that are marked FIXED, and it will delete all routing unless you set the "preserveRouting" switch in setPlaceMode. The effort level settings are the same as in setPlaceMode -fillerGapEffort.

   setPlaceMode -preserveRouting true
   addFillerGap 0.28 -effort high

That's all there is to it. If you find that you're still ending up with single-wide gaps, it's likely due to some sort of design constraint -- FIXED cells, a specific floorplan issue, etc. If you examine the area closely, you'll likely find the cause.

Kari Summers

Tab Completion with Encounter's dbGet Command: Smarter Than You Might Think

BobD — Thu, 19 May 2011 18:00:00 GMT

If there's one thing that makes navigating a UNIX command line or tool console more efficient, it's tab completion. We've been improving Encounter's support for tab completion over the past few releases, and in 10.1 Encounter's dbGet command received tab completion support for the first time. Have a look at the screencast embedded below -- I think the way it's been implemented is really nice. And smarter than you might realize at first glance.

In its simplest sense tab completion works like this:
encounter 1> dbGet top.<tab>

...returns a list of all the attributes associated with the "top" cell in the design. If I provide a portion of an attribute it auto-completes and inserts a trailing ".":

encounter 2> dbGet top.i<tab>
encounter 2> dbGet top.insts.

If you continue on and ask it to complete when there are no remaining attributes associated with the last field, notice how <tab> inserts a trailing space:

encounter 3> dbGet top.insts.n<tab>
encounter 3> dbGet top.insts.name <-and inserts a trailing space

dbGet's tab completion is smart enough to recognize whether there are remaining fields available for traversal and either inserts a trailing "." -or- a trailing space which makes for very efficient command line navigation of the database.

It's also smart enough to return a varying list of attributes depnding on what you have selected. For example you'll see a different list of attributes revealed when you tab complete the selected keyword depending on what you currently have selected in the tool:

encounter 4> dbGet selected.<tab>

Similarly, if you task it with tab completing a variable. It's smart enough to examine the contents of the variable and tab complete accordingly:

encounter 5> set nets [dbGet top.nets.name *clk* -p]
encounter 6> dbGet $nets.<tab>

These examples are demonstrated in the screencast embedded below:
(if you have trouble viewing the video try this link instead)

Check it out next time you're using dbGet in 10.1 or newer releases. I hope you find it useful.

Bob Dwyer

Five-Minute Tutorial: Fixing SI Victim Nets

Kari — Wed, 18 May 2011 16:00:00 GMT

It's hard to believe there was a time when we didn't even run signal integrity analysis. It wasn't always a necessity at the larger nodes of several years ago, but it's absolutely essential in today's processes. So I'm sure every one of you out there has battled SI violations at some point. Today's tutorial will show you a quick and easy way to reroute some victim nets in EDI and get some of your SI issues under control.

Let's say you've run your SI analysis in EDI and you know that your violations are due to some victim nets that need to be rerouted away from aggressor nets. (How do you know this? You've either looked at the failing paths graphically and can see the long parallel runs of nets, or you've done a report_timing -net with the incremental delay column displayed, and you can see that the incremental delay is occurring on the net and not a cell.)

Once we know the names of the nets we want to fix, the rest is easy. For this example, imagine that nets named "net1" and "net2" are falling victim and contributing a large amount of incremental delay. So first we'll attach the "si_post_route_fix" attribute to these nets:

   setAttribute -net net1 -si_post_route_fix true
   setAttribute -net net2 -si_post_route_fix true

Next, we'll tell NanoRoute that we want to run in SIPostRouteFix mode:

   setNanoRouteMode -routeWithSiPostRouteFix true

If you have any other setNanoRouteMode variables that you always use, such as a max layer or double-cut via settings, go ahead and set those as well. Finally, we do the actual routing fix:

   globalDetailRoute

The nets in question (net1 and net2) will be rerouted so that they are not so parallel with other nets, thereby lessening the SI effect on them. You can re-extract and run timing again to see the improvement. I've had very good success with this method. It may not solve all of your SI problems, and there may be several issues causing any one path to fail SI timing, but this method should definitely be in your toolbox of SI fixes.

Bonus: I mentioned the "incremental delay" column in the timing report. How do you get that to show up? Add the incr_delay keyword to your report_timing format, as in this example:

   set_global report_timing_format {instance cell arc delay incr_delay arrival load slew fanout pin_location}

- Kari Summers

Five-Minute Tutorial: Setting Up Clock Routing Rules

Kari — Tue, 10 May 2011 16:00:00 GMT

Hi, and welcome back to another Five-Minute Tutorial! Yes, I know it's been a while, but like most of you out there, I'm an ASIC designer, and you know how busy work can get. (Blogging is not my day job, but I enjoy doing it when I have some extra time!)

Today's topic is how to set up your clock routing rules in Encounter. This is best done in the .ctstch file, so that your clocks are routed the way you want from the CTS stage. I'm going to show you how to set up shielded clocks, because we are seeing that in 45nm and below, shielding the clocks is more important than ever in order to avoid noise on the clock nets. (Noise on signal nets is bad enough, but if your clocks are affected by noise, then your SI results are going to look REALLY awful.)

At the top of the .ctstch file, you'll want to define your routing rules like this: (I'll use a double-width double-space routing rule as my example, but it can be anything you want. We find good results with double-width double-space and shielding most of the time.)

#-- Wide_wire Route Type --
RouteTypeName DoubleWideDoubleSpace
TopPreferredLayer 6
BottomPreferredLayer 3
NonDefaultRule DoubleWideDoubleSpace
End

RouteTypeName DoubleWideDoubleSpaceShield
TopPreferredLayer 6
BottomPreferredLayer 3
NonDefaultRule DoubleWideDoubleSpace
PreferredExtraSpace 0
Shielding VSS VSS
End

#-- Regular Route Type --
RouteTypeName regularRoute
TopPreferredLayer 6
BottomPreferredLayer 3
PreferredExtraSpace 1
End

Notice that we have 3 sections: the wide-wire type, the same wide-wire type with shields, and then a regular route type. If your design is not too congested, you may not even need the regular route type, but I've included it for completeness.

For the wide-wire route type, it's important to note that we've matched it to a NonDefaultRule. This rule must exist in your tech LEF. (For details on how to create a nondefault routing rule if your tech LEF doesn't come with one, see this previous Five-Minute Tutorial.)

That was easy, right? All we have to do now is tell our clocks how we want each routing rule to be used. This is done in the clock definition section:

#------------------------------------------------------------
# Clock Root   : clk
# Clock Name   : coreClk
#------------------------------------------------------------
AutoCTSRootPin clk
Period         10ns
MaxDelay       1ns
MinDelay       0ns
MaxSkew        200ps
SinkMaxTran    80ps
BufMaxTran     80ps
AddDriverCell BUFX4
Buffer         BUFX1 BUFX2 BUFX4 BUFX8
NoGating       NO
DetailReport   YES
RouteClkNet    YES
PostOpt        YES
OptAddBuffer   YES
RouteType      DoubleWideDoubleSpaceShield
LeafRouteType DoubleWideDoubleSpace
END

What we're saying here is to use the shielded wide rule everywhere except the routes to the leaf pins. There, we'll just use the wide rule without shielding because there may not be room. This is a typical methodology that will work for most designs, but your design may vary. Are things very congested at the leaf route level? Use the regularRoute rule instead. Have plenty of room? Go for shielding at the leaf level too. The key is to go ahead and route the clock nets at the CTS stage with the "RouteClkNet YES" parameter. That way you get more accurate timing results from CTS onward because the clock routes are real (and not trial route estimates).

One final note about the TopPreferredLayer and BottomPreferredLayer: I picked these numbers based on my metal stack. You will have to decide which top/bottom preferred layers are right for you.

That's all there is to it! I hope you've found this Five-Minute Tutorial useful. Don't forget, you can subscribe to the Digital Implementation Blogs so you never miss a new one.

Kari Summers

Encounter Quick Tip: How to Repair Command Line Navigation When Launching via bsub

BobD — Tue, 12 Apr 2011 16:00:00 GMT

When two users report the same issue in the same week I'm glad I can share the problem and solution via this blog.

I know a lot of you work in an environment where you request computing resources via "bsub." In many cases it's frowned upon to request an xterm to launch jobs and it's preferred to start an interactive session with something like "bsub -I encounter." What we were seeing was that command line navigation at the Encounter console was broken when launched via bsub yet was working fine when launched via an xterm. Backspace produced garbage characters like "^H", tab-completion didn't work, and arrow-up (precious arrow-up!) wouldn't retrieve the previously issued commands.

You could barely get around but it was truly painful.

The remedy we found was to launch jobs with "bsub -Ip encounter" instead of just "bsub -I encounter." The "-Ip" asks for an interactive prompt that should enable command line navigation to work as desired.

Hope this is useful. If this works/doesn't work for you -or- you're having any other problems with command line navigation let us know. Little things like that can really affect your impression of the software so I want to make sure everyone's console is working the way it should be.

Bob Dwyer

28 nm IC Design: The Devil Is In The Details

Nora — Mon, 14 Mar 2011 23:00:00 GMT

Smaller process technologies are enticing chip makers with bigger rewards from their end products. The shorter gate lengths at 28nm promise faster transistor speeds and less leakage power, and can double the amount of the logic that can be put into the same die area. Most importantly, however, more die on a wafer means lower per unit cost.

Meanwhile, design complexity is compounded as chip content grows significantly larger. Chip sizes are significantly smaller, but are running faster into the gigahertz range, and they must consume less power. When designers break barriers to pursue new innovations at advanced nodes, design flaws are common and more costly.

A recent highly publicized glitch in the Intel's chipset captured attention from the semiconductor industry, EDA community, and across businesses and consumers. This is not only because Intel's circuitry powers electronic notebooks and laptops which are ubiquitous in our daily life, but it is also because the cost of the flaw is notable. This news serves as another reminder that similar incidents have happened before, and can happen again.

Details are Challenging

How can we prevent a costly design flaw from happening again? The common wisdom tells us that the devil is in the details. Oftentimes, the last 10% of the task is taking care of few neglected design details. Such tasks can take many iterations to resolve, drain more engineer resources, and extend project schedules. From a digital implementation context, design detail refinements usually relate to the tradeoff between meeting performance and power targets while trying to be compliant with the complex physical, electrical, and process rules and guidelines. For example:

Large and complex design rules have a heavy impact on cell architecture as well as interconnect routing topology and via configuration. Cross coupling and resistance in interconnects and vias are a lot higher in 28nm node than previous generations.

Complex via rules

Complex interconnect rules

If stress and litho effect around cell boundary is not accounted for, timing slack and leakage power problems can be more severe. This is due to intra-cell dependence.

Current density per unit area and electromigration are big concerns.
Metal thickness variation has a bigger impact on parasitic resistance and capacitance. Metal thickness modeling needs to consider the chemical mechanical polishing (CMP) effect precisely for density analysis.

Thickness variation

Smaller wires are extremely sensitive to random defects, lithography distortion, and other types of variation in manufacturing process. Such litho effects may create open and short nets after GDSII is created and cause catastrophic problems. If such problems are not prevented and detected early, the design may pass the traditional LVS/DRC verification, but still fail to operate properly in the end.

The designs at 28nm usually have more aggressive objectives for timing, power and higher density. It is very difficult and sometimes impossible to make corrections at a later stage without a redesign. If the above details are not addressed properly and timely during implementation, they can lead to a functional flaw in silicon, or become the designer's nightmare to fix before tape out. Some predict that more than half of the sub-28nm designs are likely to face re-spins one way or another due to these oversights.

Taking Care of Design Details Through a Unified Design Flow

At the 28nm and below process nodes, having a set of best in class point tools provides a good foundation for design implementation success, but not enough to prevent error oversight. It also requires a consistent method to enforce a tighter design discipline from the start. Encounter Digital Implementation System (EDI System) provides a unified constraint driven methodology with an integrated concurrent signoff analysis flow. It systematically evaluates design constraints, and executes design intents and guidelines down to the smallest implementation details across partition boundaries and design hierarchies.

For example:

For placement, its context-aware placement automatically takes intra cell interdependence into account to ensure timing and leakage power objectives are met.
For routing, NanoRoute recognizes lithography unfriendly patterns, takes a "correct-by-construction" approach to route, preventing hotspots in wire configuration on the fly. The last few hotspots left in the circuit are detected by the in-design Lithography Physical Analyzer for timely repair.

Litho unfriendly pattern

For metal density, its smart metal fill is guided by foundry certified CMP model. Thus the thickness variation is factored into the equation when deciding the metal fill shapes and locations.

Many designers from the semiconductor industry, IP providers, and design service companies have already found benefits from this disciplined and unified design flow, and reached design silicon success faster without costly incidents.

To continue to satisfy the design community's insatiable appetite for new innovation, Cadence recently charted a unified path to 28nm silicon realization with the new EDI System 10.1 release. It provides a Silicon Realization flow based on unified design intent, abstraction, and convergence with physical and manufacturing data. A previous blog posting shows how it tackles chip design problems with a unified digital flow.

"Great things are not done by impulse, but by a series of small things brought together" - Vincent Van Gogh

Nora Chu

Encounter Puzzler #3 Solution: Renaming a Net Logically

BobD — Wed, 09 Mar 2011 21:00:00 GMT

Once again, the Encounter Digital Implementation designer community has stepped up to the challenge. Last week's puzzler -- renaming a net logically in Encounter -- was solved in short order. Let's add J2mh and Sims to the list of Encounter Wizards (along with regular commentator and guest blogger Jason G).

To quickly restate the challenge, we wanted to rename a logical net. We wanted to take this netlist:

module testcase ();
wire net;
BUFX1 i0(.Y(net));
BUFX1 i1(.A(net));
endmodule

...and turn it into this:

module testcase ();
   wire new_net;
   BUFX1 i0 (.Y(new_net));
   BUFX1 i1 (.A(new_net));
endmodule

J2mh's solution was very similar to my own -- but his was more concise. Create a new net, and attach each instance terminal connected to the old net to the new net:

proc changeNetName {oldNetName newNetName} {
selectNet $oldNetName
addNet $newNetName
foreach selTerminals [dbGet selected.allTerms] {
attachTerm [dbGet $selTerminals.inst.name] [dbGet $selTerminals.cellTerm.name] $newNetName
}
deselectAll
}

Notice how we don't need to disconnect the old net from each terminal. Connecting it to the new net overrides the connection since a given instance terminal can only be connected to a single net.

attachTerm takes 3 arguments: <instName> <termName> <netName>

When you're iterating through each instance terminal in "net.allTerms" it returns pointers whose "name" is the instance name plus the pin name. Like "i0/A" for example.

I especially liked how he used dbGet to "walk" from each instance terminal to get the inst.name and cellTerm.name to pass the required arguments to attachTerm.

I used a slightly different approach that's probably more error prone. I used "file" commands to decompose <inst_name>/<pin_name>:

set instTermName [dbGet $term.name]
set instName [file dirname $instTermName]
set termName [file tail $instTermName]
attachTerm $instName $termName $newNetName

I like his approach better because it's not splitting strings -- it's getting the name directly from the appropriate db object.

The extra credit to the challenge was to make sure the script worked when renaming a net that connected through hierarchical terminal -- like "net2" does in this example:

module testcase ();
wire net2;
BUFX1 i0(.Y(net2));
a i_a(.in(net2));
endmodule

module a(in);
input in;
BUFX1 i0(.A(in));
endmodule

I thought this was going to be a really complicated case to handle. Sims' approach was what I thought was going to be necessary where we'd need to connect the hierarchical terminal i_a/in to the net at each level of hierarchy. However, I don't think it's that difficult after all. Here's why...

With the netlist above, although there are indeed fractional representations of the net in the db, there is only 1 net in the design in terms of how it is presented to us via dbGet. I've heard this called the "canonical" net name. Therefore, if we connect the input of the buffer within the "a" module to a new net:

encounter 1> addNet new_net2
encounter 2> attachTerm i_a/i0 A new_net2
encounter 3> attachTerm i0 Y new_net2

..."new_net2" is automatically connected through the hierarchical terminal "i_a/in". The netlist would look like this:

module a (
    in);
   input in;

   BUFX1 i0 (.A(in));
endmodule

module testcase ();

   // Internal wires
   wire new_net2;
   wire net2;

   BUFX1 i0 (.Y(new_net2));
   a i_a (.in(new_net2));
endmodule

The final part of the extra credit was to handle the case where the net was connected to a top-level IO port. Like top-level input port "in" in this example:

module testcase (in);
input in;
BUFX1 i0(.A(in));
endmodule

This too was a little easier than I expected, but in an interesting way. Rather than having to create a new top-level port and connect it to a newly-created net, when you create a new top-level port a new net is automatically available. Or, if you create the net first and then create a new top-level port the two are automatically associated.

addModulePort takes a moduleName -or- uses the special character "-" to denote addition at the top level:

Usage: addModulePort
addModulePort <moduleName> | - <portName> {input | output | bidi}

For example:

addModulePort - new_in input

It's worth mentioning why dbGet calls the list of terminals associated with the "net" object "allTerms" instead of "terms" or "instTerms". It's called "all" to indicate the list of objects may contain a mixture of top-level terminals ("terms") and instance terminals ("instTerms").

Stringing this all together, we can check the object type of each terminal in the allTerms list and do something different depending on which it is:

proc userChangeNetName {oldNetName newNetName} {
set net [dbGetNetByName $oldNetName]
addNet $newNetName
foreach term [dbGet $net.allTerms] {
    if {[dbGet $term.objType] == "instTerm"} {
      set instTermName [dbGet $term.name]
      set instName [file dirname $instTermName]
      set termName [file tail $instTermName]
      attachTerm $instName $termName $newNetName
    } else {
      addModulePort - $newNetName [dbGet $term.inOutDir]
      deleteModulePort - $oldNetName
    }
}
deleteNet $oldNetName
}

All of this made me realize it would be a good to have native net-renaming functionality in the tool so I filed a reuquest asking for an enhancement. Hopefully this served as a useful example of how db access can help bridge the gap between current capabilities and something we as users need to accomplish.

When performing netlist manipulations like these it's always good to check your work. I'm sure many of you are familiar with the Encounter Conformal Equivilence Checker which provides (among other things) a quick and easy way to make sure two Verilog gate level netlists are functionally equivilent.

Thanks again for participating in these puzzlers. I'll follow-up soon with another (designers have been sharing some great challenges lately!). It would be great if you subscribed to these blogs so we can keep in touch.

Bob Dwyer

Encounter Puzzler #3: Renaming a Net Logically

BobD — Mon, 28 Feb 2011 23:00:00 GMT

The other day a designer E-mailed me: How can we rename a net in Encounter?

I followed up to clarify whether the designer wanted to change the net associated with routed wire segments, or wanted to rename a signal net. He clarified that he wanted to change a logical signal net's name.

Changing the net name associated with a routed wire segments is described in this solution:

editSelect -nets VDD1
editSelectVia -nets VDD1
editChangeNet -to VDD2

However, it's not so easy to change a logical net name in Encounter. The "name" field for a net isn't editable in the Attribute Editor, there is no "dbSetNetName" command, and dbGet says the "name" attribute of the "net" object type isn't settable:

encounter 1> dbGet top.nets.?h
name: string, Canonical (flat) name of the net

If an attribute is settable dbGet will say "settable" after the attribute name. For example:

skipRouting(settable): bool, Specifies that Nanoroute should not route or re-route the net.

So how can we change the net name programatically? How would we take this netlist:

module testcase ();
wire net;
BUFX1 i0(.Y(net));
BUFX1 i1(.A(net));
endmodule

...and turn it into this:

module testcase ();
   wire new_net;
   BUFX1 i0 (.Y(new_net));
   BUFX1 i1 (.A(new_net));
endmodule

Today's puzzler is to write a TCL script called "userChangeNetName" that changes the logical net name of nets programmatically:

proc userChangeNetName {oldNetName newNetName} {
<your solution here>
}

Leave your solution as a comment below. I'll post further discussion and a round-up on Friday.

We're looking to change the net name logically so don't worry about things like wire segments or physical I/O pins.

For extra credit, check whether your scripted solution can handle the case where the net is connected to an I/O port and/or connected through Verilog hierarchy like top-level net "in" and "net2" in this example:

module testcase (in);
input in;
wire net1, net2;
BUFX1 i0(.Y(net1));
BUFX1 i1(.A(net1));
BUFX1 i2(.A(in));
BUFX1 i3(.Y(net2));
a i_a(.in(net2));
endmodule

module a(in);
input in;
BUFX1 i0(.A(in));
endmodule

Related Reading:

Encounter Puzzler #1: Where did my fences go?
Encounter Puzzler #2: Finding registers beneath a hierarchy

I'll look forward to seeing your solutions!

Update: Click here to see solutions and discussion about this puzzler

Bob Dwyer

Tortoise Versus Hare … or How to Improve Your Time to Tapeout Using In-Design Signoff

PeteMc — Wed, 23 Feb 2011 19:00:00 GMT

Now that Wei Lii Tan has helped you with your New Year’s resolution to “create a chip that is so compelling …” in his previous blog, I would like to help you understand how Cadence is using our signoff qualified engines during the design implementation flow to reduce your time to tapeout.

Anyone remember the story of the tortoise and the hare from your childhood? The moral of the story is that simply being fast isn’t always better, and in a way that is very much like using signoff quality engines during the design implementation flow. Let me explain …

Traditional design methodologies that have been established over the years were optimized for runtime, mostly by trading off accuracy. By reducing runtimes at points in the design where accuracy wasn’t needed, a design could progress more rapidly to signoff. On the surface, this seems like a very logical approach to take. However, deeper analysis shows that this might not always enable the fastest time to tapeout.

While the runtime for individual parts of the flow can be improved by trading off accuracy for increased performance, many of Cadence’s customers have already reflected that the bigger problem is repeating implementation steps to address violations that are only found during late-stage signoff.

In fact, such customers have already experienced that using signoff quality engines during the design implementation flow actually improves time to tapeout by enabling better convergence in the solution. While it does take slightly longer to run the signoff engines in the flow, the additional time is quite small compared to having to repeat steps through the back-end design methodology to fix problems.

OK, let’s get even more specific with an example.

Consider that the routing engine of an ASIC solution does not manage all of the additional complex rules required at 28nm and below. After the routing is finally completed, often following many optimization loops to address timing violations, the design meets the timing requirements and is ready for final signoff. Unfortunately, signoff DRC checking now flags that the router didn’t meet all of the design rules, forcing the design team to fix the routing … but the router isn’t aware of the complex rules that have failed, and so an automated fix is impossible. Instead, the design team must manually fix the additional DRC violations, and that’s ECO hell!!!

Now consider the alternative solution. The router is enabled with signoff quality DRC checking and so avoids creating DRC violations … admittedly, the router takes slightly longer to run, but once timing closure is attained, the design team can have confidence that no additional DRC violations will be found at signoff.

While the above example explains how time to tapeout can be improved for DRC checking, consider that all signoff components could result in similar issues. At Cadence, I am proud that we have a very comprehensive suite of signoff solutions that can execute separate standalone signoff, or enable our signoff engines integrated within our Virtuoso custom IC and Encounter digital platforms.

Included in the signoff suite are products that enable the following functionality (Cadence product names are in parentheses)

Parasitic extraction (Cadence QRC Extraction)
Physical verification (Cadence PVS Design Rule Checker and Cadence PVS Layout vs Schematic Checker)
Static timing and SI analysis (Encounter Timing System)
Power integrity analysis (Encounter Power System)
Litho hotspot detection and analysis (Cadence Litho Electrical Analyzer and Cadence Litho Physical Analyzer)
CMP analysis (Cadence CMP Predictor).

So, just like the tortoise and hare story, faster runtimes might sound like the best option, but faster time to tapeout requires a different approach.

Pete McCrorie

Evolution of Design Exploration and Planning

abham — Thu, 17 Feb 2011 19:00:00 GMT

The great architect Frank Lloyd Wright once said "you can fix it on the drafting board with an eraser, or on the construction site with a sledge hammer." The semiconductor design industry is a perfect example where finding issues later in the flow can be extremely expensive. Chips that fail in high-volume consumer products can cost companies hundreds of millions or even a billion dollars, and there is huge benefit to validating the design and identifying and fixing issues early in the design process.

To address this issue, First Encounter introduced the concept of design exploration and planning in IC design nearly 10 years ago. This enabled designers to build early prototypes of their chips and resolve issues that usually came late in the design cycle, along the critical path toward reaching final tapeout. This significantly reduced the overall turn-around time of the design flow and provided huge gains in productivity and predictability of the design process and schedule. Design exploration and planning has since become an integral part of any IC design flow and has changed significantly over the years to keep up with the growing chip size and complexity in accordance with Moore's Law.

Robust Hierarchical Methodology

While hierarchical methodologies were fairly immature back in the days as most designs were done flat or bottom-up, today any productive design exploration and planning solution requires a robust hierarchical methodology to support the big designs of today. Cadence has been a leader in this area, and both First Encounter and the Encounter Digital Implementation System support various hierarchical design styles such as channel-based, channel-less, micro-channels or master-clone.

The hierarchical support in Encounter helps physical designers assess how best to partition the logical hierarchy into physical modules by analyzing the optimal pin assignments; creating accurate time budgets; accurately predicting the clock distribution networks; analyzing the power grids; and eventually generating complete timing and physical constraints for each of the physical modules. To further handle the Giga-Gate designs of today, we have developed a new data abstraction technology. This unique capability allows netlist compression up to 90% while maintaining relevant timing and congestion information, resulting in faster turnaround time and one pass implementation handoff.

Implementation Quality Automation

In addition, the growing chip functionality in a shrinking time to market window demands increasing automation to get early feedback, while still providing results good enough for implementation. A case in point is the automation in macro placement. To address the ever-increasing number of hard macros on a design, Automated Floorplan Synthesis in First Encounter now enables concurrent standard cell and macro placement that helps designers to generate implementation quality floorplans for both flat and hierarchical designs.

The Floorplan Ranking capability further empowers designers to general multiple floorplans in parallel and rank them based on different criteria such as timing and area. This enables designers to do a quick feasibility analysis and make informed trade-offs early in the floorplanning stage.

Low-Power Support

Furthermore, there is growing concern for advanced-node support and low-power today as wireless chips dominate the consumer market. To address this, First Encounter also supports the Common Power Format (CPF), advanced low-power techniques, and design-for-yield capabilities that are critical for power hungry and advanced node designs.

First Encounter today is an integral part of the Cadence Digital End-to-End Solution. It paves the way for Silicon Realization by providing a comprehensive design planning and debug environment that captures the design intent upfront, enables large scale designs with its unique abstraction capabilities and provides a predictable convergent path for hierarchical design closure. With the ever-growing chip complexity, design planning and prototyping will continue to gain significance in the IC design flow. The pay-offs will be in the form of overall increased productivity, predictability and profitability. I am sure we will continue to see growing innovation in this area and it will be fascinating to see how this space reshapes in the future.

Abha Maheshwari

Guest User Blog: dbShape For All Your Logical Operation Needs

BobD — Wed, 16 Feb 2011 19:00:00 GMT

This is a guest post from Jason Gentry at Avago. I hope you enjoy this useful piece he's contributed on using the Encounter Digital Implementation System's dbShape command that debuted in 10.1.

I figured it was time for another guest blog, especially since I've been able to play with one of the new-to-EDI10.1 commands called "dbShape." During CDNLive! 2008, one of the topics I talked about was my need for logical operations or LogOps for short. Think basic OR, AND, ANDNOT, etc. operations on physical geometries. I had Tcl-implemented versions of these that worked well (N-log(N)) but their performance was really poor when dealing with a large number of shapes (N). Well, apparently Cadence was listening and decided to bolt-on a shapes engine. EDI10.1 introduces the 'dbShape' command and it is a thing of beauty. The usage is as follows:

Usage: dbShape [-help] [-d] [-step <step>] [-output <polygon|rect>]
             <shapeList> [AND <shapeList> | ANDNOT <shapeList> | OR <shapeList> | XOR <shapeList>
             | SIZE <value>| BBOX | MOVE {<dx> <dy>}] ...

-help            # Prints out the command usage
-d               # User specified values and return values are in database units.
                 # Default: All values are in user units, in microns. (bool, optional)
-step <step>     # Specifies step size if output format is rect, required to convert
                 # non-orthogonal shapes into series of rectangles. Default: minwidth
                 # value of first routing layer (coord, optional).
-output <polygon|rect>
                 # Specifies the output format. default: rect (string, optional)
<shapeList>      # polygon or rect or list of polygon and rect. polygon:
                 # {{x y} {x y} {x y} ... }; rect: {x1 y1 x2 y2} (list, required)
AND <shapeList> # binary operator: intersection of shapeLists
ANDNOT <shapeList> # binary operator: initial shapeList minus <shapeList>
OR <shapelist>   # binary operator: union of shapelists
XOR <shapeList> # binary operator: OR minus AND of shapeList
                 # (string, optional)
SIZE <value>     # unary operator: increase the size of shapeList by <value>
MOVE {<dx> <dy>} # unary operator: move the shapeList by {<dx> <dy>}
BBOX             # unary operator: computes the bounding box of shapeList
                 # (string, optional)

I've since replaced all of my low-level LogOp procedures with calls to dbShape. I've seen some performance improvement but it wasn't until I re-architected some of my biggest programs that I saw a major impact. One such script, a custom power grid insertion script, went from running in 8-9 hours to running in 1/2 an hour. It ran so fast I had to double check that my power grid actually got inserted. Below are some examples of each of the available operations (note that I use the '-output rect' option for all of these to simplify the illustrations but it is not necessary).

set shapes1 [list [list 100 100 1100 1100]]

set shapes2 [list [list 300 300 500 500] [list 700 700 900 900]]

set shapes3 [list [list 500 700 1200 900]]

LogOp OR:
dbShape -d -output rect $shapes1 OR $shapes3

LogOp: AND
dbShape -d -output rect $shapes1 AND $shapes2

LopOp: ANDNOT
dbShape -d -output rect $shapes1 ANDNOT $shapes2

LogOp: SIZE
dbShape -d -output rect $shapes2 SIZE 100

There are some limitations that you should know about before you write your own scripts:

- There is only a 'SIZE' logop, no 'SIZEX' or 'SIZEY' for sizing only one dimension. This has caused me some headaches but I've gotten around it for the most part for now, albeit inefficiently.

- The is no 'INTERSECTS' LogOp; a LogOp that returns all shapes that intersect the specified shapeList. Think 'AND' without modifying the original shapeList. This would be really nice for finding floating power wires (wires with no vias connecting to it).

- If you choose to work with rectangles (-output rect), all of the rectangles are returned in maximally-vertical form. In other words, the resulting rectangles will be cut such that they are as tall as possible. You might ask, "Why do I care?" The only time that I've needed to care whether I have maximally-horizontal versus maximally-vertical rectangles dealt with trying to compute spacing requirements. The "run-length" of a given shape may change depending on whether or not it appears very long or very short. I've included images below showing the above ANDNOT example with maximally-horizontal and maximally-vertical configurations.

Maximally-Vertical Rectangles:

Maximally-Horizontal Rectangles:

- You can daisy-chain the operations. This is best shown through example:

dbShape -d -output rect $shapes1 OR $shapes3 ANDNOT $shapes2

-Jason Gentry

Related Post: Using dbTransform to Translate Geometric Coordinates in Encounter

Tackling your Greatest Chip Design Challenges with the Cadence Digital End-to-End Flow

Design4Life — Mon, 31 Jan 2011 13:01:00 GMT

It hasn't been that long, but do you recall your new year's resolution? Eat healthier? Have more work-life balance? Exercise more?

Or, what about, "create a chip that is so compelling and useful, it blows everybody's socks off in the semiconductor industry?"

If the latter is your new year's resolution, then I am excited to tell you about a flow that was unveiled today (Jan. 31, 2011) and can help you achieve it. Just hours ago, we unveiled the Cadence Digital End-to-End Flow, an integrated RTL-to-GDSII flow that we believe is the next step forward in digital design, implementation and verification. This includes the award-winning Encounter Digital Implementation System (including implementation and in-design signoff technologies), Encounter RTL Compiler, Encounter Conformal technologies (including Logic Equivalence Checking, ECO Designer and Conformal-LP), as well as Encounter Test.

Corporate marketing phrases aside, the Cadence digital end-to-end solution is actually the result of countless hours of listening to our customers and partners, prioritizing what needs to be done to enable the next generation of digital designs, and then hunkering down to implement them in the software.

What our Customers Have Asked For

We've learned a lot from our customers and the semiconductor industry in general, and I'd like to share a little about what we've learned. We knew performance requirements and the sheer size of today's designs would outgrow EDA capabilities if we didn't do something about it. The walls between synthesis and physical implementation are coming down quickly, as physical effects play a more important role up front. Also, the amount of manual work required for large-scale ECOs has become unmanageable.

Besides those core requirements stated above, there are design categories that were previously considered non-mainstream designs, but are considered mainstream today -- namely, mixed signal and low power designs. As custom designs grow in size and complexity, the automation provided in digital solutions is a natural progression in terms of productivity -- but only if the digital tools are made accessible enough to custom designers, in terms of tool familiarity, and of course the ease of maintaining design intent and database coherence between the two domains.

As power consumption targets become a hard requirement instead of the "see how much we can save" approach, designers are paying more attention to having convergence to a set power target throughout the design flow. This means designs have to meet all requirements -- power, performance and area, and often in that order, especially for mobile devices. In other words, there's no backing out of power requirements just to meet timing.

Finally, leading-edge customers of ours want more integration of advanced technology. As 28nm/32nm processes gain popularity and process design rules become more complicated, it is important for EDA companies to collaborate with foundries to streamline the handling of the newer design rules. Vertical chip packaging schemes are being extended to the SoC level, introducing a new category -- the 3D stacked die design environment. This will bring about significant benefits, including the reduction of interconnect bottlenecks and the ability to have heterogeneous processes coexisting in the same package. But these benefits also introduce new challenges to the design methodology.

The Cadence Digital End-to-end Flow

So, how does the Cadence digital end-to-end flow address the challenges outlined above?

We have updated the core design closure engines. Logic synthesis now has improved physical awareness, resulting in a more convergent RTL-to-GDSII flow. Physical implementation optimization engines have been vastly improved with an in-design advanced analysis engine that provides ultra fast, concurrent signal integrity and timing analysis that is capable of reducing SI closure runtime by half, and reduce iterations by providing more convergence. We also now have a standardized, single-option high effort flow that can be put through the toughest, most timing-critical designs, as opposed to requiring the designer to come up with a custom script. This design closure methodology fully supports 28nm/32nm design rules. In fact, we have streamlined 28nm/32nm rule support such that routing speed for 28nm/32nm designs in this release has been sped up by 2X compared to the previous 9.1 release.

To address designs in the 100 million instances range, we have developed new data abstraction technology that provides a new way for entire blocks of logic to be modeled simply and accurately, resulting in runtime improvements of 20X or more. This enables designers to tackle ultra-large designs with reasonable runtime. Also, to address the ever-increasing number of hard macros on a design, we have revamped our automatic macro placement engine to be more intelligent than before, and to produce results that resemble hand-placed floorplanning.

ECO-weary customers (i.e. everyone in semiconductor design) can expect significant improvement in the way large-design ECOs are done. With the Cadence ECO Designer, part of the digital end-to-end flow, we now have a much more automated way of implementing RTL ECOs all the way from ECO synthesis to physical implementation. The bottom line is: more automation in generating the ECO netlist, and more automation in implementing that netlist with your ECO cells.

We have also enhanced our constraints-driven mixed signal flow, allowing intent to be effectively conveyed between digital and custom design. Among the enhancements is the ability for accurate full mixed-signal static timing analysis and timing-driven physical implementation to eliminate iterations between analog and digital design teams. Low power designers will benefit from more automation and ease-of-use in our correct-by-construction approach. A notable improvement is the power intent architect, which is a much-requested feature that allows power intent to be created and validated by the tool, using an intuitive user interface. A second highlight is an enhancement to physical synthesis to enable smarter clock gating through Clock Topology Planning (CTP); leveraging physical information early in the flow during synthesis to create smarter clocks, leading to lower power chips.

Last but not least is something that I am very excited about, not only because it's a significant leap forward in terms of chip design and packaging, but the potential it has to bring about some major breakthroughs in chip design: 3D-IC design. The Cadence digital end-to-end flow includes the first production release of a fully integrated 3D-IC design environment. In short, we now have a full-featured consistent design, implementation and verification environment across digital, full-custom, and packaging environments, driven by unified 3DIC design intent, that allows designers to fully realize their 3D-IC design and benefit from the ability to reduce interconnect bottlenecks and realize heterogeneous processes on a single package.

What Does This Mean to You?

Last October Cadence announced our new approach that delivers a deterministic path to Silicon Realization by creating a design flow based on the three requirements of unified design intent, design abstraction and design convergence. In other words, by providing a flow in which design intent is pervasive (instead of having different parts of the flow interpret design intent differently), uses the appropriate levels of abstraction (such as hierarchical abstraction, or other modeling technologies such as the new advanced analysis engine for signal integrity and timing) to deliver better speed and capacity, and last but not least, ensuring a highly convergent flow, we aim to provide you with the solution that gives you fastest path to successful silicon.

The Cadence digital end-to-end flow is part of our Silicon Realization goal. But don't just take our word for it -- as you hear more about it in the coming months, I invite you to give it a try, and if you already have, feel free to comment below on your experiences so far.

What's Next?

You can find out more about the Cadence digital end-to-end flow from the article located here. Or, check us out this week at DesignCon 2011. Hope to see you there!

Wei Lii Tan

Advanced Maneuvers in Feedthrough Insertion: Maximizing Routability while Minimizing Port Creation

BobD — Mon, 10 Jan 2011 17:00:00 GMT

Previously I wrote about the basics of feedthrough insertion in Encounter. Today I'd like to push into a tiny but powerful example of how Encounter's feedthrough insertion solution can derive solutions that enable rapid top-level design closure.

Feedthrough insertion in Encounter has two modes of operation: Placement-based -or- route-based. The advantage of route-based is its awareness of congested vs. sparse areas of the design. Encounter's high capacity virtual flat view of the design combined with hierarchically aware track-assignment-based trial routing provides design insight not usually available until after partitioning and reassembly. We can use this information to derive feedthrough insertion and pin assignment with a high degree of routability.

Once we embark up on deriving feedthrough insertion solutions based on trial routing, some interesting situations arise. Take for example the one pictured below. The design has 4 partitions. The example net potentially in need of feedthrough insertion is driven from an instance within the partition on the lower left to a partition on the upper right. I've highlighted the net showing how it crosses over the neighboring partition to the lower right:

If we run route-based feedthrough insertion it will follow the topology of the net, determine which partitions it crosses, and insert feedthroughs generally along the route.

Here is the command:
insertPtnFeedthrough -chanLess -doubleBuffer -routeBased

And here is the result:

After performing pin assignment (assignPtnPin) and commiting the partitions (partition) the result is neatly aligned connections on the partitions with no top level routing crossing over partitions:

This solution is fine, but what if we wanted to reduce the number of ports created and feedthrough buffers inserted? For this particular net we could avoid the need for feedthrough buffers all together if we instead assign the partition pins for the lower left and upper right partition along the common edge they share in the center of the design.

But how can derive the benefits of route-based feedthrough insertion while still detecting situations where it would be better to instead simply align pins on common edges in situations like this? There's a very useful switch called "-preferPinAbutment" that will give us the best of both worlds. With it, the tool will perform route-based feedthrough insertion and back off in situations where a common edge is available -- unless the common edges are highly congested.

insertPtnFeedthrough -chanLess -doubleBuffer -routeBased -preferPinAbutment

I remember working with our developers on this capability years ago. I thought it was a stretch when I asked them for it but I was pleased when they implemented it. There are a number of other capabilities insertPtnFeedthrough has that are subtly powerful. I'll be talking about them in future blog posts.

Have you used Encounter's feedthrough insertion functionality? If so I'd love to hear what's working and what's not in the comments.

Bob Dwyer

Planning for Hierarchical Design Success: Do You Have a Robust Feedthrough Insertion Solution?

BobD — Mon, 27 Dec 2010 14:00:00 GMT

Feedthrough insertion is a subtly crucial task that naturally arises in hierarchical digital design. There are several types of approaches we can use to allow signals to traverse across a chip, but the most common and effective I've seen is where buffers are inserted in neighboring partitions. This eliminates top-level routing and more importantly takes the top-level timing closure task and makes it part of block-level timing closure. In Encounter this capability is accessed through the TCL command insertPtnFeedthrough.

Here's a picture to describe what I'm talking about. Say we have 3 partitions: a, b, and c. A signal that originates in "a" and connects to "c" traverses over "b":

If we don't perform feedthrough insertion, what we'll get is a net that traverses over partition "b". This is unacceptable in scenarios where all layers are reserved for partitions, and in scenarios where some layers are reserved for over the block-routing we get into a difficult situation because we can't insert buffers on nets that exceed the maximum distance required for rebuffering. See below what the design would look like after buffering without feedthrough insertion:

If we use insertPtnFeedthrough, the tool will:

Insert buffers within "b" for each entrance and (optionally) exit required to traverse the partition.
Create new ports as needed on the partitions to make new connections. In this case, 1 new input and 1 new output port is needed on "b".
Create new top-level logical nets as needed to connect to the new ports.

Here's what the design would look like after feedthrough insertion (insertPtnFeedthrough -chanLess -bufCell BUFX1 -doubleBuffer) prior to partitioning:

Once the buffers have been inserted we can place the partition pins (assignPtnPin) and commit the partitions (partition is the command). The result should be a design where connections between neighboring partitions consist of only 2-pin nets between abutted edges (or in the case of design with small roughly 10 microns channels, short jumper wires connecting the partitions):

So that's how feedthrough works in its simplest sense. In this context it's tempting to consider writing a script to do this at the logic synthesis stage. But feedthrough insertion is much more complex in practice. In upcoming blog posts I plan to focus on more advanced scenarios to give you a sense of what to prepare for in terms of making sure the tools you're using are up to the task.

I'd love it if you subscribed to our Digital Implementation RSS feed -or- via E-mail at the form on the right side of this page so we can continue the conversation.

Bob Dwyer

CDNLive! Silicon Valley 2010: User Papers Explore Digital Implementation

BobD — Thu, 04 Nov 2010 16:00:00 GMT

I previously wrote about the general session of the 2010 CDNLive! Silicon Valley conference, focusing on what EDA360 means for Digital Implementation engineers. Today I wanted to share a little more about a couple of papers I co-presented along with Cadence customers. I enjoy co-presenting with customers where I, as a Cadence Applications Engineer, describe a piece of functionality in the system and then a customer describes how they brought it to bear on a real-world design challenge. It's not always pretty or perfect but it is almost always useful. The best part of conferences like these is the chance to connect other users with the same hyper-specific interests as you have, and then hopefully stay connected with them via the Cadence.com Community or on other social channels.

Proceedings for the conference have been posted. Click here to access CDNLive! Silicon Valley 2010 On-Demand where you can access slides for the presentations described below, along with (optionally) listening to audio recordings of the presentations along with slides. You'll need a Cadence.com account to view the content. If you don't have one you can get one here.

In the first presentation I was involved with, Ranjit LoboPrabhu from Netronome described how they implemented a post-mask Mega-ECO. Post-mask meaning all of the base layers were frozen so no changes could be made to the instances in the design, and "mega" meaning a large amount of changes were being made. ECOs like this are complex because all the changes need to be made using spare cells -- or by reclaiming dormant logic if not enough spare cells are available. Ranjit (photo below) shared how they leveraged Conformal ECO Designer along with the Encounter Digital Implementation System's "ecoDesign" super-command to achieve their design goals. Judging from the amount of audience interaction during the session, I think attendees appreciated the level of technical detail in the presentation.

Next, Jason Gentry from Avago Technologies presented on extending the Encounter Digital Implementation System GUI in version 9.1. You might remember his name from a guest post he wrote about the dbTransform command. In the 9.1 release, Encounter switched from having an entirely tk-based GUI to being Qt-based. That changed the way we as users interact with and extend the main GUI. If you've tried to source an Encounter script written for version 8.1 or earlier that attaches a new item to a pulldown menu and received a message saying bad window path name ".m" this presentation was right up your alley.

Thanks to everyone who participated in the conference, especially those who introduced themselves saying they participate in the Cadence.com Digitial Implementation Community. It means a lot to me. I'll look forward to continuing the conversation and seeing you at a future Cadence event!

Bob Dwyer

CDNLive! Silicon Valley 2010: What EDA360 Means to Digital Implementation Engineers

BobD — Wed, 27 Oct 2010 18:00:00 GMT

CDNLive! Silicon Valley 2010 -- our user's group meeting and more -- kicked off yesterday morning at the Fairmont Hotel in San Jose, California. It's been 2 years since the last CDNLive! (last year's event was online-only) where I captured this video of our Encounter software running though VPN/VNC on an iPhone. I was thinking this morning: How are we going to top that? What is going to be the thing I remember most at this year's event?

Well, for starters I grabbed a seat near Richard Goering, Gary Smith, and John Cooley who -- collectively -- have probably written 90% of the content I've consumed while working in the semiconductor and EDA industries for the past 13 years. It was great to see these guys in attendance along with other distinguished members of the press covering the event. Although I'm a Cadence employee I share these observations from the perspective of a typical engineer. I hope they're useful in getting a feel for the tenor and topics discussed in the morning session at this year's conference.

The morning agenda had our executives describing what we're working on at Cadence at a high level, what our strategy is, and what makes Cadence special. First, we heard from our President and CEO Lip-Bu Tan who shared that design costs are greater than mask costs. Automation, he suggested, is the way forward. Next, our Chief Marketing Officer John Bruggeman (image below) delivered a focused and deliberate message about what EDA360 is and why customers should care about it.

He went into detail about System Realization, SoC Realization, and Silicon Realization and shared an anecdote I found interesting. He said that the average American television set has a lifespan of 15 years. That business model is undesirable when contrasted with a typical smartphone business model where the consumer pays for the handset, pays for a service contract, and then pays for apps and content on top of it. When John unboxed a television set he recently purchased he booted it up (as opposed to "plugging it in" or "turning it on") -- and was presented with an app-like user interace similar to the iPhone. He used this as an example of how technology businesses need to fundamentally rethink the way they deliver their solutions to delight end users and then earn a revenue stream from them.

Chi-Ping Hsu is our Senior VP of R&D in charge of Silicon Realization. Responsibility for the Encounter Digital Implementation System, my area of expertise, falls within his organization. He talked about EDA360's concepts of intent, abstraction, and convergence and how those concepts drive product direction. He noted that design costs are greater than mask costs and suggested that automation is the way to reduce design costs.

Next up was Dave Desharnais, Product Marketing Group Director, also in Silicon Realization. For the engineers in the room, this was likely a highlight of the morning because he delivered a demo which showed a tangible example of how an EDA360 concept meaningfully touches backend design. A key topic that came up throughout the day was Mixed Signal design. He showed how a top-level analog designer could easily interact with digital IP in their design by analyzing pin assignment quality in Virtuoso and then moving over to Encounter to implement the details of the pin move while keeping the top and bottom levels in sync. This is a simple task conceptually which can be complicated if analog and digital design teams and/or tools aren't well aligned. Here's a photo of Dave in front of one of the biggest screens I've ever seen an EDA demo on:

So that took us to our first break. Quite a session from the high-level to the mid-level, conceptually. Check back later for some thoughts on the excellent customer presentation from Ty Garibay from Texas Instruments and a panel discussion on EDA360 in the Real World. I'll also go into a couple of papers I co-presented with customers and talk about perhaps the best part about conferences like these -- the side discussions that occur with people with similar areas of experience and expertise.

If you're looking for a nice meal while you're out here I have a couple of suggestions. One of my favorite restaurants in downtown San Jose is Il Fornaio inside the nearby Sainte Claire Hotel. The Pizza Fradiavola ($13.79) includes mozzarella, tomato sauce, Italian sausage, mushrooms, bell peppers, red onions, and spicy peperoncino oil. Delicious. Looking for a nice steak? The Grill (attached to the Fairmont) serves up nice stuff with great service in a classy environment. Pricey, but very good.

I'd love it if you subscribed to the Digital Implementation blogs (via E-mail or RSS) so we can continue the conversation.

Question of the Day: Are you out here at the conference? What did you think of the morning session?

Bob Dwyer

Five-Minute Tutorial: ecoAddRepeater

Kari — Tue, 19 Oct 2010 20:00:00 GMT

In today's tutorial, we're going to talk about the Encounter Digital Implementation (EDI) system command ecoAddRepeater. You may have come across this command and even used it before, or perhaps you used the GUI (Optimize->Interactive ECO...) to add buffers or inverters, and didn't know that this was the command doing the work. Either way, let's review some reasons we'd want to use such a command.

Fix a few remaining hold violations by adding a small buffer at the endpoint
Add delay to data paths you're trying to skew-match
Buffer a path to fix an AC Limit violation
Buffer a path to reduce SI sensitivity

These are just a few cases; you can probably think of other times were you would use or have used this kind of functionality. We'll use the case of fixing some remaining hold violations by adding a small buffer at the endpoint as an example.

The command itself is pretty straightforward. For our hold-fix example, we'd use something like the following:

ecoAddRepeater -term reg1/D -relativeDistToSink 0.1 -cell BUFX2

The -term and -cell arguments are fairly obvious: the pin you want the new buffer to drive, and the type of buffer to add, respectively. But what's the -relativeDistToSink? That's how close to the -term you want to buffer to be placed. The allowed range is between 0 and 1, with a small number (like 0.1 in the example) meaning that the buffer will be placed near the sink (the reg1/D pin here). If we want the buffer to be placed close to the driver of the net instead, we could specify something like 0.9 or 1.

If you enter the above command, you'll see that EDI takes a few minutes while a refinePlace is called and the timing is updated. Not a big deal if you're only adding one buffer. But what if you're adding 10 buffers, or 100 buffers, or more? You don't want to sit there and wait for each one. This is where setEcoMode comes in. We can set a few things with setEcoMode so that refinePlace and a timing update are not run after each ecoAddRepeater command. This way, all of our ecoAddRepeater commands will run very quickly, and we'll just do a refinePlace and update timing at the end. Here's what you need to set:

setEcoMode -refinePlace false -updateTiming false

The key is to remember to run refinePlace after you're all done, otherwise your ecoRoute and timing will be a mess! We can also use a foreach loop to make it easier to script up a lot of ecoAddRepeater commands. We'll use just 3 endpoints in this example, but you'll get the idea. This is a very common ecoAddRepeater script that I use on almost every project:

setEcoMode -refinePlace false -updateTiming false

set endpoints { \
"reg1/D" \
"reg2/D" \
"reg3/D" \
}

foreach endpoint $endpoints {
ecoAddRepeater -term $endpoint -relativeDistToSink 0.1 -cell BUFX2
}

refinePlace -preserveRouting

setNanoRouteMode -routeWithEco true
globalDetailRoute

Notice the -preserveRouting flag for the refinePlace command. Usually, when you're at the point of fixing those few last hold violations, you don't want to disturb your design too much, so you don't want the routing of the new nets created by adding repeaters to be ripped up. You want as much of it kept as possible, and ecoRoute will just fix up the wires it needs to in order to connect your new buffers.

We've been using buffers in this example, but you can use ecoAddRepeater to add inverters too. Just specify your inverter with the -cell argument (-cell INVX2, for example), and ecoAddRepeater automatically knows to add two of them in series so that your logic polarity is preserved.

HOMEWORK: How would you use ecoAddRepeater to add a buffer right in the middle of a given net? (Hint: Check out the EDI System Text Command Reference for all the options of ecoAddRepeater.) Feel free to post your answer in the comments.

There is a lot more that you can do with this command, either at the command line or with the Interactive ECO GUI Form, but that's all the time we have for this five-minute tutorial. I encourage you to investigate more on your own. This one simple command can lead to some creative solutions to unique problems. If you've used ecoAddRepeater to do something interesting, let us know about it!

Still haven't subscribed to the Digital Implementation Forum Blogs? What are you waiting for? Do it here.

3D-IC TSV Realization: The Race Has Begun!

samtabansal — Tue, 12 Oct 2010 21:00:00 GMT

3D IC discussions are creating quite a buzz these days. No conference is complete without a mention of 3D ICs, and there are reasons behind that. 3D ICs using through-silicon vias (TSVs) help you meet challenging performance and power targets to serve the growing demands of the networking, graphics, wireless, and computing industries. And don't forget consumer needs for ultra light and thin devices!

If you have anything to do with memories or with GPUs, or with designing logic to interact with the analog and RF components for the markets I mentioned above, you probably know what I am talking about. If you have not looked at 3D-IC TSV technology yet, it's a good time to do so now.

What's Needed for 3D IC Realization

There are a few technology requirements for 3D IC Silicon Realization:

An integrated digital, analog and packaging environment: This serves as a foundation to enable heterogonous integration of various components like analog, RF, logic, and memories, which may be at different process nodes, for 3D IC stacks. Any solution is incomplete if it can't marry these platforms together.
3D floorplanning and implementation: This environment helps with critical tasks such as placing microbumps for TSVs, optimizing the stack for timing and thermal management, routing the signal and power lines across multiple die, and placing landing pads.
Thermal and IR drop analysis: Signal integrity, IR drop, and thermal analysis and management become very critical on stacked chips. One can only imagine how easy it will be to melt a chip if memory and logic are not stacked properly. Heating and cooling are important considerations.
Design for Test: During the 3D Panel at the recent LSI Innovation Acceleration conference, 3D design for test (DFT) was agreed upon as a challenge in this space. How will we test the entire system and diagnose potential problems? Who will own the stack and yield issues - foundries or OSATs?
System level exploration: This is certainly important once we start planning in 3D, but I think there are many other problems for 3D community to sort out before this.

I began studying this technology years ago wondering if it would ever become real. I remember when a colleague of mine shared an article that he had written 22 years ago that had a mention of 3D ICs. But now I can see that it is real because the need is real and is urgent. Moore's Law is not going anywhere anymore, "more" needs to be done to deal with the CMOS scaling trend, and 3D IC is that "more" right now.

We are seeing a lot of traction at some of our key customers who are now taping out real production chips. 3D IC technology has its share of open challenges, like any other disruptive technology in its early stages, but the performance and power benefits are so huge that it is certainly serving as a differentiating strategy for the few who have dared to walk that path.

So unarguably the race is on.

Are you in it yet? Let me know; let's talk about it. Please let us know if you would like to see the technology in action.

Samta Bansal

Recent Cadence Community blogs on 3D ICs:

Samta Bansal: My DATE With 3DIC Technology

Rahul Deokar: EDP Symposium Discovers an Inconvenient Truth with a Shot of 3D

Richard Goering: EDA Workshop: A Reality Check on 3D ICs

Rahul Deokar: DAC 2010 - A "Coming Out" Party for 3D-IC Design

Richard Goering: 3D-IC TSV Update: No Technology Roadblocks, But Cost Management is Needed

Recent Webinar on 3D IC Topics:

Should You Design Your Next System With 3D TSVs? Hear from GLOBALFOUNDRIES and Cadence

Guest Blog: Using dbTransform to Translate Geometric Coordinates in Encounter

BobD — Tue, 28 Sep 2010 13:00:00 GMT

This is a guest post from JasonG at Avago. I hope you enjoy this useful piece he's contributed on using the relative-new dbTransform Encounter command. If you'd like to write a guest post we'd love to have it. Please drop me an E-mail if you're interested in contributing: dwyer@cadence.com -Bob Dwyer

Hello fellow digital implementation Tcl developers! Bob asked if I'd be interested in contributing to a "guest blog" on a subject of my choosing.

First, a quick background about me. I am a senior design engineer for Avago Technologies where I do a lot of floorplanning and floorplan-related script development. You may have seen me a couple years ago at CDNLive! 2008 where I gave a presentation on all the extensions I've written for SoC Encounter during my career. When Bob asked if I was interested in guest blogging, I thought what better topic than a db-command that I'm anxious to integrate into my Tcl scripts.

Some commands that always pop up high on my list of time-consuming procedures are my Tcl-implemented transformation commands. Often times my higher-level scripts require that I transform back and forth between "cell" coordinates and "instance" coordinates. For instance, say you are adding a routing blockage to a partition clone and you want to ensure it also gets added to the master in the corresponding location. One could transform the clone instance's coordinate to the clone's cell reference coordinate and then transform it from the cell reference to the master. Easy, right? Well, when you think about all the orientations that a clone could have, the computations can be pretty time consuming. Thankfully, the Cadence Encounter Digital Implementation system platform provides a partial solution to this problem; dbTransform.

The usage, as of EDI9.1USR1:

Usage: dbTransform [-help] [-d] -localPt <list> {-inst <instPtr> | {-cell <cellPtr> -orient <orientEnum> -pt {x y}}}

-help               # Prints out the command usage
-d                  # Specifies if points are in dbUnit: default is um
                    # (bool, optional)
-inst <instPtr>     # instance object (db object, required)
-cell <cellPtr>     # cell object (db object, optional)
-orient {R0|R90|R180|R270|MX|MX90|MY|MY90|dbcR0|dbcR90|dbcR180|dbcR270|dbcMX|dbcMX90|dbcMY|dbcMY90}
                  # orientation (enum, optional)
-pt {x y}           # location (point, optional)
-localPt <list>     # a pt {x y}, rect {xl yl xu yu} or list of pts and/or
                    # rects {{x1 y1} {x2 y2} {xl yl xu yu} ...} inside cell
                    # (string, required)

Here is an example that shows how one would go about finding the shapes for a specific pin on a leaf cell.

### Find the metal shapes associated with the "CK" pin of a cell.
set instPtr [dbGetInstByName i_a/i2]
set termPtr [dbGetTermByName $instPtr CK]

### The pin shapes are stored on the "cell fterm" reference.
dbForEachFTermLefPort [dbTermFTerm $termPtr] lefPortPtr {
dbForEachLefPortLayerShape $lefPortPtr lShapePtr {
    set lsLyr [dbLayerWireId [dbLayerShapeLayer $lShapePtr]]
    dbForEachLayerShapeShape $lShapePtr lShapeSPtr {
      set lsBox [dbShapeRect $lShapeSPtr]
      ### Use 'dbTransform' to take this "local point" and translate into
      ### the instance's placement.
      set pinShape [join [dbTransform -d -localPt $lsBox -inst $instPtr]]
      ### Fix the shape to be a legal "rect" (i.e. urx>llx and ury>lly).
      foreach {llx lly urx ury} $pinShape {
        if {$llx > $urx} { set tmp $llx; set llx $urx; set urx $tmp; }
        if {$lly > $ury} { set tmp $lly; set lly $ury; set ury $tmp; }
        break
      }
      set pinShape [list $llx $lly $urx $ury]
      Puts "Pin on layer $lsLyr has rectangle \{$pinShape\}"
    }
}
}

### The resulting coordinates, in DBU, are:
Pin on layer 1 has rectangle {2077950 5172740 2078370 5172920}
Pin on layer 1 has rectangle {2077950 5172270 2078090 5172740}
Pin on layer 1 has rectangle {2078230 5172920 2078370 5173170}

The picture below shows, in solid blue lines, the resulting shapes. As you can see, they exactly correspond with the pin shapes for the "CK" pin on this instance. Note that this instance just happened to be placed in the MY orient and, thus, the ury and lly were swapped.

Unfortunately, as dbTransform is currently implemented, there is no way to transform the other way. In other words, you cannot transform coordinates that are in terms of an instance to a cell. However, I hear this will be available in the next version and I cannot wait to test it out. Also, dbTransform only supports objects of type 'dbcObjInst' and 'dbcObjBump'. For my scripting needs, I also need support for 'dbcObjHInst'. Hopefully this, too, will be available soon.

Well, that's it for me. I hope you enjoyed this little tutorial. I hope to give more in the future (I have a couple ideas for future posts but they'll have to wait for the offical EDI10.1 release). I'll be giving a presentation on the new EDI GUI API available in EDI9.1 at this year's CDNLive! Silicon Valley conference Oct. 28. If you are in attendance, please drop by and say 'Hi'.

JasonG

Encounter Puzzler #2 Solution: Finding Registers Beneath a Hierarchy

BobD — Fri, 24 Sep 2010 13:00:00 GMT

Thanks to everyone who participated in this week's Encounter Puzzer. If you didn't catch it earlier, have a look now before reading the solution discussion below.

I thought this puzzler was great because it's such a small and simple example, yet it leads to so many useful fundamental components of database access. The first two comments were especially appreciated because it pointed out two of the primary ways to access data in Encounter: with dbGet and with Advanced Timing TCL commands (let's call them CTE-TCL commands for "Common Timing Engine-Tool Command Language" shall we?).

Coincidentally, I had a chance to visit was the original requestor of this challenge just yesterday. I sent him the solution via E-mail and it wasn't working! More on why in the discussion below...

@Edwin suggests a solution that was very nearly what I proposed to the customer:

deselectAll
foreach inst [dbGet -p2 [dbGetHInstByName i_a].allTreeInsts.cell.name DFF*] {
dbSelectObj $inst
}

What I like about this solution is that it discovers the instances beneath the hierarchical instance i_a programatically rather than relying on instance name. The \i_a/i0 instance I added at the top-level of the design is a bit contrived, but it does point out a risk in assuming hierarchy from instance name. In the spirit of writing generic code that can work across a number of designs it is good practice to find the instances that are explicity stored beneath the hierarchical instance and using dbGet to traverse from hierarchical instance to "allTreeInsts" is a great way to do that. But it raises a complication...

Another point to mention in this example is keying off a cell name of "DFF*". If the timing libraries are loaded, the script could key off the ".isSequential" cell marking as follows:

foreach inst [dbGet -p2 [dbGetHInstByName i_a].allTreeInsts.cell.isSequential 1] {
dbSelectObj $inst
}

Remember how I said the script I sent the customer wasn't working? It turns out timing libraries weren't loaded so the isSequential marking was populated. Turns out selecting by a sequential cell master name like Edwin suggested was a better approach for the situation.

Another point to mention is that as of 9.1.USR1 dbSelectObj works on a list so the code could be compacted further into:

dbSelectObj [dbGet -p2 [dbGetHInstByName i_a].allTreeInsts.cell.isSequential 1]

Further reading on selecting objects by pointer with dbGet in this blog entry.

By the way, it's worth mentioning that a Google search for "dbSelectObj cadence encounter" would retrieve this blog entry as would a search on support.cadence.com for "dbSelectObj".

One other thing to mention relative to the dbGet solution. When I run the suggested code I get the following message:

**WARN: (ENCDBTCL-204): 'cell' is not a recognized object/attribute for object type 'hInst'. For help use 'dbGet <object>.?h' to get list of all supported (settable/unsettable) objects and attributes.

What's happening there? Well, the warning can be ignored but .allTreeInsts returns what we call a "heterogeneous" list which includes all of the instances -and- hierarchical instances beneath i_a. This list includes the hierarchical instance i_a/i_a_sub and when we try to traverse from i_a/i_a_sub to its "cell" we get the warning message because "cell" is not a valid object for hierarchical instances. We could filter out the objects that aren't instances with the following addition in bold:

dbSelectObj [dbGet -p2 [dbGet -p [dbGetHInstByName i_a].allTreeInsts.objType inst].cell.isSequential 1]

Note: We're considering exposing heterogeneous and non-heterogeneous lists in a number of areas to make this simpler in a future release.

@Vishnu used CTE-TCL:

set x [get_cells -hier -filter "hierarchical_name =~ i_a/* && is_sequential == true"]
foreach_in_collection y $x {
selectInst [get_object_name $y]
}

There's a lot of extremely useful functionality demonstrated in this example. The complex filtering capabilities of get_cells, keying off the "is_sequential" attribute, using foreach_in_collection to iterate through the objects... Great stuff. One tiny tiny nuance that was problematic with the example was filtering out the top-level \i_a/i0 instance.

By default, Encounter hides leading backslashes from instance names, so the instance that's called \i_a/i0 in the Verilog netlist is identified within Encounter as simply "i_a/i0". Consequently, the script would still catch that instance undesireably as being beneath i_a. We can overcome this however with a call to:

encounter 1> set dbgIsBackslashInNamesHidden 0

Once this variable is set, the leading backslash is no longer hidden and the code would work as desired: \i_a/i0 would be filtered out because it contains a leading backslash and therefore doesn't match the "i_a/*" filter expression. Normally, variables like this are visible from Options->Set Global Variable... However, this one isn't public yet. I'm working with our developers on that now. Kind of a wacky side-issue but I hope it illustrates some risks associated with keying off names vs. keying off the hierarchical structure directly.

Laurent proposed an interesting area-based solution. I hadn't thought of that myself but it could certainly be useful in this and other scenarios when seeking to find objects by type in a specific area of the design:

set area [list 600 600 1200 1200]
foreach i [dbGet [dbQueryInstInBox \
[dbMicronsToDBU [dbBoxLLX $area]] \
[dbMicronsToDBU [dbBoxLLY $area]] \
[dbMicronsToDBU [dbBoxURX $area]] \
[dbMicronsToDBU [dbBoxURY $area]]].cell.isSequential 1 -p2] {
dbSelectObj $i
}

An even easier way to go about this is with the dbQuery command. I haven't talked about it yet since it's not fully documented until 9.1.USR3 but check back in a month or so for an update on that. It can be really powerful and simple to use.

Another way to solve this puzzler is by using what JasonG referred to as "old school" commands. Here we're talking about commands like "dbForEachCellInst" and old school is actually a good characterization of them since they've been around since Encounter's inception. I sometimes refer to these as "FE-TCL" commands. They're sometimes criticized as being cryptical and confusing, but they can often be fast and powerful:

proc selectHierRegisters {hinstName} {
dbForEachCellVInst [dbHInstCell $hinstName] viPtr {
    if {[dbIsCellHier [dbVInstCell $viPtr]]} {
      selectHierRegisters $hinstName/[dbVInstName $viPtr]
    } elseif {[dbIsCellSequential [dbVInstCell $viPtr]]} {
      selectInst $hinstName/[dbVInstName $viPtr]
    }
}
}

Ideally, we can do everything you can do with FE-TCL with dbGet but there are some cases where I find it more comfortable to fall back on FE-TCL commands. This just might be one of those cases. Here's why...

FE-TCL provides one very useful command for this scenario: dbForEachHInstTreeInst. It's an object-type specific iterator that goes through each instance beneath a given hierarchical instance. Perfect! There's also a "dbForEachHInstTreeHinst" command that iterates throughall of the hierarchical instances beneath a hierarchical instance. Here's an example:

proc userSelectHierRegisters {hinstName} {
dbForEachHInstTreeInst [dbGetHInstByName $hinstName] inst {
    if {[dbIsCellSequential [dbInstCell $inst]]} {
      dbSelectObj $inst
    }
}
}

An interesting side-note: We've been discussing the idea of splitting out more homogeneous lists in dbGet to make code more compact. In this case, that would mean a list of just the instances beneath the hierarchical instance. Stay tuned for more on that in a future release.

As you can see there's more than one way to solve this solution for sure. I'm pleased we covered it from so many angles -- the general techniques described here can be applied to other scripting tasks in the tool. Thanks again for the participation and discussion. If you have any thoughts you'd like to add we'd love to hear from you. Check back soon for more puzzlers and updates. You'd be my Best Friend Forever if you subscribed to E-mail updates to our Digital Implementation blogs. Never more than one E-mail a day and hopefully useful and interesting content.

Bob Dwyer

Five-Minute Tutorial: Creating a NONDEFAULT Rule

Kari — Wed, 22 Sep 2010 18:00:00 GMT

Ah, the NONDEFAULT rule. This is a routing rule that is, well, not the default! It usually consists of double-wide or triple-wide metal, and at least double-wide spacing, but it can be whatever you like as long as it follows DRC rules (no violating the min or max metal widths, for example). NONDEFAULT rules are typically used to route clock nets or other sensitive nets. If you are very lucky, your tech LEF came with some NONDEFAULT rules already defined. But this is not usually the case. Those of us who have been around a while always dreaded the creation of NONDEFAULT rules -- it's not difficult, but it is tedious to write out a large tech LEF section by hand.

Well, for some time now, EDI has had the ability to create NONDEFAULT rules for us! It's easy and fast. Here's how to do it:

In the EDI 9.1 Menu, go to Edit -> Create Non Default Rule. You'll see the following form:

Name your NONDEFAULT rule something descriptive, and then choose an existing rule to start from. In most cases, all you'll have so far is the Default rule. That's a great starting point. With the default rule width and spacing numbers right in front of you, it's easy to enter values that are twice or three times as large for a double- or triple-wide rule.

Now, the vias: the vias from the default rule (or whatever rule you chose as your starting point) will be listed. In most cases, it's fine to just use the default rule vias.

Finally, decide if you want the NONDEFAULT rule to follow Hard Spacing. This means that violations of the NONDEFAULT rule spacing are considered and flagged as true violations. Without Hard Spacing turned on, the NONDEFAULT spacing is followed as much as possible, but if it needs to be broken to complete the route or follow other routing/spacing rules, then it's not considered a violation.

When you click OK or Apply, the rule is created and exists in your design database. But here is the crucial part: we want to add this NONDEFAULT rule to our tech LEF. Let's say we named our NONDEFAULT rule "DblWide" and we'll output it to a temporary file called tmp.lef. At the EDI prompt, type:

exportNdr DblWide -lef tmp.lef

Now, you can cut and paste the NONDEFAULT portion of tmp.lef into your tech LEF. (The section you need starts with "NONDEFAULTRULE DblWide" and ends with "END DblWide" in this example.)

Much easier than typing the whole thing in by hand!

Would you like to be notified when the next Five-Minute Tutorial comes out? Subscribe to the Digital Implementation blog!

Encounter Puzzler #2: Finding Registers Beneath a Hierarchy

BobD — Mon, 20 Sep 2010 13:00:00 GMT

I hope you enjoyed our first Encounter Puzzler: Where Did My Fences Go? The source of inspiration for this week's puzzler came from an internal alias that we have here at Cadence where folks ask and answer questions about Encounter. An applications engineer received a request from a customer and wanted to know: How can I select all of the registers beneath a given logical hierarchy?

The image above shows the scenario. To clarify exactly what we're talking about, here's a sample Verilog netlist:

module testcase();
DFFX1 \i_a/i0 ();
BUFX1 i1();
a i_a();
b i_b();
endmodule

module a();
a_sub i_a_sub();
DFFX1 i2();
BUFX1 i3();
endmodule

module a_sub();
DFFX1 i0();
BUFX1 i1();
endmodule

module b();
DFFX1 i0();
BUFX1 i1();
endmodule

Given this netlist, we'd like to select all of the registers beneath the hierarchical instance i_a. In this case, the script should therefore select i_a/i2 and i_a/i_a_sub/i0.

Tips:

The first thing that comes to mind is using dbGet, but there are a number of ways this could be done including Advanced Timing TCL Scripting Commands.
In this context "registers" are just another word for sequential elements. They're marked as such in the .lib and can be keyed off in the db.
Consider using dbSelectObj -or- selectInst to select the instances.
Beware of the \i_a/i0 instance at the top level of the design -- it is not beneath the hierarchical instance i_a. I threw that in there to keep things interesting.

This is a little more open-ended than our last puzzler. Leave a comment below with your solution -- I'll look forward to seeing what you come up with. I'll post some solutions and further discussion this coming Friday.

Check back on Friday for the answer. Or better yet subscribe to the Digital Implementation blogs to get new content delivered to your inbox or favorite feed reader.

Bob Dwyer

Five-Minute Tutorial: Encounter Command Line Help

Kari — Wed, 15 Sep 2010 17:00:00 GMT

Hi everyone, and welcome to the first Five-Minute Tutorial! I have several things planned for this series. Today we're going to look at getting help on the command line in the Encounter Digital Implementation (EDI) system.

Sometimes in the middle of an EDI session, you want to run a command but you can't remember the exact name, or the exact options. Sometimes you don't even know if a command exists to do what you want, but you'd like to find out if it does. Obviously, you can always look at the EDI System Text Command Reference. (And I recommend doing so to learn all about the various EDI commands. This is a manual that I use every single day!) But sometimes you just want a quick reference at your fingertips. This is available in the form of command-line help.

Let's say you want to report the transition violations in your design. You know there's a command to do that, but you don't recall if it's report_tran_violation, reportTranViolation, or something else similar. At the EDI command prompt, you can type:

encounter 31> help report_t*
Multiple commands found:
      report_timing
      report_timing_derate
      report_timing_format

encounter 32> help reportT*
Multiple commands found:
      reportTimingDerate
      reportTimingLib
      reportTranViolation

Ah, there it is! But what are the options for this command? Now that we know the exact command name, we can do this:

encounter 33> help reportTranViolation
Usage: reportTranViolation
    reportTranViolation
    [-all | -noGlobalNets]
    [-selNetFile <selNetFileName>]
    [-excNetFile <excNetFileName>]
    [-useDrcMargin]
    -outfile
    <fileName>

Great! If we want more detailed info, we can then go to the Text Command Reference, but there is yet another form of help we can get right from the command line.

HOMEWORK: See what happens when you type "man reportTranViolation".

Something to be aware of: In Encounter versions 8.1 and earlier, the wildcard character * in the examples above was not required.

Another way to find command names is by using the tab key:

encounter 36> legalize <press the tab key>
legalizeFPlan legalizePin

You could also just type the partial command name and get a message which lists the possibilities:

encounter 38> legalize
ambiguous command name "legalize": legalizeFPlan legalizePin

BE CAREFUL with this one though - if what you enter is an actual command name, you will inadvertently run that command!

I hope you've found this five-minute tutorial useful.

Want to make sure you don't miss the next Five-Minute Tutorial? Subscribe to the Digital Implementation blog!

Encounter 101: Implementing ECOs with ecoDesign

BobD — Tue, 14 Sep 2010 17:00:00 GMT

When people say "ECO" in the context of back-end digital implementation tools, they can mean a number of things:

TCL commands that trigger netlist changes to the design
Functionality that takes RTL-based changes and automatically implements them automatically and surgically
Functionality that takes a new Verilog netlist and implements the changes to an existing database
Pre-mask or Post-mask (i.e., can the base layers in the design be altered?)
Selective metal layer (i.e., which metal layers are allowed to be altered?)

I consider these all part of a similar family of functionality. They're pointed at surgically altering the existing database for whatever reason and implementing just a small change in the design while leaving everything else undisturbed. This can be hugely beneficial for accomodating late-breaking changes to the design specification or repairing bugs in the RTL.

In Encounter, "ecoDesign" is the super-command targeted at implementing ECOs. The input is an existing Encounter database along with a new Verilog netlist that describes the desired logical netlist. Here's a simple example of an ECO that Encounter could be tasked with implementing and how you'd instruct the tool to do so:

Here's how we'd do it:

Save the existing database with "saveDesign <designName>.enc.dat"
In a new Encounter session, call ecoDesign pointing to the new netlist along with the old Encounter database:
Syntax: ecoDesign <sessionDirectory> <designName> <newNetlistFile>
"ecoDesign testcase.enc.dat testcase eco.v"

This will instruct the tool to load the new netlist while refering to the old physical database. It will then compare the new netlist to the old and retain as much physical information as possible while preparing the database for incremental routing. Finally, it will implement surgical changes to the routing to finalize the ECO. Conceptually, this is why it is advantageous to perform an ECO as opposed to completely respinning. It's all about minimizing turnaround time and reducing the uncertainty associated with changing the entire design.

Here's what the database would look like after ecoDesign. Note how the connection is changed, but the old unaffected routing isn't touched:

I'll be writing about other nuances related to ECO in future blog entries so I wanted to share this as a foundation for further discussion. Developing an ECO strategy is something I've seen successful design teams do while implementing their first chip -- not only because they want to make their designs amendable to future re-spins but because they want to speed their first release to market by spinning late breaking changes effectively.

Further Reading: The ECO Flows Chapter in the Encounter User's Guide is actually pretty good. It covers a wide variety of ECO types and gives detailed step-by-step insight into the steps ecoDesign performs to implement an ECO.

Have you used Encounter's ECO capabilities? We'd love to hear about your experiences.

Bob Dwyer

Encounter Puzzler Solution: Where Did My Fences Go?

BobD — Fri, 10 Sep 2010 21:30:00 GMT

A couple of days ago I posted a puzzler on a scenario where fences couldn't be seen in Encounter. Check it out HERE.

Congratulations to Jason G for absolutely nailing it in the comments. He was indeed corrrect -- the issue was that the fences didn't contain any standard cells within them, so the tool wasn't displaying them. That's because the default setting stiplulates that module guides with less than 100 instances within them aren't displayed. This setting is controlled via the GUI under Options->Set Preference...->Display:

(Note: In 8.1 and earlier this form was accessed via Design->Preferences...)

This has been a long-standing default in the tool and it's usually a sensible one. If you think back to Encounter's legacy of being a high capacity floorplanning system with a unique virtual-flat view, it makes sense to think that modules will usually have standard cells beneath them and if there are less than 100 instances within a given module, it's usually not a large enough entity to consider as a partition. That being the case, the default is set to 100 in order to avoid the GUI from being cluttered up.

However, it's quite common for users to perform early floorplanning where there is no standard cell content to the modules. In cases like this, the tool can treat empty modules as black boxes, or as empty modules as was the case in the puzzler. That being the case, I'd be in favor of changing the default to 0 (i.e., all modules should be displayed regardless of how many standard cells are within them). What do you think? Let us know in the comments or by dropping me an E-mail: dwyer@cadence.com

Setting that aside, why was it that one user was able to see the fences yet another wasn't? It was because one user had long ago set this preference and saved it in his home directory in an .enc file. If you'd like to save preferences for future sessions you can do so by clicking "Save" on the Preferences form and then choosing where you'd like to save the file. Next time you start the tool, it will pick up the preferences automatically:

For more information about EDI initialization files and the order in which they are sourced see this section of the EDI User's Guide.

So why doesn't the tool save the preferences when a design is saved? Well, it does, but depending on whether the design is restored or loaded from scratch, the preferences won't get restored. If one did a "saveDesign testcase.enc" that would result in a testcase.enc.dat directory. That testcase.enc.dat directory would contain the preferences saved in an enc.pref.tcl file. If that session was restored via Design->Restore Design... (or "source testcase.enc" which is equivalent to Design->RestoreDesign and the TCL command "restoreDesign") then the preferences associated with the database would be restored along with the design. But if the design is restored by loading a configuration file and floorplan file, then the preferences file doesn't get sourced.

In all, the moral of the story is that there is more information stored as a result of saveDesign than what is stored in the .conf file. You might consider passing around .enc.dat directories rather than .conf files when sharing data between users.

Further Reading: If you want to create a self-contained testcase this blog entry might be useful. It describes how to create a testcase that also contains all of the supporting library data which can be useful when passing databases to other sites that don't have visibility to the same file system. It's also very useful for passing testcases to Cadence applications engineers to troubleshoot issues. This is why "saveTestcase" is one of my favorite commands.

I hope this format is fun and useful. I'll post another puzzler soon.

Bob Dwyer

Encounter Puzzler: Where Did My Fences Go?

BobD — Wed, 08 Sep 2010 16:00:00 GMT

A while back I visited a customer I see on a fairly regular basis. As soon as I entered the building, my primary contact asked if I'd stop off to talk with a colleague of his who had an Encounter problem. It was a bad one -- he was dead in the water and he couldn't get past the issue.

It's fairly unusual to look at a problem as an application engineer, and make quick suggestions that resolve problems. Especially lately, it seems. Invariably, the problems I see are complicated multi-variable things that take a lot of time and effort to pinpoint. But this one was different. It took me less than a minute to diagnose this problem and resolve it with the user. This scenario got me thinking that sharing these little tidbits would be an interesting addition to the blog. Challenges like this become a "puzzle" of sorts; I share some symptoms and clues, and you can take a crack at it and learn a little bit about how Encounter works along the way.

So here's the first puzzler:

The designer I visited was attempting to perform floorplanning operations in the tool. He inherited a database from another designer and needed to refine the solution to derive better fence locations and sizes. However, there was one big problem -- he couldn't see any fences in the design! Here is what the designer saw when he looked at the floorplan in Encounter:

The following is what he expected to see (5 fences):

The strange thing was that when the original designer was working on the database he could see the fences. We checked to make sure Guides/Regions/Fences/Modules were all visible and selected -- they were. We found one simple setting that, when changed, made the fences visible.

Do you think you know what's going on here? And why could one designer see the fences while the other could not? If you have an idea, leave a comment below.

Check back on Friday for the answer. Or better yet subscribe to the Digital Implementation blogs to get new content delivered to your inbox or favorite feed reader.

Bob Dwyer

CDNLive! Silicon Valley Abstract Deadline Extended 1 Week

BobD — Wed, 25 Aug 2010 16:00:00 GMT

The deadline for submitting abstracts to CDNLive! Silicion Valley 2010 has been extended 1 week to Sunday August 29th. The conference begins October 26th at the Fairmont Hotel in San Jose, California.

If you've already submitted an abstract: Thank you!

If you haven't yet, I'd highly recommend you take a moment to consider taking part in this year's conference. I think the most common reason people don't submit abstracts and papers for conferences like this is they feel like they didn't do anything spectacular enough to warrant writing a paper in the past year. Don't underestimate how useful the knowledge you've built up would be to other users. Some of the best papers cover nuances associated with just a single option of a single command. Or general areas you've been working with over a period of time. The most important thing to consider, I think, is how you used Cadence tools to solve a real-world challenge.

Click here to visit the CDNLive! Silicon Valley abstract submission page.

Thanks for your consideration. We look forward to your submission and participation in the conference.

Bob Dwyer

Webinar: SOI Gives More Performance Per Watt, And There's An Easy Path

mikeNaustin — Fri, 20 Aug 2010 23:00:00 GMT

If you've seen any of the recent buzz lately around Silicon-On-Insulator (SOI), you'd know that it's an excellent option that can enable you to meet lower power consumption and die area targets without sacrificing performance or functionality. This is why Cadence, ARM and IBM have partnered to provide you an easy path to silicon with the SOI process for your digital design, including production proven software, design kits and IP.

If you're a design manager or engineer, and you'd like to learn more about designing with SOI, please join Cadence and ARM on Wednesday August 25^th for the "Ready for SOI" webinar. Here's more info:

When:

August 25, 2010 @ 10:00 am pacific time

What & Where:

Attend this webinar to find out what SOI technology can do for you and how you can maximize its benefits. You'll learn how to implement and verify your digital and mixed signal SOI IP and SoCs, and you'll hear about how Cadence and its ecosystem partners are collaborating to offer an end-to-end SOI solution and methodology.

This webinar is part of a Digital Implementation and Signoff series of webinars that begins August 24.

Michael Jacobs

Abstracts For CDNLive! Silicon Valley 2010 Due August 22

BobD — Mon, 09 Aug 2010 20:00:00 GMT

Don't let the name CDNLive! confuse you. It's the Cadence user's group conference and for North America this year it's occurring in Silicon Valley October 26th, 2010. The conference also includes Technology Demos and a Designer Expo, but the heart of the event is really the user presentations. If you haven't submitted a paper for consideration or haven't even thought of a topic to talk about, don't worry -- it's not too late.

The deadline for abstracts is August 22nd, 2010. Abstracts are a maximum of 1,500 words so you don't have to invest a lot of time and energy to see if your topic will be accepted. I highly recommend you consider submitting an abstract. Here's why...

I've presented papers at this conference twice in the past and it's been a rewarding experience each time. The first was back in 2000 when the conference was called the International Cadence Usergroup Conference. I was working at IBM at the time and my colleague Adam Jatkowski and I presented "X-Terminator: A hierarchical pin placement optimizer." We wrote up an algorithm in SKILL that did some very cool things in the pin assignment domain. Adam was brains of the operation and I "sold" it to our project manager. That project was where I developed my interest for EDA scripting languages that continues today. We were just a couple years out of college and had a great time writing the code, presenting the paper, and sneaking in a trip up to Napa at some point during the week. I remember a Cadence representative asking about the run-time of our solution after we finished our talk. Adam advised that "it was on the order of n-squared." Good thing he was there -- I would've said it was "pretty fast."

The next paper was jointly authored with Franklin Bodine from Intel in 2008. We wrote up "Avoiding Unhappy Block Designers with Incremental Feedthrough Insertion." Franklin couldn't join me to present, but it was rewarding to talk about the content we worked together developing to audience members who had familiarity working with the exact set of specific commands we leveraged. Who knew "insertPtnFeedthrough -topoFile" could be the subject of a paper?

2008 was also the year I caught this video of our Encounter software running through VNC on an iPhone. I also had a nice meal at The Grill inside the Fairmont Hotel (where the conference is being held this year). Highly recommended if you can find a way to fit it on the expense report. If you're having difficulty there's always ExpenseASteak.com to help out.

For me the best part of the conference is connecting with other users working in the same functional areas and establishing lasting relationships. For example I met Jason Gentry at the conference. His paper on "Extending SoC-Encounter using Built-In db Commands" was right up my alley. Others enjoyed it too -- it earned the People's Choice Award for Best Paper.

I hope you consider taking the time to submit an abstract and create your own memories at a CDNLive! And I hope to see you there.

Click here to visit the CDNLive! Silicon Valley 2010 website.

Bob Dwyer

EDA Follow-The-Leader ... Signoff In The Design Flow

PeteMc — Mon, 09 Aug 2010 13:00:00 GMT

As a member of the EDA community, I find it interesting and somewhat frustrating to see how much we copy each other at times. Ever notice how one company might make a position on something, and once their message resonates, then a lot of other companies come out of the woodwork with me-too messaging and positioning?

I saw this happen on mixed-signal design, and now see it happening on signoff analysis.

Here at Cadence, we have developed a very comprehensive suite of signoff analysis solutions, and have been advocating that these solutions help design teams more when solutions are integrated into the design environment. Instead of transferring gigabytes of design data to separate tools, it makes obvious sense to enable the analysis directly from the design environments themsleves. This helps design engineers more efficiently execute the multiple types of analysis and enables an easy path to fixing any identified problems -- but it does require signoff levels of accuracy.

Today, signoff solutions at Cadence include functionality used to validate timing, signal integrity, distributed power dissipation, power rail IR drop and electromigration, parasitic extraction, DRC, LVS, noise and on-chip thermal analysis. All of this functionality is now accessible directly from the Encounter Digital Implementation System digital design platform, and most of this functionality is also accessible directly from our Virtuoso custom design platform too. The end result is that we have enabled our customers with high increases in ease-of-use and efficiency in completing their designs.

I find it a little amusing that some of my competition use phrases such as "in-design signoff" when they are often referring to limited functionality such as DRC and LVS. While it is great that they have copied the Cadence positioning, the reality is that true integrated signoff covers a lot more functionality.

If you want to learn more on how Cadence has enabled comprehensive in-design signoff, watch out for some techtorials that will be announced in the coming weeks, where will will educate you in detail on our solutions and the value of the integration.

Pete McCrorie

Programatically Capturing Cell Delay In The Encounter Digital Implementation System

BobD — Fri, 23 Jul 2010 16:00:00 GMT

A while back we were talking about how to programatically troubleshoot timing violations in Encounter. That post recieved a lot of good comments (thanks!) but one in particular touched on a point that I've worked on with other users, so I thought to raise it up for visibility here and go more in depth on the topic. Nataraja G asks:

"how can we get the delay values associated with that cell ? is it possible!"

When I first looked at our CTE-TCL inferface for probing timing programmatically I too thought it would be convenient to capture the delay through a given cell. Then it would be easy to capture all the instances in a given path with delay greater than a given value, for example. However, it's a little more complicated than that in practice. It is possible, however, and choosing the best method depends on what exactly you're looking to achieve.

Let's get right into an example of an actual timing path to see how we might be able to extract information about cell delay programmatically.

In this blog entry I'll be seeking to capture the delay through i0 in this simple reg2reg path that goes through a single buffer:

     +-------------------------------------------------------------+ 
     | Instance |     Arc     |  Cell | Delay | Arrival | Required |
     |          |             |       |       |  Time   |   Time   |
     |----------+-------------+-------+-------+---------+----------|
     | i0       | CK ^        |       |       |   0.000 |    0.309 |
     | i0       | CK ^ -> Q v | DFFX1 | 0.286 |   0.286 |    0.595 | 
     | i1       | A v -> Y v  | BUFX1 | 0.156 |   0.442 |    0.751 | 
     | i2       | D v         | DFFX1 | 0.000 |   0.442 |    0.751 | 
     +-------------------------------------------------------------+

Reporting timing through a given instance

Before going too much further, it's probably worth mentioning the "reportDelayCalculation" command. It's helpful for asking the tool to write out information about how delay was calculated for a given instance. Here's an abridged example of what it writes out if we call it:

encounter 1> reportDelayCalculation -from i0/CK -to i0/Q
-------------------------------------------------------------
                           Rise        Fall
-------------------------------------------------------------
Input transition time  : 0.120000 ns 0.120000 ns 
Effective capacitance  : 0.003261 pF 0.003261 pF
Cell delay             : 0.377800 ns 0.286200 ns 
Output transition time : 0.093300 ns 0.079400 ns 
-------------------------------------------------------------

This is perhaps useful information, but what if we want to do something more programmatic?

Programatically capturing the delay for a portion of a path

The "get_arcs" command can be useful in situations where you want to capture the delay from any point to any point. In this case

encounter 38> get_arcs -from i0/CK -to i0/Q
0x36

The 0x36 tells us we've caught a "collection" that we can in turn query for more information. The "report_property" command can be used to list what information we can query for the collection:

encounter 40> report_property [get_arcs -from i0/CK -to i0/Q]   
property                            | value    
-------------------------------------------------
arc_type                            | rising_edge
delta_delay_max_fall                |  
delta_delay_max_rise                |  
delta_delay_min_fall                |  
delta_delay_min_rise                |  
delay_max_fall                      | 0.286
delay_max_rise                      | 0.378
delay_min_fall                      | 0.286
delay_min_rise                      | 0.378
is_cellarc                          | true
is_disabled                         | false
mode                                |  
object_type                         | timing_arc
sdf_cond                            |  
sdf_cond_end                        |  
sdf_cond_start                      |  
sense                               | non_unate
source_pin                          | {...} 
sink_pin                            | {...} 
when                                |

Note that there are rise and fall arcs that go through the instance. The 0.286 in the timing report happens to be associated with delay_max_fall. If we wanted, we could capture one of the values explicitly with "get_property":

encounter 42> get_property [get_arcs -from i0/CK -to i0/Q] delay_max_fall  
0.286

Programatically capturing the delay for a given instance

With get_arcs, we needed to select from the rising and falling arcs. If we want to capture the arc that appears in a given timing report for a specific instance, we can capture a timing collection and query its timing_points. The timing_points are sorted such that we can perform a subtraction of arrival time to determine the delay through any instance. Here's a proc that finds the delay through a given instance name in a timing collection:

proc user_get_inst_delay {inst_name timing_collection} {
  set timing_points [get_property $timing_collection timing_points]
  set previous_arrival_time 0
  foreach_in_collection timing_point $timing_points {
    set pin [get_property $timing_point pin]
    set pin_name [get_property $pin hierarchical_name]
    set inst [file dirname $pin_name]
    set arrival [get_property $timing_point arrival]
    if {[string match $inst_name $inst]} {
      set cell_delay [expr $arrival - $previous_arrival_time]
    }
    set previous_arrival_time $arrival
  }
  puts "Delay for inst $inst_name is $cell_delay"
}

Then we could query the delay through a given instance in the path as follows (switching up to i1 here just to show a different value than the next example):

encounter 63> user_get_inst_delay i1 [report_timing -collection]
Delay for inst i1 is 0.156

Programatically capturing instances with delay greater than a certain amount

We could also write the script such that we find the instances with delay greater than a certain amount and potentially do something with those instances like upsize them. Here's an example of how the script could be reworked to do that:

proc user_get_inst_delay_greater_than {max_delay timing_collection} {
  set timing_points [get_property $timing_collection timing_points]
  set previous_arrival_time 0
  foreach_in_collection timing_point $timing_points {
    set pin [get_property $timing_point pin]
    set pin_name [get_property $pin hierarchical_name]
    set inst [file dirname $pin_name]
    set arrival [get_property $timing_point arrival]
    set cell_delay [expr $arrival - $previous_arrival_time]
    if {[expr $cell_delay > $max_delay]} {
      puts "Delay for inst $inst is $cell_delay"
    }
    set previous_arrival_time $arrival
  }
}

encounter 62> user_get_inst_delay_greater_than 0.2 [report_timing -collection]
Delay for inst i0 is 0.286

Conclusion

Having the ability to programatically query timing in the physical domain can be a powerful tool. If you're not that into scripting but you still want to troubleshoot timing you might find our Global Timing Debug utility useful. It provides a menu-driven way to capture categories of paths with certain characteristics. For example you could create a category that had all of the paths in the design with more than "n" instances with delay greater than "y".

For more information on programming and timing analysis in Encounter check out the Advanced Timing Tcl Scripting Commands chapter of the Encounter Digital Implementation System Text Command Reference.

Question of the Day: Any tips or tricks related to this you'd like to share? Any suggestions for improvement?

Robert Dwyer

DAC 2010 – A “Coming Out” Party For 3D-IC Design

RahulD — Mon, 28 Jun 2010 22:51:00 GMT

Overall, the 2010 Anaheim DAC was livelier than the years before. Customer and vendor faces were not long and serious, but more purposeful and forward-looking. The recent M&A activity also brought in some rays of sunshine. The EDA360 vision for the entire industry resonated with a wide gamut of system companies, IDM's, ASIC/IP vendors and foundries. And, the hottest topic this year definitely was 3D-IC (Stacked Die). Most folks talk about the Denali party, but DAC #47 was indeed a "coming out" party for 3D-IC design, and three events stood out.

The first one was "Hogan's Heroes: What Nightmares will 22nm Bring?" This panel had participants from Qualcomm, Xilinx and D2S, and was chaired by Jim Hogan, Vista Ventures. They discussed and debated how the limits of lithography will impose new rules for designers, and discussed the industry impact. They agreed that the biggest factor they would lose sleep over at 22/20nm is "cost"...not performance, power, time-to-market but "cost." They also pointed out that costs of double-patterning (which is a must at 22/20nm) are orders of magnitude higher than traditional methodologies up until 32/28nm. And, that makes alternative solutions like 3D-IC viable alternatives to achieve the next scale of SoC integration, without having to weather the risks of migrating to advanced process nodes.

The second event was a GSA (Global Semiconductor Association) Birds-of-a-Feather event on 3D/TSV (through-silicon via) with an overwhelming 125+ attendees. Herb Reiter and his team brought together representativies from major foundries, IDMs, EDA/IP vendors, design services and other industry organizations to accelerate 3D design. The open forum and discussion were definitely a right step in that direction to not only ensure good tools for cost-effective 3D designs, but also to minimize risk and shorten time-to-profit for the companies that design and manufacture 3D ICs.

The importance of extending today's 2D tools to handle 3D design was realized, given widespread market acceptance and usageof 3D ICs. Only then will IC and system designers be able to cost-effectively and efficiently integrate multiple 2D SoCs into 3D systems. In addition, in the GSA market survey of semiconductor companies that asked about EDA vendors with 3D/TSV support, it was satisfying to see Cadence (38%) leading the pack (Mentor is 25%, Synopsys is 18%).

The third event was a panel entitled "3D Stacked Die: Now or the Future?" with speakers from TSMC, Samsung, IMEC and Qualcomm. The good news is that all the panelist companies have already moved beyond traditional 2D design techniques and are utilizing key advantages of the third dimension. These companies might be in different stages of the adoption/deployment curve, but all of them consistently and clearly see a path to fully take advantage of 3D IC design.

Also, the speakers highlighted that the first wave of 3D devices would be hitting the market this year. Actual production designs with real silicon, and in real consumer products! This first batch would primarily have memory on one die and the rest of the SoC on another die. This makes sense since embedded memory takes a large portion of the design, thus growing die-size and decreasing yield. Embedded memory also consumes more power and limits bandwidth, as compared to stacking memory on top of the logic dies.

All in all, the refeshing take-away was that the industry has clearly answered for itself the question: "Is 3D design now or the future?"

The answer is an emphatic "Now." 3D design is certainly happening now and at a rapid pace. And, companies not considering 3D IC design face the risk of missing the boat and being left behind.

Rahul Deokar

Mixed Signal: Why The Sudden Attention?

PeteMc — Mon, 24 May 2010 23:35:00 GMT

With DAC 2010 rapidly approaching, we can again expect that lots of EDA and IP vendors will use “mixed signal” somewhere in their company’s messaging. Last year it seemed that nearly everyone wanted to jump on the mixed signal “bandwagon” … so what caused this sudden jump in interest in mixed signal?

We all know that mixed signal design is not new. It’s been around for about 20 years (give or take), but there has been a shift in the types of mixed signal designs that are being developed.

In the past, a mixed signal design was typically a pretty small design that was created using a manually-driven design methodology. Design engineers drew schematics and simulated the design, while layout designers created the physical layout based on the schematics and constraints from the design engineers. Custom schematic editing and layout tools such as Virtuoso were used for these designs.

As the digital content of these mixed signal designs grew beyond a manageable number of instances, a purely manual implementation approach rapidly became a major bottleneck. Instead, design teams looked to more automated digital implementation solutions, based on standard ASIC methodology. Here at Cadence, we created a specific product for such designs, called Virtuoso Digital Implementation (known as VDI), which complements Virtuoso and enables automatic digital implementation for up to 50K instances. VDI has seen rapid growth, which reflects the growth in these types of mixed signal designs.

In the past couple of years, there have been a growing number of mixed signal System on Chip (SoC) designs … very large, very complex designs that contain multiple digital and analog components fully distributed throughout the chip. A simple example of such a design is shown in Figure 1.

Figure 1: Example mixed signal SoC design

There are many additional design and methodology challenges associated with developing this type of advanced mixed signal SoC chip, mostly related to size and functional complexity. It all starts with early functional verification, where simulators are challenged to simulate huge netlists over large timescales in order to comprehensively validate that the design meets the functional specification. The challenges continue through physical floorplanning, analog/digital/mixed signal implementation and eventually design signoff prior to tapeout.

Large designs mean that power management is critical, while fully distributed analog and digital components force attention to noise management. The advanced process technology, required to enable such large amounts of functionality to be integrated onto the same die, forces even more attention on design for manufacturing techniques, else low yields can be expected.

These design challenges, plus industry predictions that practically every design will be a mixed signal design in the not-too-distant future, are gaining attention for obvious reasons.

Cadence has already focused on all components within our mixed signal design flows to ensure that such complex SoC designs can be efficiently designed. If you are going to DAC, stop by our booth (#1334 in Hall B) and learn why the EDA industry is positioning Cadence as a true leader in mixed signal.

Pete McCrorie

What you didn’t know about DFM for advanced node designs: “In-route” is insufficient

mchacko — Fri, 14 May 2010 20:21:00 GMT

Recently, there has been a lot of buzz about addressing DFM issues during routing. This is not a surprise as the economics of increased development cost of advanced process nodes and manufacturing has influenced dramatic changes to business models of several semiconductor companies. Due to the increasing design cost and time-to-market pressure, a re-design or few weeks delay, because of poor yield for example, may mean the financial death of a project and the subsequent loss of market window opportunity.At 45/40nm and advanced nodes, systematic variations are the greatest cause of catastrophic chip failures, and electrical issues related to timing, signal integrity and leakage power. Ideal-GDSII shapes (squares or rectangles) get converted into contours on silicon, irrespective of any post-tapeout manipulation of GDSII data. This is a leading cause of variability, leading to catastrophic and parametric failures. Signoff DFM has been available since the 65nm node and several EDA vendors have litho hotspot analysis tools. At 40nm, signoff DFM has been made a mandatory part of the tapeout flow by several leading foundries. In this area, Cadence’s Litho Physical Analyzer (LPA) has been the first to qualify at the leading foundries and is the industry’s fastest lithography hotspot detection solution. By leveraging proprietary algorithms, and distributed processing, LPA has proven to deliver near-linear scalability with each additional CPU.Model based litho hotspot detection is compute-intensive and depending on the type and complexity of the design the turnaround time can vary from few minutes to several hours. At Cadence, we integrated LPA with our flagship digital implementation solution – Encounter Digital Implementation System, at the 65nm node. While this was good, that is, signoff litho integration with implementation and leveraging a common database, the core problem remained – increased total design cycle time via iterative feedback loops from signoff to implementation.

The Challenge

How could we improve designers’ productivity and bring litho hotspot predictability in an incremental and convergent manner. Extreme care had to be taken such that by adding an additional DFM step during routing did not cause a big increase in turnaround time and thereby increase in design cycle time.

The Answer

At the advent of the 65nm node, we launched in Encounter Digital Implementation System the industry’s first built-in litho prevention. In other words “in-route prevention” built in to Nanoroute has been successfully used in numerous 65 - 40nm production tapeouts and helped reduce the number of potential litho hotpots during routing. The whole flow is invisible to users and the technology and intelligence was built into the router. Customers simply enabled litho prevention, followed by a signoff run for complete litho hotspot identification and fixing.While “in-route” or “litho prevention” worked well for 65nm, and may be sufficient for some 40nm designs in eliminating a good chuck of the potential litho hotspots in a layout, the widening lithography manufacturing gap at 32/28nm leads to a dramatic increase in complexity. We have come to another point where existing technology (litho prevention or in-route DFM) is okay but not sufficient to enable designers with the best productivity ad predictability for their design flows.

At Cadence we have studied the growing lithography complexity problem and impact on design turnaround time and implemented yet another innovation in Encounter Digital Implementation System to help designers meet their design productivity and predictability goals. The goal is to help eliminate all potential litho hotspots during implementation and truly use signoff as a final verification step. I will explain the innovation in the Cadence approach in the coming weeks.

How are you managing DFM routing today? Let me know.

Manoj Chacko

Hands Up, Anyone Believe That Toyota's Problems Are All Physical?

PeteMc — Mon, 26 Apr 2010 17:00:00 GMT

In the past number of weeks/months we have all seen how Toyota has struggled to manage perception around their "sudden acceleration" problems. The first fix that was proposed was a replacement of the floor mats, under the argument that the mats had been forcing the gas pedal down. Quickly following this first "solution", Toyota announced that they were issuing a recall to fix the mechanics of the gas pedal, adding a small spacer to prevent the pedal from getting physically stuck.

Even during the recall, there started to appear a number of people who were stating that their pedal wasn't physically stuck, and that they were unable to turn off the engine or shift the car into neutral. The implication is that while the physical fixes may have helped, there might be a more underlying problem associated with the electronics.

There are some good reference pages online (example report from Frost & Sullivan) that show how the automotive industry is expanding its use of integrated electronics.

As far back as 2003, BMW announced that their 5- and 7-series cars already had upwards of 100 microprocessors in them, to manage functions from engine control to opening the windows, and unless designed very carefully, these systems could fail a number of different ways. One failure mechanism is the software itself getting locked in a tight loop ... who hasn't had to force a reboot on their computer to get it out of such a situation? Another failure mechanism could come from some form of electrical interference, either in the wiring harnesses or directly in the microprocessor and sensor chips.

With safety as their #1 goal, automotive suppliers must perform rigorous testing and validation to prove that their components are not going to fail under some harsh conditions, including large operating temperature ranges, high levels of humidity, varying voltages, electro-magnetic interferences, mechanical stress ... the list is long.

Specifically for the chips that are used in automotive systems, there is an absolute requirement that they are validated to correctly operate under all possible conditions and scenarios. What does this mean to the automotive chip design team? Many weeks of simulations to ensure that the functionality is operating correctly in all possible modes of operation, extended physical verifications to ensure that the chips do not fail due to the high stress environments that they execute in, and extended electrical checking to ensure that timing, IR drop, electromigration, Joule heating, electro-static discharge, latch-up, signal integrity and ... and ... and ..., are all fully validated.

EDA is a critical component of design, and so we must ensure that EDA tools and functionality used to perform such comprehensive verifications and validations continue to keep up with the ever-advancing chip design requirements and the ever-increasing focus on safety.

If you are interested in a similar viewpoint of the challenges of the automotive industry, you might want to take a look at the blog from Richard Goering on the Toyota Prius.

Is there anyone from the automotive design industry that would like to give us the views from the design team?

Pete McCrorie

EDP Symposium Uncovers an Inconvenient Truth with a Shot of 3D

RahulD — Fri, 16 Apr 2010 15:00:00 GMT

Every April the leading edge of the leading edge of semiconductor industry meet at the Electronic Design Process (EDP) Symposium to address design problems that make design more difficult than it should be. This was my first visit and chance to rub shoulders with the industry's gurus and to discuss the arc and future of EDA tools and the EDA industry.

The nice thing about the EDP symposium (often referred to as the "secret DAC") is that it favors open discussions around presented papers. It is a sound mix of academic and industrial research and experiences and the goal is to foresee what the coming design problems might be and propose either solutions or alternatives. This year, the programme included a number of interesting topics including parallelism/cloud-computing for EDA, high level design/ESL, and 3D ICs.

I had the privilege to present on 3D IC design - particularly the latest work/trends around Through-Silicon Vias (TSV). For those of you that are new to this area, here's an interesting article that helps understand the foundational elements: http://www.cadence.com/Community/blogs/di/archive/2010/03/29/My-DATE-With-3DIC-Technology.aspx. The beauty and promise of this new technology is that it can inject a fresh breath of air into the semiconductor industry and give life to a whole new world of consumer end-applications. It can provide a huge paradigm shift to what can be achieved in design performance, power, and form factor.

The inconvenient truth is that the semiconductor industry is at crossroads. The cost of doing design in the traditional 2D methodology is getting exhorbitant. For instance, designing at 32/28nm incurs 3-4X the cost of design at 45nm (spanning fabrication costs, design costs, process and mask costs). Additional manufacturing effects like lithography, chemical-mechanical polishing, stress, and double-patterning are rendering the move to advanced process nodes exceedingly difficult. To make matters worse, we get hit with a double-whammy since the time-to-production on advanced process nodes has increased significantly, and that takes its toll on the profit margins for the industry.

And, this is where the new 3D/TSV solution shows promise to be the panacea to the industry's ailments. The biggest benefit it offers is the flexibility of heterogeneous integration. Designers no longer need to move the entire System-on-Chip (SoC) to the latest process node, thus eliminating a lot of the risks, costs and time-to-market delays. Design companies can choose to keep their analog, full-custom and memory IP at the older, safer process nodes while they move the aggressive CPU/GPU/digital logic to advanced process nodes. Essentially, designers now get the best-of-both-worlds by mitigating the cost, complexity, risk, and development time. And the end-result is smaller and faster and lower-power.

Thomas Williams from Future Tech and Sungkyu Lim from Georgia Tech also talked about 3D/TSV in their presentations. An interesting way of looking at the cost savings from 3D/TSV is the following: Let's take a traditional methodology for an SOC chip on a signle die with dimensions (L x L). The footprint/area of this device would be L² and the corner-to-corner distance would be 2L. Now consider this chip to be implemented in 3D as a stack of 4 dies with each die dimensions of (L/4 x L/4). The footprint/area of this device would be L²/4 (one fourth of the original). The corner-to-corner distance would be much smaller to the original as well (L + h, where h is the height of the stack). And this reduced area and corner-to-corner wire-length is what effectively translates to significant benefits in performance and power for the 3D/TSV methodology.

In the real world, I see several semiconductor companies are now taping out real production chips. Some of them are also using "Silicon Interposers" which are silicon platforms with TSVs and enable different dies to be connected. It looks like the light at the end of the tunnel is real, and not just a false hope. While this technology and approach might not be for everybody (as was righly debated at the EDP symposium), it is certainly is a differentiating strategy for the select few semiconductor vendors who have embarked on this 3D/TSV path.

Have you looked at this 3D/TSV technology? What's your take on it?

-Rahul Deokar

IR Drop Analysis: It's Not Really Necessary, Is It?

PeteMc — Mon, 05 Apr 2010 18:25:00 GMT

I was recently asked by an engineering manager if running IR drop analysis was really necessary. The argument to support his question was that his engineering team always over-designs the power rails, and so the risk of getting high IR drop was so small that analysis was not required.

The easiest way to answer his question was to relate what actually happened during the creation of a DAC demo a number of years ago.

The demo was designed to initially suffer from high IR drop in the center of the design, and the plan was to short the VDD of this region to a solid VDD, and hence fix the high IR drop. Figure 1 shows the initial IR drop analysis results, with the high IR drop in the center of the design. You can also see the solid VDD net just below the red region of IR drop.

Figure 1: Initial IR drop plot

While the added jumper did help reduce the highest IR drop in the center, it also enabled current to flow through a completely different path from the lower right boundary VDD I/O pad to the center of the design. This new path caused higher currents to flow around a memory, and resulted in new electromigration (EM) failures around the sense-amps of the memory. Figure 2 shows a zoomed in view of the lower right of the design, where you can see the added VDD jumper and the new EM failures.

Figure 2: VDD jumper plus new EM problems in lower right memory

When we saw this result, it surprised everyone involved and we were all experts with many years of experience in both chip design and IR drop analysis. No-one could have predicted how the addition of a small jumper in the center of the design could have caused new EM problems towards the corner of the design.

That's the reason why power rail analysis is required!

While we would like to believe that we can predict how current flows through the power network, in reality the current often flows unpredictably through multiple levels of interconnect and complex gridded power networks. It is the inability to predict how the current flows that forces the need for analysis. How can you possibly over-design the power rails when you don't know where, and how much, current is flowing though them?

Anyone have other thoughts on this?

Pete

My DATE With 3DIC Technology

samtabansal — Tue, 30 Mar 2010 00:10:00 GMT

This year DATE (Design, Automation and Test in Europe) was in snowy cold Dresden, Germany, March 8th-March 12^th and offered several 3DIC topics during the conference. I heard someone say "How did 3D with TSVs become hot from cold just so quickly?" In fact it did. Last year when I was following this technology I had found the design community to be hesitant in the feasibility of this technology in the beginning with lots of secretive projects in the pipeline. Suddenly by the end of last year, several IDMs, foundries, Cadence, and other EDA vendors were sharing methodologies and flows around 3D. There is now at least one discussion on this topic, at every industry conference, in various forms - panel, paper, etc.

For some of you who might be wondering what am I talking about let me share some background information: 3D is the stacking mechanism engineers have been using for several years to squeeze-in smaller package size to accommodate for smaller, denser electronic devices that consumers need and demand (think cell phone, heart pace makers..tiny gadgets !!)

Added to that need of miniaturization is performance and density and that starts a trend called 3D TSV : It is a technology to stack chips on top of each other with a silicon layer in the middle with TSVs (Like Vias just too large) going between them. This helps performance, miniaturization and enables flexibility of combining Analog, RF, and Digital all on one package eliminating the need of wire bonding them down. Obviously as you may imagine this adds the complexity for the EDA tools to move from one dimension analysis to 3D knowledge.

Coming back to a more interesting topic - DATE in snowy Dresden, Germany. DATE had 3 big 3D IC centric events - 3D tutorial session, 3D dinner event, and 3D Workshop. I was able to attend the first and the last. I was pleasantly surprised to see two things: People's interest on this topic and actually given the newness of 3D with TSV technology, its increasing adoption by customers. I have to say "It is here today and it is taking off sooner than expected".

Both DATE 3D tutorial and Workshop had some good papers/presentations from EDA vendors and customers who have dared to be first in adopting 3D. I noticed more sharing and more EDA players than last RTI conference I was in. From all the papers, talks, panels, keynotes one thing was clear that community is expecting EDA vendors to accelerate the tool development to support the growing 3D with TSV trend. Apart from EDA vendors telling which part of the 3D flow they are enabling and helping out with, what also caught my attention are the questions that lingers around 3D :

Ecosystem readiness :
- Are Foundries ready?
- What will the business model look like between OSAT and Foundry?
Standards
- Too many approaches (Via first, Via Last, Via Middle) today
- How to do 3D test to answer questions on reliability and yield? (2 redundancy/4 redundancy approach, iJTAGs, KGD, TSV and Micro bump Fault modeling)
Cost of 3DICs with TSV vis-à-vis moving to the next smaller geometry

I think until and unless we find out the answers to the above, there will still be hesitation in the 3D wider adoption. In order for 3D TSV to really take off and become mainstream, I expect to see more close knit, open discussions and convergence on the above questions else it will remain just a niche technology !!

Samta Bansal

Signoff-Driven Implementation = Consistent and Convergent = Predictable and Efficient

mikeNaustin — Wed, 10 Mar 2010 17:38:00 GMT

Digital designs are reaching 10's of millions of instances, which makes efficiency of the overall digital implementation and signoff flow critical to ensure predictability in the design schedule. A major stumbling block that can be a real threat to that predictability is iterations between different stages of the design flow. There are multiple reasons why this happens but one that should not happen is because you have two design stages giving you two different answers with the same set of data.

The most common, and likely the most costly, is when your implementation tool disagrees with your signoff analysis or extraction tool. At this late stage in the design flow, fixes are costly and time consuming. Also, how do you know which is right? Did your implementation tool miss something or is your signoff tool too pessimistic?

Adding margin to your implementation tool for timing or power is one way to mitigate this problem but this can be costly in several ways:

Degrades chip performance when timing margins are already tight
Area and power consumption will increase
Makes your optimization work longer and harder to close timing - major productivity killer

The easy way around this dilemma is leverage high-precision tools which use the signoff analysis and extraction engines to drive implementation. This way your analysis results are consistent and convergent throughout the flow and you don't get any surprises at the end during signoff. You can essentially catch problems early in the design process which makes them much easier to fix.

It's for this exact reason that Cadence has integrated our signoff analysis and extraction technologies into our implementation environment. Our production proven signoff technologies - Encounter Power System for power analysis, Encounter Timing System for timing and signal integrity, and QRC for digital extraction are built-in the Encounter Digital Implementation (EDI) System. Since we've done this, our users have seen some major productivity benefits when using the complete solution.

A bonus is that, with this integration, you can also signoff during implementation if you like without going to a separate signoff tool. In fact, we have many customers doing just that at 65nm and above where the number of timing and power runs for signoff are much less. This eliminates the need to re-run your timing and power analysis in a different session or tool. Also, it allows the implementation environment to take immediate advantage of the latest analysis capabilities such as advanced OCV, statistical timing, thermal analysis, technology files, etc. to fix design problems instead of just finding them.

You may be wondering... will this slow me down if I'm using signoff engines at every stage? Actually, in this case an ounce of prevention saves you a ton of iterations. And, with the latest developments in mult-CPU performance and capacity of our analysis and extraction solutions, the flow stages are actually much faster.

In short, you should always be doing implementation with signoff in mind so there are no surprises. Signoff-driven implementation = consistent & convergent = predictable & efficient

Mike Jacobs

Encounter How To: Writing To/Reading From a File With TCL

BobD — Wed, 24 Feb 2010 15:20:00 GMT

A couple weeks ago, there was a good thread in the Digital Implementation Forums about managing buffering on nets between IOs and registers. The post touched on a number of interesting topics, but one of the fundamental building blocks I'd like to expand upon in this blog entry is the fundamental task of writing to and reading from a file: File I/O.

It may seem like second nature for folks who use TCL-based tools like Encounter regularly, and it's pretty much straight TCL that we use to write and read, but I hope having concise examples of how to do this within Encounter is a useful reference.

Reading From a File

Say for example you received a list of nets in a file that needed to be routed on upper metal layers. Here's an example of how you would read from that file and use the "setAttribute" command to apply that routing constraint. Say your file looked like this:

   critical.nets:
   n_5822
   n_5828
   n_5834

Here's how we'd do it:

   set infile [open critical.nets "r"]
   while {[gets $infile line] >= 0} {
   setAttribute -net $line -bottom_preferred_routing_layer 5
   }
   close $infile

Writing To A File

Say we wanted to capture a list of all of the nets in the design that are connected to IO pins? Here's how we could do it:

   set outfile [open io.nets "w"]
   foreach net [dbGet [dbGet -u top.terms.net].name] {
   puts $outfile $net
   }
   close $outfile

Redirecting Command Output To A File

Another scenario that's often useful is when we want to take command output that's echoed to the console and redirect it to a file. We can use the "redirect" command for this purpose. (Note: The command is not documented. This will be rectified in the next release.) Say for example you wanted to parse the output of the verifyGeometry command to see whether there were any violations. Here's one way you could do it:

   redirect verifyGeometry > verifyGeometry.out
   set infile [open verifyGeometry.out "r"]
   while {[gets $infile line] >= 0} {
   if {[string match *Verification* $line]} {
   set nrViols [lindex $line 3]
   }
   }
   close $infile
   puts "verifyGeometry reported $nrViols violation(s)"

Tip: It's much easier to use "dbGet top.markers" to see whether there are violations in the design after running verifyGeometry:
encounter 1> dbGet top.markers
0x2aab94d740 0x2aab94d5f0

Separately, some commands like report_timing support ">" and ">>" redirection. For example:

report_timing > timing.report

We're looking to expand this easy ">" mechanism to include other commands in a future release.

I hope these examples are useful. Any related tips you'd like to share?

-Bob Dwyer