Digital Implementation

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

User Review of The Encounter Foundation Flow

BobD — Mon, 22 Feb 2010 14:00:00 GMT

This is a guest post from John McGehee. John is an independent consultant in Silicon Valley, specializing in EDA application development and design. He blogs about these topics at voom.net. Prior to starting his consulting career, John was an AE at Avanti, Cadence Japan and Daisy Systems Japan. You can follow him on Twitter @JohnMcGehee

In an earlier series of posts, I described techniques that will make your chip design flow easy to use. I subsequently had the pleasure of using a flow that employed most of my favorite techniques—the Cadence Encounter Foundation Flow version 8.1.

The focus of this flow is to get you up and running immediately. Plug in your libraries, netlist, timing constraints, do some floorplanning, create a clock tree specification file, type make, and something comes out the other end. Not a usable chip of course, but something, so you can see what’s next. A flow is executable documentation, and this is your Quick Start Guide.

The Encounter Foundation Flow does not try to be everything to everybody, but rather the portion of the design flow that is common to everybody. It can be difficult to decide how far to go with such a flow, but Cadence engineers Rob Lipsey and Glenn Gullikson knew where to stop. I found the Encounter Foundation Flow to be a good balance between completeness, extensibility, and usability. It contains no confusing, useless features like GUIs, wrappers, and “under the covers” sleight of hand. The best ASIC designers I know use flows architected like this one.

An additional advantage of any standard flow is that it gets all users to operate the tools in the same way. With versatile tools like place and route, there are many ways to accomplish the same thing. Yet such tools are a minefield of bugs and quirks. When every user chooses a different approach, something bad always happens. A standard flow defines a single safe path for users. It frees the tool developers from having to support a needless variety of ways to accomplish one task.

The make/ Semaphore File Directory

Physical designers who are accustomed to using GNU Make will be at home with the Encounter Foundation Flow. The one thing that you need to be aware of is the location of the target semaphore files in the make/ directory. This is specified in the Makefile with the VPATH variable.

While a separate directory for semaphore files initially seems like a good idea, putting them in the make/ directory causes subtle problems. You can eliminate this make/ directory by changing,

VPATH=./make

in the Makefile to:

VPATH=.

If you prefer to keep the make/ semaphore file directory, be careful of the following points:

With the Encounter Foundation Flow, you reset the design flow so that the init target is the most up to date using,
touch make/init
but if you forget the directory name and mistakenly type,
touch init #wrong
the flow forever thinks that only the init target is up to date; every time you run, the flow starts over. I burned up a lot of CPU time until I discovered that the culprit was the ./init file hiding in my working directory.
Similarly, do not forget the directory name when you use the make -t option to update the design flow:
make -t make/place
This can be difficult to remember after becoming accustomed to typing make place.

Suggestions for Improvement

I found several things in Encounter Foundation Flow 8.1.RTM that I think Cadence should consider improving. As noted below, many are in fact already fixed in later versions of the flow.

The Makefile clean target deletes the Subversion version control directory .svn:
```
  clean: rm -rf .??*   # ...
```
Wildcards in the clean target can easily make a mess. This is fixed in the version 8.1.USR2 cleanup target.
The Makefile does not make use of the .PHONY target. This is especially useful for the administrative targets like clean and all:
```
  .PHONY: all clean # ...
```
The Encounter Foundation Flow puts reports in its own RPT/ directory rather than the tool default. For example, I would prefer that Encounter timing reports go in the Encounter default, timingReports/.
Lower case is easier to type, so I would prefer lower case names for the LOG/, RPT/, and DBS/ directories. Users can customize these paths using the vars(rpt_dir) and vars(dbs_dir) variables in the setup.tcl file. The log file directory can be changed using the Makefile variable LOG.
In file SCRIPTS/FLOW/run_route.tcl, line 68, the variable setFillerMode is missing for the non-power domain case, but this is fixed in version 8.1.USR2.

Future Direction

In addition to the fixes mentioned above, Rob and Glenn are still enhancing the flow.

Currently the flow executes Tcl scripts that contain procs and variables. In a future version, the flow can first generate linear scripts with all variable values evaluated and all procs expanded into Encounter commands. Then it executes these scripts with Encounter.

