Digital Implementation

Find, Fix And Learn With Cadence Online Support

2009-11-05T18:00:00Z

We recently rolled out a new online support mechanism that replaces Sourcelink called Cadence Online Support. Point your web browser to sourcelink.cadence.com and you'll notice that it redirects to support.cadence.com.

Improving the search capabilities was one of the major focuses of Cadence Online Support. A single box enables searching across the following areas:

Troubleshooting
Product Manuals
New or Changed Features
Design Info
Blogs and Forums

Additionally, the "Top 3 Overall Matches" across all of these areas are returned. The result, hopefully, is that it's easier to find the information you're looking for. Check it out and let us know how we're doing.

(click to enlarge any of these images)

You can also provide Feedback specifically about any page on the new site. Please take advantage of this capability- we really want to hear what you think and your Feedback will be responded to and tracked to closure:

The new site surfaces up your most recent service requests, and provides a link to create a new service request:

Finally, the site offers a way to learn about how our tools are intended to be used with "Design Topics". Design Topics are the place to look when you don't have a specific bug or issue you're trying to troubleshoot but rather when you want to understand conceptually what Cadence recommends at any given stage on the design process. This information is accessible via Design Topics->View Design Topics on the top of Cadence Online Support pages. Here's an example of the available subtasks within Block Implementation. You can expand any one of these subtasks for more information -or- go directly to any one of the Technical Topics for more information:

So there you have it: Find, Fix and Learn. Click HERE to learn more about Cadence Online Support (login required using your existing Cadence.com password).

Question of the Day: What do you think of the new Cadence Online Suport so far? Leave a comment below or make use of the Feedback mechanism within Cadence Online Support.

Bob Dwyer

Cadence and Very Cool Stuff

2009-11-03T17:44:00Z

One of the very cool things about my job is that I get to see all kinds of new stuff early. I’m privileged to be involved in technology roll outs, and so get to be involved in early discussions with R&D, Product Engineering, and Marketing. And, I gotta tell you, there is very cool stuff coming out.

As I think we’ve established, I’m a geek. (And there’s my daughter again, rolling her eyes, and saying, “tell’em something they don’t already know, Dad.”) And so when I get a chance to see some of the new stuff being prepped by our R&D teams, I get pretty excited.

Here’s just one thing that’s on the burner – a method to explore the power solution space. I met a good customer today, and he very accurately pointed out that Power Shut Off (PSO) is a system function. The system designers very clearly know what blocks can be shut off when – it is a system function. But Multi-Supply Voltage (MSV) is another matter. Fundamentally MSV is about trading off speed for power – the faster you need it, the more power you’ll need. And this really means that any effective power estimation solution needs to consider the libraries, architecture, and expected implementation. If you don’t consider these, you’re not looking at the full picture. In the absence of the ability to estimate the impacts of timing, any kind of architectural analysis is largely meaningless. I mean, why not set the voltage on everything to 0.1v? You’ll save a ton of power. Of course timing closure might be a bit challenging.

So we’re getting ready to come out with something that will allow exploration of the power solution space; something that will really allow you to trade off speed for power. You set up the starting points – stuff like the libraries, constraints, and the like. You then set up the bounding conditions – the allowed solution space. The tool will then go off and run through the scenarios, identifying the best combination of voltages that will meet your timing and power targets. Under the hood, the tool is taking advantage of RTL Compiler’s target setting function to identify whether a given scenario will meet the requirements.

This will take the guess work out of MSV designs. What I really like is that this is the same technology that will then produce a production quality netlist. So correlation is not an issue – there’s no magic library conversions or RTL manipulations to produce this. You pour RTL, libraries, and constraints in, and you get the right scenario out. And you can then just push the button to implement the scenario.

As I mentioned, I was at a customer today. With me were two members of the R&D team – both PhDs and both widely known in the industry. We were presenting the challenges of low power design and how Cadence flows and methodologies solve those challenges. Now these are seriously smart people, and to see their passion and enthusiasm for the technology was contagious. These R&D guys really know their stuff, and they’re committed to making my customer successful. Cadence has (obviously) being going through a down cycle. But with guys like these, and with the technology we’ve got, no one should count us out. Nor should anyone discount our commitment to our customer’s success. We still have the best flows and tools and technology, and we’re still driving the innovation in the industry. We’ve not changed our passion or commitment one little bit – and don’t let anyone tell you differently.