In my flows I avoid generating scripts, because it allows the configuration variables and the scripts to become desynchronized. But Glenn and Rob had some good arguments for doing it this way:

The script stands alone as a record of exactly which commands were executed. To reproduce the step, you (or your AE) need only the starting database and one script file, not the entire flow.
The flow can be easily tested by merely comparing the scripts against golden scripts, without running Encounter. Testability is a key feature of every software project.

To solve the synchronization problem, I encouraged Rob and Glenn to generate each script within the Make target, immediately before it is used. I’m interested to see how this works out. Make sure to send them your feedback, too.

I'd like to thank John for exercising the Foundation Flow and sharing his thoughts with us in this piece. -Bob Dwyer

Three Reasons to Move to EDI System 9.1

BobD — Mon, 01 Feb 2010 16:59:00 GMT

We recently announced the 9.1 version of the Encounter Digital Implementation System. Head over to http://downloads.cadence.com, select your platform and choose EDI91. Notice that in our download system, we’re calling it EDI as opposed to the former SOC to align with a name change from SoC-Encounter to EDI System that occurred in the 8.1 release.

I think customers will be interested in three high-level aspects of 9.1 that lead to one important benefit: getting your job done faster within the tool.

The first area of focus was on raw turnaround time for a typical job that runs through the system. Across a suite of designs that our developers use to test the tool, we’re seeing on average a 2x run-time improvement as compared to 8.1.RTM for multi-corner designs.

The second area of focus is improved quality of results, both in terms of setup time optimization with SI and hold fixing. For example, our hold fixing algorithm is now better able to identify bottlenecks and efficiently repair hold violations without increasing area- especially locally.

The third area is in terms of correlation to signoff. The parasitic extraction engine used during post-route optimization aligns more precisely with signoff extraction engines without the need for scale factors. This leads to fewer iterations required to meet timing closure according to signoff timing.

I think these items together, along with other enhancements make 9.1 a release you’ll want to check out.

Further Reading:

For more information about EDI System 9.1, check out What’s New in EDI 9.1 (Cadence Online Support login required)
Here is a link to the announcement of EDI 9.1

-Bob Dwyer

Encounter Screencast: Editing Wires More Quickly With Bindkeys

BobD — Thu, 21 Jan 2010 14:00:00 GMT

The Encounter Digital Implementation System offers interactive wire editing capabilities via the Wire Editor. This is one part of the tool that becomes much easier to use with the help of a few bindkeys. In particular, I find the "Shift-S" bindkey useful in conjunction with "Auto Query" mode becuase it provides a way to populate the Edit Route form with net name, layer, width, and spacing depending on the object you're currently hovering over. Have a look at this short video to see this functionality in action:

(if the video fails to embed, click HERE)

Summarizing what's shown in the video with text:

Select the Edit Wire tool
Click the "Q" button at the bottom of the GUI to enter Auto Query mode
Make sure instance pins are Visible (by default they are not)
Bring up the Edit Route form with the "e" key
With the mouse, over over the pin you'd like to route
Enter "Shift-S" to auto-populate the Edit Route form with the net, layer, and width of the pin you're hoving over

It's worth noting that by default, the wire editor creates wires that are the default width for that layer. To create routes of arbitrary width, you'll need to click the "Force Special (to allow arbitrary widths)" checkbox on the Edit Route form's Nets tab.

For more information on bindkeys related to the Wire Editor have a look at this chapter in the Encounter User's Guide and click on "Using Keyboard Shortcuts".

Hope this is helpful.
-Bob Dwyer

Question of the Day: Are there any other bindkeys in the system you've found particularly helpful?

Sometimes It's The Little Things: Working With Square Brackets in Encounter

BobD — Sat, 16 Jan 2010 07:03:00 GMT

Good news! A long-standing source of irritation for Encounter users has been addressed in our 8.1.USR1 release. You might not have noticed it if you've grown accustomed to backslash-escaping square brackets in object names.

For example:
selectNet DTMF_INST/RESULTS_CONV_INST/nbus_544[0]