Oh, and here’s a chance for you to hear about the latest innovations in the Front End Design space: Cadence is hosting the annual FED Event in San Jose on Nov 10. This is an event with R&D leaders discussing the new technology and innovations coming out in the next releases. You’ll hear from all of the R&D leaders in this space, and hear from other customers using our technology. And you’ll even get to see me – I’m on a panel offering my perspective about FED. Sign up at www.secure-register.net/cadence/ld_event2009 and I hope to see you there.

Rich Owen

Encounter How-To: Write Text to The Log File With "Puts"

2009-10-30T16:00:00Z

Here's a simple but useful tip that shows how to write to the log file using the Encounter command "Puts"...

In TCL, the "puts" command is use to write information to the console -or- to a file. For example:

encounter 63> puts "hi"
hi

-or-

encounter 64> set outfile [open test "w"]
file18
encounter 65> puts $outfile "hi"
encounter 66> close $outfile
encounter 67> more test
hi

But, how do you write information to the log file? Although it's possible to get the name of the current log file (and that's a useful tip in itself):

encounter 68> getLogFileName
encounter.log207

...it's not clear how to get the handle of the log file so that we can write to it with puts. It turns out- you don't need to because there's a special built-in command called "Puts" (note the capital "P") that writes to the screen -and- to the log file:

encounter 69> Puts "hi"
hi

Note: that the string is still written to the console.

Note: too that the string is written to the log file:

encounter 70> tail -1 encounter.log207
hi

Writing to the log file can be particularly useful when troubleshooting a script and you want to write checkpoint statements that you can later search for using a text editor.

I hope this is useful.

Bob Dwyer

How To: Purge Interactive Constraints in MMMC Mode

2009-10-23T13:00:00Z

These tips are applicable to the Encounter Digital Implementation System.

Back in the good old days, I remember asking designers at the beginning of a silicon virtual prototyping evaluation "Where is your timing constraints file?" Note the singular form of the word file- was it really that simple? Didn't seem so easy at the time. While the complexity of timing constraints in terms of their content has increased, managing the actual files that contain the constraints, how they apply to multiple constraint modes in the tool, and dealing with incremental additions to the active constraint set is increasingly complex.

A scenario came up with a customer I was working with recently that led to a solution that I thought would be good to share. The designer was using MMMC (multi-mode/multi-corner) timing analysis, and wrote a script to query the timing graph, add timing constraints that would alter the timing graph, and then write out a list of ECOs that needed to be made to the design based on what his script found. He wanted a way to clear out the interactive timing constraints his script used while retaining the timing constraints associated with each of the views as defined in the viewDefinition.tcl file.

Interactive constraints are simply the constraints entered at the command line (or sourced in a file) that aren't part of the files associated with the create_constraint_mode command:

create_constraint_mode -name common_constraint_mode -sdc_files testcase.sdc

When we're in MMMC mode, and we want to apply a timing constraint at the command line, we need to tell the tool which of the constraint modes we'd like the interactively-entered constraints to apply to:

encounter 2> set_false_path -from i0 -to i1
**ERROR: (TCLCMD-1048): There is no interactive constraint mode. The constraint will be ignored. Please use 'set_interactive_constraint_modes' command.

Tip #1: When I get this message, I find the quickest way to get past it (and ask the tool to consider the constraints I give it for all active views) is to apply the constraints to all the active constraint modes. This can be time consuming if you need to recall all of the names of the constraint modes via cut and paste, so we can retrieve these modes programmatically like this:

encounter 6> set_interactive_constraint_modes [all_constraint_modes -active]

Now the tool will accept the interactive constraint and apply it to all the active views. My simple design only has 2 registers so if I false_path -from/-to the registers I'll see no constrained paths:

encounter 7> set_false_path -from i0 -to i1
encounter 8> report_timing
No constrained timing paths found.

Tip #2: So now if I wanted to ask the tool to forget this interactive constraint (the false_path) and revert back to the sdc files associated with the constraint_mode, here's how I'd do it. We can make use of the update_constraint_mode command (which is primarily used to append/delete sdc files to the current list and replaces the unloadTimingCon command when not in MMMC mode). Specifically, we'll leverage a nuance regarding whether interactive constraints are retained or purged when you reset the sdc files:

encounter 11> update_constraint_mode -name common_constraint_mode -sdc_files testcase.sdc
**WARN: (TCLCMD-1122): The update_constraint_mode command will reset all interactive constraints for all views. Any interactive constraints entered before this command will be lost.

Let's confirm that the design is again timed as we'd expect it to be:

encounter 12> report_timing
Path 1: MET Setup Check with Pin i1/CK
Endpoint: i1/D (v) checked with leading edge of 'clk'
Beginpoint: i0/Q (v) triggered by leading edge of 'clk'

If we wanted to use this approach to reset the sdc files associated with all of the active views, we could do that. But again, this could be laborious to keep track of in contemporary designs were we have dozens of modes and even more sdc files.

Tip #3: A better way would be to retrieve the sdc files associated with all of the active views and re-point each constraint mode to the current sdc files (thus purging the interactive constraints as previously described). Here's how to do it:

foreach constraint_mode [all_constraint_modes -active] {
set constraint_files [get_constraint_mode $constraint_mode -sdc_files]
update_constraint_mode -name $constraint_mode -sdc_files $constraint_files
}

Tip 4: To refine things a bit, we could wrap this up into a procedure that we could call any time we wanted to purge the interactive constraints we've entered. We could share this procedure across other designers we work with:

proc user_purge_interactive_constraints {} {
foreach constraint_mode [all_constraint_modes -active] {
set constraint_files [get_constraint_mode $constraint_mode -sdc_files]
update_constraint_mode -name $constraint_mode -sdc_files $constraint_files
}
}

I hope this was generally useful in understanding how interactive constraints work in MMMC mode, and in describing an efficient way to manage interactive constraints.

Bob Dwyer

Leakage Power and National Security

2009-10-09T13:00:00Z

I read an interesting article recently on EDN regarding a new way to determine cryptographic keys using leakage power. Differential power has long been documented to be a method of cracking keys. In this paper, the author, Milena Jovanovic of the University of Montenegro demonstrated that leakage power can also be used to predict the key contents.

I can’t pretend to understand the techniques behind cryptography (my knowledge of security doesn’t go much beyond looking for the little lock icon on my browser), but this does point out the importance of accurate activity files for all power optimization, not just dynamic opt. Modern libraries have state dependent leakage tables, and the Cadence tools can perform power optimization and analysis based on the activity factors and leakage tables.

In order to effectively use this state dependent leakage, you need to have accurate data. When I talk to customers, this routinely come up as a major issue – test benches are not naturally built to generate accurate usage. Instead, test benches are built to test things – to see whether or not the design meets the requirements. One solution is to run real use cases, and capture the activity. In reality, this is difficult to do, particularly with any kind of embedded software application. Hardware accelerators can solve this problem, allowing users to run real software, and to zero in on activity areas of interest – I’ve blogged about Palladium DPA previously.

But clearly, you gotta take leakage much more seriously now. As if heat, package, and battery life concerns aren’t enough, you’ve now got to worry about security and some guy with an ammeter dissecting your algorithms!!

Richard Owen

Running Low on Power or Receiving Mixed Signals? Talk to the Expert Users

2009-10-06T18:48:00Z

Everytime my wife and I are looking to buy a big item, we do our research by reading blogs, articles, and customer reviews. I have to tell you, the single best source for information is through customer reviews and testimonials by actual users. Testimonials not only included the good stuff, but they also include items that cover 'areas of improvement' in a particular product.

I think the concept is applicable to purchasing EDA software as well. The best way to learn about a product is by talking to expert users. I would like to tell you about two events where you have the opportunity to do just that. We have invited a myriad of expert users to discuss their design challenges and talk about solutions that they are using to get ahead of their competition. And oh yes, they will also talk about items that they'd like to see in currently available EDA tools.

1. Power Forward Low-Power Design Summit: in this event over 10 member companies will make technical presentations on the topic of enabling power efficient design from system to silicon. You can hear design challenges that you might be struggling with today and solutions that you should be using today. Find out more at www.powerforward.org.

2. Mixed-Signal Summit: Get your signals straight at the first annual mixed-signal design summit. Become part of a community and discuss applications and methodologies with expert users. Find out what it takes to be ready to tackle mixed-signal designs. Find out more at www.secure-register.net/cadence/ms_summit.

But don't stop there. Come back to this blog and challenge our presenters and participants by asking them more questions about today's design challenges, what it takes to get ahead of the competition. If you hear something that needs to be elaborated, but you didn't have time to ask during the event, come back to this blog and post your question. If you see something that needs to be highlighted, good or bad, I encourage you to come back to this blog and post your comments.