In 7.1, if you tried to select a net with this syntax you'd get the following as the TCL interpreter treated the contents within the square bracket as an executable command:
encounter 1> selectNet DTMF_INST/RESULTS_CONV_INST/nbus_544[0]
invalid command name "0"

As a workaround, you needed to either escape each square bracket -or- enclose the entire string within squiggly braces:
encounter 2> selectNet DTMF_INST/RESULTS_CONV_INST/nbus_544\[0\]
encounter 3> selectNet {DTMF_INST/RESULTS_CONV_INST/nbus_544[0]}

This was cumbersome to work with, especially for users who spend a lot of time querying the database and timing from the command line. In 8.1.USR1 the tool has been enhanced to handle square brackets automatically without needing to escape them. When the contents within square braces are anything other than an Encounter command, they're treated as bus bits. The nice thing about the way this has been implemented, is that it applies to all commands in the system rather than on a command-by-command basis.

In other words, any of the following also work:
report_timing -through DTMF_INST/RESULTS_CONV_INST/nbus_544[0]
dbGet top.nets.name DTMF_INST/RESULTS_CONV_INST/nbus_544[0]
get_nets DTMF_INST/RESULTS_CONV_INST/nbus_544[0]

I hope this little enhancement is useful.

Question of the Day:
Is there something similar to this- a little thing that's bothering you about Encounter you'd like us to improve? Let us know in the comments area and we'll see what we can do.

-Bob Dwyer

Design Signoff Begins In Implementation

PeteMc — Wed, 06 Jan 2010 14:00:00 GMT

As an ex-design engineer now working in EDA, I am often privileged to see advanced design methodologies from many of my customers. I would like to reflect on the recent trends that I am seeing around signoff analysis for digital ASIC designs.

For the majority of ASIC designs, signoff analysis includes executing parasitic extraction that feeds static timing analysis, signal integrity analysis and power rail IR drop analysis. Most often this is standalone execution using a separate set of tools than those used in design, and the obvious goal of this analysis is to ensure good quality silicon.

What is interesting is that, today, a robust ASIC design methodology must employ the same signoff analysis engines within the design flow, to ensuring that timing is consistently closed and IR drop is consistently managed. This is certainly the case with Cadence’s Encounter Digital Implementation System (aka EDI System), which can utilize all of the signoff engines (parasitic extraction, timing, SI and IR drop) within the design platform.

The use of signoff engines within the design environment opens up an interesting question ... if I am using signoff quality engines within my design flow, is there significant value in performing separate, standalone signoff analysis prior to tapeout?

The answer for an increasing number of my customers is no … separate signoff analysis does not catch any additional and significant timing, SI or IR drop problems. These customers chose to signoff from within the design platform and save the expense of purchasing and maintaining separate standalone signoff products.

So, I have an open question to the design community … what are your thoughts on separate signoff analysis?

Pete

Trying to Figure Out Social Media? Ron Ploof Says "Read This First"

BobD — Tue, 05 Jan 2010 14:00:00 GMT

Left to Right: Ron Ploof, Bob Dwyer
Photo Credit: brillianthue

"As a New Media evangelist...I've been able to categorize those reactions into three different personality types: The 'Get-Its,' the 'Traditionals,' and my favorite group, those 'Running with Scissors'" -Ron Ploof

When I was out in California recently, I had a chance to sit down with author Ron Ploof. Ron has worked at Cadence and Synopsys in the past, and continues to consult with Synopsys. Given his background and the fact that he just released a book on New Media (which contains targeted examples of its application within the electronic design community) I thought it would be interesting to capture the highlights of our conversation.

Q: Tell us a little about your background, and how you became passionate enough about New Media to write a book about it

Ron Ploof: Although my degree is in electrical engineering and I've been in the EDA trenches for almost 20 years, I've always been drawn to new communications technologies. I was a strong proponent of the Web 1.0 transition and it is a natural fit for me to be part of the Web 2.0 transition.

I wrote the book because I found too many people getting wrapped up in the wrong things when the subject of New Media came up. They talk too much about the technologies (Twitter, Facebook, blogs, etc...) and not about what makes them different than any other communications vehicle that companies use today. Corporate communications have historically been built on controlling the message and controlling the brand, which worked swimmingly when it was expensive to deliver those messages. But today, with the cost of distribution too small to measure, the game has changed. I wrote "Read This First" to discuss these fundamental changes.