You can call it tools, solutions, methodologies, or products; the best way to learn about it/them is by listening to current users.

Soheil Modirzadeh

Lost and Found: Missing Filler Cells, Power Vias, and Highlighted Objects

2009-08-28T13:15:00Z

Have you ever gotten to signoff DRC and found that there was a small area where a filler cell did not get placed for some reason? Well, now there's an easy way to check for that with the checkFiller command:

   checkFiller -highlight true



To get rid of the highlights, do this:

    checkFiller -clearHighlight true

Another thing that is often found near the end of the design flow is missing power vias. You may have an IR-drop issue that leads you to discover this, or you may find it by visual inspection. In the old days, before taping out a chip we would turn on just two layers at a time, and the via layer between them, and visually check the whole power grid to make sure there were vias at every intersection. Now, you can easily check this anytime with verifyPowerVia:

   verifyPowerVia

After running the command, you'll see the violation marker in your design, and you'll also get a report that looks like this:

###############################################################
# Generated by:      Cadence First Encounter 08.10-s273_1
# OS:                Linux x86_64(Host ID crvclo16)
# Generated on:      Thu Aug 27 14:49:51 2009
# Command:           verifyPowerVia
###############################################################
Verify Power Via report created on Thu Aug 27 14:49:51 2009

Net VDD: Missing via at (414.280, 621.190) (422.280, 629.190) between layers: M5 and M6.

Begin Summary
    Missing 1 Via(s) between Layers: M5 and M6.
    1 total info(s) created.
End Summary

You can narrow down which layers you want to check with the -layerRange parameter.

Finally, sometimes in large designs, or when you have a lot of things displayed in the GUI, it can be hard to find one small thing that you've highlighted either in the design browser or with a script. You know it's highlighted, but you still can't see it! To make it easier to find, you can hit the F9 key to dim everything but the highlighted object. There are two levels of dimming, and the third press of F9 returns the GUI to normal. Here's an example of how it looks:

Much easier to spot!

I hope these things will help you find the missing pieces of your design.

Co-Design - Its Not Just an Exercise in Excel Any More - Learn Why at the Aug. 26 Webinar

2009-08-14T14:01:00Z

Co-Design … some are trying to do it with spreadsheets … everyone is talking about it. But talk is cheap. Can you really optimize a package footprint and a chip I/O padring such that that package and PCB costs can be minimized?

What if using a straight forward flow you could take the devices to which your chip needs to interface and place them on a canvass with your chip and package. And then what if you could then see the maze of interconnect lines that crisscross in every imaginable direction giving you the daunting task of trying to figure out how to unravel that mess? But then, what if, with a few simple clicks of a mouse, you could turn …

Wouldn’t that make the routing your board and package easier? Wouldn’t that help keep costs down on your final product?

Yes, as a chip designer, you can look out into the package and board and optimize the full system. If you want to learn how Cadence SiP Digital Architect empowers chip designers to do just that, come see John Park’s webinar on August 26. You can register for the “SoC I/O Padring Optimization Using Cadence SiP Co-Design Technology” webinar by clicking here.

Please let us know what you think of the webinar.

Brad Griffin

Useful dbGet One-Liners

2009-08-12T13:00:00Z

We've gotten some good feedback about posts in this forum relating to dbGet and dbSet (the database access mechanism inside SoC-Encounter). I've been collecting interesting dbGet/dbSet lines over the past several months that I think are very useful. Some of these may be something you've wanted to do as well, or maybe they will serve as a starting point for a different idea or even a longer script. I gave credit to the people whose emails I extracted these from:

Get a list of unplaced cells: (Laurent Lefebure)
   dbGet [dbGet -p top.insts.pStatus unplaced].name

See what metal layers your block's IO pins are on: (Bob Dwyer)
   dbGet top.terms.pins.allShapes.layer.name

Get a list of NONDEFAULT rules in the design: (Gary Nunn)
   dbGet head.rules.name

Get the placement status of an instance: (Ali Aslani)
   dbGet [dbGetInstByName instName].pStatus

Get the points of a rectangular routing blockage: (Bob Dwyer)
   dbGet top.fplan.rBlkgs.shapes.rect