Q: Of all the books out there on New Media, why is “Read This First” a good place to start? What kind of people would benefit most from reading the book? Who did you write it for?

Ron: There are many New Media books out there that fall into two categories: Channels and Philosophy. Channel books teach you about the mechanics of specific tools like Twitter or Facebook. Seminal books like "Trust Agents," "The New Rules of Marketing and PR," and "The New Influencers" discuss the philosophical changes companies must make in order to create content that best fits within those channels. But none of the books discuss the management support and understanding required to properly adopt New Media, so I wrote Read This First as a foundational piece for executives to make important decisions.

Q: When we were talking, one of the things that intrigued me most was the question about how much organizations should trust their employees to “do the right thing” with New Media. In the context of participating in forums, blogging, and tweeting- what should companies and employees be thinking about to effectively leverage New Media without doing harm to the company’s reputation?

Ron: Because traditional communicators are so focussed on controlling the corporate message and the brand, they've come to this silly belief that if everyone in the organization is saying the same thing, then the customer will finally "get the message." And so they only authorize designated people to talk for the company.

But who is working with customers day in and day out? Marketing? PR? No. In EDA, it's applications engineers, customer support, and the sales team. Instead of trying to hammer customers with cute catch-phrases that some professional communicator came up with over margaritas at last month's offsite, these employees are helping customers get chips out the door--which is what customers want in the first place.

The only difference is that these conversations can now happen online as opposed to on the telephone, in person, or in front of a trade show audience. These employees are already trained in what they can and can't do offline, so if a company is worried about what they'll say online, offer additional training. Add a section in the employee handbook. Write a Social Media Policy. Then, if an employees violates that policy, it's management's job to assess the situation and take appropriate action.

The upside of online customer conversations outweighs the downside.

Q: The book talks a lot about transparency. Could you share the anecdote from the book involving Wikipedia edits, the Common Power Format, and transparency? I don’t mean to be controversial in raising this, but I thought it was a really good example that hits close to home in EDA and is something we can all learn from.

Ron: First of all, under full disclosure, I used to work for Synopsys as a full-time employee and am presently under contract with them as a consultant.

The story you are referencing involves someone vandalizing Cadence's Common Power Format entry in Wikipedia. The vandal thought that they were under the cloak of anonymity, but Wikipedia doesn't work that way. It logs every edit, including the IP address of who made that edit, and stores that information forever. Unfortunately, by running that IP address through the whois.net, it was found that the edit came through someone logged into Synopsys's network.

When this issue was brought to Synopsys's management, they were mortified. Independently of whether or not it happened online or offline, the act was a violation of Synopsy's code of employee conduct. It was also a violation of the company's Social Media Policy that stipulated that online activity must be done under an employee's real name. But rather than shoving the embarrassing issue under the rug, Synopsys did the right thing by drawing attention to it through its internal employee communications website. In addition, the company also updated its Social Media Policy to include a special line item to address this specific issue.

And as a final note, before any EDA vendors point accusatory fingers toward Synopsys, be careful. A few keystrokes into a Google search reveals similar shenanigans instigated by other EDA vendors. The question is, does their upper management even know?

Q: When I finished reading the book, I was motivated to participate even more in New Media as part of my job at Cadence. What’s the next thing you’d like readers to do after they finish the book? What’s the call to action?

Ron: Use the tools. The only way to understand the nuances of New Media is to engage with it. Just because you read a book by Dr. Spock, it doesn't mean that you know what it's like to be a parent. The only way to do so is to have a child of your own. Use the tools and I guarantee you'll learn something valuable.

What to do Next:

Visit the Web page for ”Read This First” (and check out free audio recordings of the book)
Follow Ron on Twitter: @RonPloofVisit (and subscribe to)
Ron’s blog: RonAmok.com

Question of the Day:
What you think of New Media’s role in the electronic design community? Do confidentiality requirements limit its effectiveness? Or are companies smart to leverage New Media in order to build closer relationships with the companies they interact with?

I'd like to thank Ron for taking the time to share his thoughts with us.

-Bob Dwyer

Encounter How-To: Selecting Objects By Pointer With dbGet And dbSelectObj

BobD — Wed, 16 Dec 2009 17:00:00 GMT

I just got back from a trip to California where I met with a couple of customers and presented database access with dbGet in the Encounter Digital Implementation System (EDI for short). I took notes on the questions that came up- in particular those common between both sets of users. One item in particular that was helpful was understanding how to select objects by pointer with dbGet. In this post, I'll explain the basics of object selection by type with existing mechanisms in Encounter, and then show how you would use dbSelectObj in conjunction with dbGet to select objects by criteria and pointer.

Say for example, you'd like to select all of the instances in the design that have the cell master "BUFX1". How could we do that?

First, we naturally like to use the most polished, productized piece of functionality available that does what we're looking for. There is a nice piece of functionality that can select many different objects by name, type and criteria under: Edit->Find/Select Object... If we ask it to select all instances whose "Cell" Matches "BUFX1" it will find, display, and select 11 instances in my design:

If we look at our .cmd file (which logs the commands executed at the command line -or- via GUI actions) we see:

selectObjByProp Instance <Cell>Match<BUFX1>

We could certainly use this command to select a number of objects by type, and this is a useful utility. But invariably, our requirements are become more complex than what the utility supports. Say we want to find and select all the hard macros in the design with an area greater than some amount so we can set them FIXED? How would we do that?

This is where db access can be useful. In EDI, dbGet provides a simple but powerful way to probe the database. We can use it to find objects based on a number of criteria. For example, if we wanted to perform the same action as we did above with the Find/Select Object utility using dbGet we'd do it like this:

dbGet -p2 top.insts.cell.name BUFX1
0x2aa72affb8 0x2aa72b0050 0x2aa72b00e8 ... (truncated, but 11 pointers would be returned)

This would return a list of all the pointers to instances in the design that are of cell type "BUFX1". BUFX1 is used as a filter in this case, and we use "-p2" to instruct dbGet to "walk" 2 levels back up the structure that was traversed to get inst pointers. Let's say that we wanted to select all of those instances- how would we do that? One way to do this is get a list of the inst *names* (as opposed to pointers):

dbGet [dbGet -p2 top.insts.cell.name BUFX1].name
DTMF_INST/TDSP_CORE_INST/i_10181 DTMF_INST/TDSP_CORE_INST/i_10155 DTMF_INST/TDSP_CORE_INST/i_10084 ...

...and then select them using selectInst within a foreach loop:

foreach instName [dbGet [dbGet -p2 top.insts.cell.name BUFX1].name] {
selectInst $instName
}
->This would find -and- select all of these instances, similarly as Find/Select Object did

But what if the object you're trying to select isn't easily identified by name because it's a floorplanning object? Like placement obstructions for example? For things like this, it is often more conventient (or even mandatory) to select by pointer. We can use the dbSelectObj command for this:

foreach pBlkg [dbGet top.fplan.pBlkgs] {
dbSelectObj $pBlkg
}

For our BUFX1 example above, it would look like this (we select by pointer instead of by name):

foreach instPtr [dbGet -p2 top.insts.cell.name BUFX1] {
dbSelectObj $instPtr
}

To make things easier and not require a foreach loop, dbSelectObj is being enhanced to operate on lists of pointers. In 9.1.USR1 (not released yet) we'll be able to use dbSelect Obj as follows:

dbSelectObj [dbGet top.fplan.pBlkgs]

As you work with dbGet, I think you'll find lots of situations where by selecting by pointer is more sensible than selected by name.

Further Reading:

Hope this is helpful,
Bob Dwyer

Find, Fix And Learn With Cadence Online Support

BobD — Thu, 05 Nov 2009 18:00:00 GMT

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

Rich Owen — Tue, 03 Nov 2009 17:44:00 GMT

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"

BobD — Fri, 30 Oct 2009 16:00:00 GMT

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

BobD — Fri, 23 Oct 2009 13:00:00 GMT

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

Rich Owen — Fri, 09 Oct 2009 13:00:00 GMT

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

soheilm1 — Tue, 06 Oct 2009 18:48:00 GMT

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