Get the points of a rectilinear routing blockage: (Jon Cooper)
   dbGet top.fplan.rBlkgs.shapes.poly

Get a list of all cell types used in the design: (Gary Nunn)
   dbGet -u top.insts.cell.name
   (The "-u" filters out duplicate objects.)

Get the size of block placement halos: (Kari Summers / Bob Dwyer)
   dbGet [dbGet -p2 top.insts.cell.subClass block*].pHaloTop
   dbGet [dbGet -p2 top.insts.cell.subClass block*].pHaloBot
   dbGet [dbGet -p2 top.insts.cell.subClass block*].pHaloLeft
   dbGet [dbGet -p2 top.insts.cell.subClass block*].pHaloRight

Get the size and top/bottom layers of block routing halos: (Bob Dwyer)
   dbGet [dbGet -p2 top.insts.cell.subClass block*].rHaloSideSize
   dbGet [dbGet -p2 top.insts.cell.subClass block*].rHaloBotLayer.name
   dbGet [dbGet -p2 top.insts.cell.subClass block*].rHaloTopLayer.name

Make sure all your tiehi/lo connections have tie cells (and are not connected to a rail instead): (Gary Nunn)
   dbGet top.insts.instTerms.isTieHi 1
   dbGet top.insts.instTerms.isTieLo 1
   (Should return "0x0" if all connections have tie cells.
     If "1"s are returned, use the following to find the terms that still need a tie cell:)
   dbGet [dbGet -p top.insts.instTerms.isTieHi 1].name
   dbGet [dbGet -p top.insts.instTerms.isTieLo 1].name

Change the routing status of a net (for example, from FIXED to ROUTED): (Gary Nunn)
   dbSet [dbGet -p top.nets.name netName].wires.status routed

Get the status of your design: (Siva Kumar)
   dbGet top.statusIoPlaced
   dbGet top.statusPlaced
   dbGet top.statusClockSynthesized
   dbGet top.statusRouted
   dbGet top.statusRCExtracted
   dbGet top.statusPowerAnalyzed

List all the FIXED instances in your design: (Bob Dwyer)
   dbGet [dbGet -p top.insts.pStatus fixed].name

Find out which layers are used in a net: (Bob Dwyer)
   dbGet [dbGet -p top.nets.name netName].wires.layer.name

Find all the instances of a certain cell type: (Laurent Lefebure)
   dbGet [dbGet -p2 top.insts.cell.name cellName].name

Get the size of a cell in the library, but not necessarily in the current design: (Rob Lipsey)
   dbGet [dbGetCellByName cellName].size

I'm sure there are many more useful dbGet/dbSet one-liners out there; let's hear yours! Please post in the comments some of the dbGet lines that you have come up with.

5 Fascinating People I Met at the 2009 Design Automation Conference

2009-08-03T10:00:00Z

As much as the Design Automation Conference (DAC) is about demonstrating solution capabilities to potential customers, it is also about personal connections. Reconnecting with old and current colleagues, and making new connections with people in the design community you haven't had a chance to meet before is as important as anything else you might do at DAC. Maybe it was just me, or maybe it was because of Twitter and the resultant familiarity with some of the people I met for the first time at the conference, but there seemed to be a level of friendliness between competitors that I'd not seen before.

I enjoyed meeting a lot of great people at this year's conference. Here's a list of 5 people that I thought were particularly fascinating:

Karen Bartleson from Synopsys is one of the nicest people in EDA (and that's saying something because there are a lot of nice people in EDA). Karen did an amazing job facilitating vendor neutral conversations in their "Conversation Central" room (a small room adjacent to the Synopsys booth with about 8 chairs and lots of good snacks). She also rallied folks around the #46dac Twitter hash tag for the conference, which was in turn broadcast on a 17' tall Twitter tower live at the show. In a somewhat bizarre cross-vendor connection, Karen gave me a flyer with a schedule of talks they'd be having which I in turn passed along to Magma CEO Rajeev Madhavan who promptly informed me that he was already planning to drop in! What a mash-up of EDA companies. Karen was voted "EDA's Next Top Blogger" at this year's DAC for her blog The Standards Game. You can follow @KarenBartleson on Twitter.

Here's Karen behind the keyboard:

I got a chance to meet John Cooley for the first time. I've been a reader of DeepChip.com for as long as I've been in the industry, so it was a bit of a surreal experience. He dishes it out in person just like he does on his site and in the videos I've seen him do. John is a controversial guy for his role as moderator of DeepChip, but the filter he applies and sensibility he brings to the information he delivers is part of why people read what he publishes. Like him or hate him, he's got a following in the industry. The most enlightening thing I learned about him is that the bulk of the work he does these days does not come in the form of long-term design contracting. He consults helping chip projects get "unstuck", but also does due dilligence studies of chip design and EDA companies on behalf of venture capitalists. John said he doesn't see value in Twitter at this point (the signal-to-noise ratio is poor), and he recommends against starting your own EDA blog without knowing what you're getting into. Why? Because 99.5% of blogs fail within 2 months, and even if they're successful they can sometimes end up owning you; constantly demanding that you keep it up to date. To test the waters, he suggests sending your EDA/chip thoughts to DeepChip.com, where it has a built-in audience of 25,000 subscribers and there's no requirement that you update there constantly. "I see 2 to 10 emails a week for new blogs. A good 99.5% consist of 2 or 3 posts on EDA, then 1 post about how cute their kid is, then nothing," reported John.

I had a chance to sit in on a small group conversation with Ron Ploof, and to chat with him for quite a while afterwords. What a trip. We covered a ton of ground discussing all things social media as it relates to corporations, especially EDA. Ron is one of the savviest guys in the world when it comes to social media, and his experience working with EDA companies make him incredibly well suited for consultation in this space. I'd highly recommend you check out his blog and connect with him if you're looking to discuss social media with someone who truly knows what he's talking about. Most memorable takeaway: In a group of 100 people, 1 will create content, 9 will interact with it, and 90 will consume it silently. You can follow @RonPloof on Twitter.

JL Gray from Verilab is a really gracious and enjoyable guy to talk to. He moderated a small group conversation on EDA blogging that I thought was fascinating. JL has been blogging since July, 2005 on CoolVerification.com so it was great picking his brain and comparing notes with him on what works well in blogging as well as some of the challenges he's faced over the years. The thing I'm still thinking about since that conversation: Is there a truly objective voice with no conflicts of interest producing content anywhere in EDA? My takeaway: As a corporate blogger, there's tons of things you can write about without being critical of your product or a competitor's. Like producing useful content focused on helping customers be more successful doing their jobs. You can follow @JLGray on Twitter.

From left to right: Ron Ploof, me (Bob Dwyer) and JL Gray

Deepak Das is another voice to listen to. We discussed whether social media will "work" as well in EDA given confidentiality requirements of customers, historical lack of interaction between competing EDA companies, and engineering personalities in general being perhaps less interested in "friending one another up" as other personality types. It'll be interesting to check back in on this subject a year from now. In the mean time, check out this entry on his blog: Can the EDA industry truly leverage Social Media? You can follow @DeepakDas on Twitter.

Photo credits (and my thanks to): brillianthue

Further Reading:

An overview of the demo station I manned at DAC showing interoperability between the Cadence InCyte Chip Estimator and Encounter Digital Implementation System
All of my tweets related to the conference

Check back next week for a list of things that caught my attention at DAC. Or consider subscribing to the Digital Implementation blogs so you'll never miss an update.

Question of the Day: What were some of the most memorable conversations you had at DAC this year? I'd love to hear about them.

-Bob Dwyer

Reducing Risk and Improving Productivity with the Cadence InCyte Chip Estimator and EDI System

2009-07-23T13:00:00Z

I'm looking forward to heading out to San Francisco next week for the 46th Design Automation Conference. For my money, it's hard to beat San Francisco as a location for a trade show. Cable cars, Fisherman's Wharf, Alcatraz, San Francisco Giants baseball, Napa/Sonoma Wine Country...what a great part of the country. And DAC itself is a great time in my experience. You get to learn about all the latest things EDA companies are offering, what other chip design companies are working on, and best of all you get to catch up with old friends that you haven't seen in a while.

For my part in the conference, I'll be presenting a demonstration of a new capability we've been working on that bridges the gap between chip estimation and chip implementation. We'll show how the Cadence InCyte Chip Estimator can interface with the Encounter Digital Implementation System to establish a formal and quantified exchange of design data between chip architects and chip implementation leads. This exchange reduces risk by enabling clear communication of design intent and allows each participant in the process to manipulate the design with a level of fidelity appropriate to their role in the project.

Here is an image of the same design with the InCyte Chip Estimator (on the left) and within the Encounter Digital Implementation System (on the right). Each participant works with the design in an environment that has the appropriate level of control and automation for what they need to do, and meaningful design intent exchange occurs as the design is refined:

If you're interesting in learning more about this solution:

Visit the ChipEstimate.com booth for an floor demo
Contact your Cadence salesperson to set up a suite demo

For a complete listing of what Cadence has planned for DAC, visit the Cadence DAC mini-site.

I'll be blogging and posting videos/photos of interesting things during the week. If you're planning on attending DAC and would like to say "hi", drop me a message in the Cadence.com Community -or- follow me on Twitter and send me a message. I'd love to meet you.

Question of the Day: Are you planning on attending DAC this year?

-Bob Dwyer

How To: Create a Self-Contained Testcase in Encounter

2009-07-16T14:00:00Z

In the course of performing design work in Encounter, it frequently becomes desireable to create a self-contained testcase that can be shared with colleagues at other sites, or with Cadence to aid in troubleshooting tool issues. By self-contained, I mean the design data (netlist, floorplan, placement, routing, timing constraint files, etc) and all of the supporting collateral (.libs, LEFs, extraction tech files, etc) within a sub-directory that can be tarred up and uploaded to an ftp site such that someone else can download the design and see the design just as you're seeing it. Because this data is often drawn from various shared locations on the network, symbolic links are used, and pointers often make use of shell/TCL variables, creating a self-contained testcase is frequently quite a bit more complicated than it appears at first glance. But fear not- a new command has been introduced that automates this for us.

In the Encounter Digital Implementation System version 8.1.USR2, a new public command was introduced that automates the testcase creation. It is called: "saveTestcase"

Here's how it works...

Load a design into the tool (either via a .conf file -or- by restoring a design)
Get the design into the desired state (ie,placed or routed)
At the tool prompt, issue the command: "saveTestcase"
By default, a sub-directory in your current run directory will be created called "testcase" which contains the design data and collateral. The pointers in the .conf file and the viewDefinition file (if you're running in MMMC mode will all be resolved to point to these new locations relative to the current directory.
This new directory can be tarred up and E-mailed or ftp'ed to other people you're working with.

Complete usage:

Usage: saveTestcase [-name <testcaseName>]
[-dir <directoryName>]
[-rc] [-merge] [-overwrite] [-gzip]

Enter "man saveTestcase" at the tool prompt in 8.1.USR2 for extended help -or- see the complete documentation on Sourcelink here.

Additional nice features:

saveTestcase can automatically tar and gzip the resulting testcase. Use the "-gzip" option.
In 9.1 the GUI will be updated to include the image shown at the top of this piece. It will be accessible under "File->Save->Testcase..."

Not using 8.1.USR2 yet?

Here are Three Reasons to Move to 8.1
Download it here [select your platform, "then SOC81", then "SOC08.10.002"]
In versions prior to 8.1.USR2 there was is a script available in <install_path>/share/fe/gift/scripts/tcl/ called "userCreateZeroReg.tcl" with a very similar use model and capabilities.

Congratulations to userCreateZeroReg.tcl on "graduating" from the gift scripts to being a productized command. I'm proud of you. :)

Question of the Day: What are some of the scenarios where self-contained testcase creation is useful to you?

-Bob Dwyer

Using A Dual Flop Methodology for Dynamic Power Savings

2009-07-10T13:00:00Z

Imagine this scenario: Your chip is a low power design. You’ve used everything in the book – clock gating, multiple threshold optimization, power shutoff, multiple supply voltages etc. What else can you do to reduce power in your design?

Or, maybe you can’t do power shutoff – the entire device is always on. Maybe you can’t use multiple supply voltages (face it – if you’re already running at 0.8V, how much lower can you go?) But you know you have plenty of random logic, and you know you have to reduce power in your design.

A dual flop methodology could help to furter reduce power in your design. What is a dual flop? It’s basically two flops physically merged into one. Kind of like a multi-bit flop, but in parallel instead of in series. The merged flop will share the same clock pin, but besides that, it’ll have two separate inputs and outputs.

This setup saves dynamic power in two ways: first of all, there is some savings from efficiency by using a common clock pin. In the worst case scenario, the new clock pin will have double the amount of capacitance, resulting in no significant savings, but usually there is some amount of efficiency and the resulting capacitance of the clock pin will not be double the original capacitance of the individual clock pins, but some amount less than that. Therefore some amount of dynamic power will be saved there.

The second way this setup saves dynamic power is in the clock network distribution. For every two flops, instead of the clock network having to route to two individual places, the clock network now only has to reach one location. Therefore, dual flops are more tighly clustered than individual flops, which results in savings on clock distribution net length, and more importantly, the buffers needed to drive the clock distribution network.

So, how much power does dual flop save? It really depends on what kind of design you’re dealing with. For designs with a large portion of random logic, and especially designs where clock power is a significant contributor to total power (e.g. designs with large clock networks or low signal-to-clock switching ratio), using a dual flop methodology will yield better results. Used in the right design category, a dual flops methodology has the potential of saving roughly 10%-20% of total power in the design.

What do you think?

Wei Lii Tan

Flow? What Flow?

2009-07-02T21:30:00Z

For EDA software, it seems that it takes just as much effort to develop a methodology to use the software, as writing the tool itself. Ask any CAD group or design group that has to develop their own methodology and you can quickly gauge the many challenges in building a flow for your favorite EDA tool.

Why is it so hard to build and maintain a working flow? There are many reasons. First of all, EDA tools change. Updates, revisions, bug fixes etc - all these change the way the tool is used, sometimes incrementally, or sometimes in a drastic way. Secondly, every design is unique in at least a couple of ways. Design requirements (whether it's a low power design, or a 32nm design that needs advanced node capabilities, or both) dictate the necessity of steps needed in the design flow.

EDA companies have all tried to create flow wrappers that cater for every design (similar to a makefile system), but there are challenges in that too - with unique design requirements in each design, as well as ever-changing use models, creating an all-encompassing design methodology system is difficult.

One thing that EDI System has done is not to focus on creating a comprehensive flow wrapper, but a set of "Foundation Flows" that act as a baseline for user-customizable flow scripts. These Foundation Flows are based on a specific need, e.g. a Timing Closure Foundation Flow, or Low Power Foundation Flow, and contain a set of commands that are usually used by designers, in the order they are usually done. Foundation flows are available starting EDI System 8.1.

In your design environment today, how is the issue of flows handled? Is there a central group that handles flow-related issues for design groups? Do you use a makefile system? Or do design teams build their own custom flow for each project? Most importantly, do you think flow management should be provided by the tool? Sound off in the comments section!

Wei Lii Tan
Cadence Design Systems

Cadence: Committed to DFM

2009-06-20T01:19:00Z

On June 10, Cadence issued a press release that mentioned “…decreasing the level of investment in the manufacturing side of DFM” as part of restructuring activities. Since that announcement, some in the press and analyst community have published their interpretations of the actions. A few of the published items do not accurately describe the actions that were taken, and we’d like to set the record straight.

Manufacturing-side DFM involves post-tapeout processing that transitions a finished layout into the factory (i.e. for manufacturing). Cadence has successful offerings in this area and will continue to appropriately invest. But in select areas such as mask proximity correction our investment will decrease as we emphasize design-side DFM.

Design-side DFM means seamless incorporation of manufacturing process effects within the design environment – like the Cadence Encounter® Digital Implementation System and Cadence Virtuoso® custom design environment – so designers can implement manufacturing-friendly designs that achieve higher yield and performance while meeting tight design schedules.

Our design-side DFM tools, including Cadence Litho Physical Analyzer (LPA), Cadence Litho Electrical Analyzer (LEA), Cadence Chemical-Mechanical Polishing (CCP) Predictor, and Cadence Pattern Analyzer (CPA), are production proven at multiple technology nodes. The Cadence LPA, for example, was the first tool qualified by TSMC from 90nm through the advanced nodes. The Cadence LEA is the first of its kind in the EDA industry. And the Cadence CCP is the established CMP predictor tool used by most leading foundries and IC manufacturers.

Today most of the top 20 semiconductor companies use Cadence design-side DFM tools. Leading semiconductor companies like TI, Freescale, AMD, Broadcom, Qualcomm, TSMC, Chartered, UMC, NXP, NEC and others have publicly described the successes they have had with our tools and technology in published papers. Cadence continues to develop and integrate DFM technology to address next-generation manufacturing requirements, such as double patterning. We hope this perspective clears up any confusion generated by speculative blogs. Cadence is committed to DFM.

Manoj Chacko