https://community.cadence.com/search?q=type%3Ablog%20user%3A2907&sort=date%20desc&Redirected=trueen-USTelligent Community 12en-usnoSearch results for 'type:blog user:2907'https://community.cadence.com/cadence_blogs_8/b/di/posts/the-case-for-the-tiny-testcaseFri, 16 Nov 2012 11:56:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1316707BobD/cadence_blogs_8/b/di/posts/the-case-for-the-tiny-testcase1I often joke with customers that, although I realize they have to work on large designs, I do my best work on designs with just 2 or 3 instances. That's because I'm often trying to replicate an issue they've observed on their design and I'm attempting to reproduce that behavior in a smaller circuit. I've found tiny testcases to be extremely efficient ways to gain quick clarity on tool behaviors which can then be more effectively applied to the real design. But it's not just having a tiny testcase that's most useful. It's the act of creating the small testcase where most insight is gained. But it's not always easy to create a tiny testcase. Do you know how to write a syntactically correct gate-level Verilog netlist from scratch with a text editor? Do you know how to contrive complicated timing scenarios? Do you know to modify .lib/LEFs to replicate the things likely present in a design in a smaller setting? These are non-trivial things for someone who works in many different aspects of a design flow as designers are tasked with understanding an ever-increasing breadth of tools. I recall a quote from a colleague of mine, Thad McCracken ( interview here ), a few years ago. We were working on a benchmark and were having a hard time reproducing some of the issues we were observing in a small testcase. He said " If we can't reproduce it in a small testcase it tells me we fundamentally don't understand the problem well enough. " Isn't that the truth of it? With the exception of run-time/memory related issues, nearly every issue we run into can be replicated in a tiny representative testcase -- but doing so can be very difficult. Customers often joke with me that the oldest tricks in the EDA Applications Engineering books are (1) to ask if you're using the latest tool version and (2) ask for a testcase. Sure it's easy to get a self-contained testcase with Encounter (see the link for saveTestcase at the end of this post). But a better question to ask is, " Do you have any hunches on the likely circumstances causing the issue? " Tiny testcases can be powerful in the user community as well. Some of the most disciplined and effective project teams and CAD groups I've worked with relentlessly stress the tool at the onset of a project in ways they're going to need it to perform during crunch time. Sure, some things only come to light in the context of real designs. But creating tiny testcases can efficiently flush out the gaps between project requirements and tool capabilities to give everyone a chance to find ways to get the software to do what it needs to do to meet project requirements. In our busy schedules we often feel like we don't have time to create small testcases to triage a situation. And indeed, sometimes we just need to send a testcase in to R&D for resolution. But next time you run into an issue I'd encourage you to consider whether a tiny testcase might shed more light on the situation. To borrow a line from Paul Cunningham : " Sometimes we need to slow down to speed up. " -Bob Dwyer Related Reading: The Case for Robust Database Access Creating a testcase with Encounter's "saveTestcase" commandhttps://community.cadence.com/cadence_blogs_8/b/di/posts/how-to-bring-up-encounter-quot-man-quot-pages-from-a-unix-promptWed, 01 Aug 2012 14:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1313536BobD/cadence_blogs_8/b/di/posts/how-to-bring-up-encounter-quot-man-quot-pages-from-a-unix-prompt1Okay, this one is too cool not to share. The other day a customer and I were trying to understand a tool behavior better so we did what we all do in desperate times: We read the documentation. As straightforward as "reading the documentation" would seem, I bet no two users of the system interact with documentation the same way. Some people like to bring up "cdnshelp" at the UNIX prompt. Some like to download the .pdfs from the install tree. Others like to use CommandGetIt through a web browser. Some click the "Help" button within the tool. Others like to read them through https://support.cadence.com/ For most things, I use " help " at the Encounter prompt. And " man " for an extended description of what each option does along with some examples. So when the designer I was working with saw me launching Encounter to bring up the man page for a command, he asked if there is a way to do that from the UNIX prompt without launching the tool. I didn't know how to do that, but there is a way. Here's how... The short answer is to add the path to the Encounter man pages to your MANPATH environment variable. The man pages reside in the Encounter installation tree under /share/fe/man - for example: UNIX> which encounter /icd/flow/EDI/EDI111/latest.USR1.lnx86/lnx86 /bin/encounter UNIX> setenv MANPATH /icd/flow/EDI/EDI111/latest.USR1.lnx86/lnx86 /share/fe/man UNIX> man placeDesign This should bring up the man page for placeDesign without needing to launch Encounter. However, you probably don't want to lose access to regular UNIX commands, so you'll want to append the Encounter path to your existing MANPATH. How to do this depends on the shell you use but this works for me: setenv MANPATH ${MANPATH}:/icd/flow/EDI/EDI111/latest.USR1.lnx86/lnx86/share/fe/man Want to get even fancier? If you've already got the encounter executable in your path you can make use of the " cds_root " utility to set your MANPATH. This way your MANPATH will always update to the latest version of Encounter you're pointing to. Slick! setenv MANPATH ${MANPATH}:`cds_root encounter`/share/fe/man Another approach would be to create an alias to a separate man command for Encounter: UNIX> alias eman 'man -M `cds_root encounter`/share/fe/man' UNIX> eman placeDesign Hope this is helpful! And thanks to my colleagues Tim, Benton, and Bupendra for pointing out how to do this. -Bob Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/10-tipsFri, 27 Jul 2012 14:26:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1313357BobD/cadence_blogs_8/b/di/posts/10-tips3In looking over the shoulders of Encounter users over the years I've found there's a bunch of little tips and tricks I use to make interacting with the tool a little easier that aren't necessarily immediately obvious. Here are some of the more common ones I used this week: When navigating an Encounter log file in a text editor, search forward for " ". Each time a command is executed it's embedded in the log file, for example: " optDesign -preCTS ". This makes it easier to understand what was executed and what resulted. Use " getLogFileName " to determine which log file goes with which Encounter session. Use " win " at the Encounter prompt to raise the window of the session associated with the Encounter console. Doesn't work with all window managers but when it does I find this quite useful. Use " dbWireCleanup " to delete all of the signal routes in the design (trialRoute or NanoRoute). See also " editDelete -type Signal ". Use " deleteAllPowerPreroutes " to delete all of the power routing in a design. Sure you could " editDelete -type Special " but what fun is that? Use " encounter -init design.enc " to restore a design from the UNIX prompt. Load designs with " source design.enc " at the Encounter prompt instead of using restoreDesign. That way you don't need to use a pulldown menu and you don't need to tell the tool the top cell name since it's embedded within the .enc file. Use emacs-style shortcuts like "ctrl-a", "ctrl-e", and "ctrl-k" to position the cursor and strike text at the Encounter console. Use " dbGet selected.?? " to query physical information about an object. Use " report_property [get_nets ] " to query timing information about an object. Question of the Day: What little tips and tricks have you found useful in Encounter over the years? Let us know in the comments. -Bob Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/capturing-and-processing-encounter-console-output-with-quot-redirect-quotMon, 23 Jul 2012 12:08:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1313169BobD/cadence_blogs_8/b/di/posts/capturing-and-processing-encounter-console-output-with-quot-redirect-quot2In my last post I wrote about writing more compact db access scripts with dbGet's expression-based matching . We found all of the high fanout nets in the design which weren't clock nets: dbGet [dbGet top.nets {.numInputTerms > 16 && .isClock == 0}].name This writes the name of each net to the console. But how would we write those nets to a file? Say, for example, if we wanted to call optDesign -selectedNets on them? optDesign expects a file with a list of net names, one per line. How could we create that file? We could use the redirect command along with some clever scripting. More on that in a moment, but let's talk about redirect first. The Basics The redirect command as described here is available starting in release EDI release 11.1 (EDI stands for Encounter Digital Implementation System). In its simplest form redirect takes the output that's written to the Encounter console and writes it to a file. This is useful when you want to process that output programatically and do something based on what's found in that file. Take for example the checkPinAssignment command. It writes output like this: encounter 1> checkPinAssignment Start Checking pins of top cell: [top] **WARN: (ENCPTN-562): Pin [in] is [PLACED] at location ( 0.330, 50.120 4 ) is NOT ON THE DESIGN BOUNDARY. Summary report for top level: [top] Total Pads : 0 Total Pins : 3 Legally Assigned Pins : 2 Illegally Assigned Pins : 0 Unplaced Pins : 0 Constant/Spl Net Pins : 0 Internal Pins : 1 Legally Assigned Feedthrough Pins : 0 Illegally Assigned Feedthrough Pins: 0 End of Summary report End Checking pins of top cell: [top] The command doesn't return anything (ie, if you " set x checkPinAssignment" , "x" wouldn't have a value) so if we want to query whether checkPinAssignment found any violations -or- check which specific pins were in violation we could do it by redirecting to a file and parsing the output. It's not necessarily pretty but sometimes you've got to do it. Here's how it works: encounter 1> redirect checkPinAssignment.out checkPinAssignment **Info: stdout is directed to file 'checkPinAssignment.out'... Now, you could iterate through each line in checkPinAssignment.out and regexp for "WARN", find a pin name and operate on it in some way. If the command you want to execute contains options, embed the options in curly brackets: encounter 1> redirect queryPlaceDensity.out {queryPlaceDensity -userSpecified} **Info: stdout is directed to file 'queryPlaceDensity.out'... Intermediate We've talked before about writing to and reading from a file . I've got a couple more tips that extend on that idea and make things more compact. First, check out the dbForEachFileLine command. It essentially does the same thing as: set infile [open checkPinAssignment.out "r"] while {[gets $infile line] >= 0} { if {[regexp WARN $line]} { Puts "$line" } } close $infile If you're like me and have trouble remembering the infile/open/while/gets/close business try dbForEachFileLine instead: dbForEachFileLine checkPinAssignment.out line { if {[regexp WARN $line]} { Puts "$line" } } But we can get even fancier with this approach, and avoid writing to a file altogether with redirect's -variable option: redirect x checkPinAssignment -variable set lines [split $x \n] foreach line $lines { if {[regexp WARN $line]} { Puts "$line" } } Extra Credit Back to the original puzzler I mentioned previously. How could we write to a file, one net per line, all of the nets with fanout greater than "n" so we could pass it to a command like " optDesign -selectNets "? It's a little tricky, and probably exceedingly compound to be honest, but there is a way: encounter 18> redirect high_fanout.nets {puts "[join [split [dbGet [dbGet top.nets {.numInputTerms > 16 && .isClock == 0}].name]] \n]"} **Info: stdout is directed to file 'high_fanout.nets'... encounter 19> more high_fanout.nets scan_enI DTMF_INST/TDSP_CORE_INST/MPY_32_INST/n_7295 DTMF_INST/TDSP_CORE_INST/MPY_32_INST/n_6735 {DTMF_INST/TDSP_CORE_INST/MPY_32_INST/ab_a[15]} {DTMF_INST/TDSP_CORE_INST/MPY_32_INST/ab_b[15]} Pretty cool! Here's the full usage for the redirect command: encounter 1> help redirect Usage: redirect [-help] [ ] [ ] [-tee] [-stdin | -append | -variable ] [-stderr | -stdin ] -help # Prints out the command usage # file name or variable name, for outputs to go # (string, optional) # command to execute (string, optional) -append # append stdout/stderr to file or variable # (bool, optional) -stderr # redirect stderr also (bool, optional) -stdin # redirect stdin (bool, optional) -tee # redirect output to both screen and file or # variable (bool, optional) -variable # redirect to a Tcl variable (bool, optional) I hope there's a useful nugget or two in here. Question of the Day: Any tips or tricks you'd like to share about reading from/writing to a file, capturing output as a variable, or redirecting it to a file? -Bob Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/writing-more-compact-encounter-scripts-with-dbget-expressionsWed, 30 May 2012 13:36:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1311462BobD/cadence_blogs_8/b/di/posts/writing-more-compact-encounter-scripts-with-dbget-expressions5Querying the Encounter database with dbGet is typically pretty concise to begin with. But you might not be aware of its support for expression-based matching, which enables even more compact scripting. Let's take a very simple but common scripting challenge: Finding all of the high fanout nets in the design. Then let's take this a little further. How would we write a script to find all nets with fanout greater than "n" which are not clock nets? Historically we'd do this by iterating through all of the nets in the design, checking whether their fanout is greater than "n", checking whether it is marked as a clock net, and if so add it to a list of nets that meet the criteria. This would take about a half-dozen lines of code. But by using dbGet's support for expression-based matching, we can make this script more compact. Here's how it works. First, let's look at how we'd write this script without expressions: set high_fanout_nets {} foreach net [dbGet top.nets] { if {[dbGet $net.numInputTerms] > 32} { if {![dbGet $net.isClock]} { lappend high_fanout_nets $net } } } return $high_fanout_nets Here's how we'd write the same functionality using dbGet's expression-based matching: encounter 1> dbGet top.nets {.numInputTerms > 32 && .isClock == 0} Much more compact, right? So here's how it works, step by step. The attribute ".numInputTerms" gives us, effectively, the fanout for each net. If we were to query that attribute for each net we'd get a list of numbers representing the fanout of each net in the design: encounter 2> dbGet top.nets.numInputTerms 5 5 1 16 32 32 16 33 19 17 18 21 20 21 20 20 71 17 17 8 16 16 32 16 We more commonly use "simple" matching to find things we're looking for like object names, and testing for 1's and 0's. And we could certainly do that with the .numInputTerms attribute: encounter 3> dbGet top.nets.numInputTerms 32 32 32 32 32 32 32 32 32 And if we wanted to get the pointers to those nets we could do it like this: encounter 4> dbGet top.nets.numInputTerms 32 -p 0x2aaab4252f38 0x2aaab20acbe8 0x2aaab20acf30 0x2aaab215fc88 0x2aaab2160078 0x2aaab21faa00 0x2aaab21faca0 0x2aaab21fcab8 And if we wanted to get their names we could do it like this: encounter 5> dbGet [dbGet top.nets.numInputTerms 32 -p].name DTMF_INST/TDSP_CORE_INST/ALU_32_INST/n_3062 DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/n_896 {DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/nbus_426[0]} DTMF_INST/TDSP_CORE_INST/TDSP_CORE_GLUE_INST/n_1213 DTMF_INST/TDSP_CORE_INST/TDSP_CORE_GLUE_INST/n_1357 DTMF_INST/RESULTS_CONV_INST/n_2516 DTMF_INST/RESULTS_CONV_INST/n_2521 DTMF_INST/RESULTS_CONV_INST/n_2512 But if we want to get more sophisticated we can use dbGet expression matching. The first thing to notice is the unique syntax these expressions use. If we want to do the same as we did a couple examples back -- ie, get the pointers to all nets with a fanout of 32 -- here's how we do it with expression matching: encounter 6> dbGet top.nets {.numInputTerms == 32} 0x2aaab4252f38 0x2aaab20acbe8 0x2aaab20acf30 0x2aaab215fc88 0x2aaab2160078 0x2aaab21faa00 0x2aaab21faca0 0x2aaab21fcab8 Notice that we select the attribute to match on with ".numInputTerms", then the criteria ("==" in this case), then the value. And we wrap it all in "{}". Note also that dbGet automatically returns pointers in this mode and doesn't require a "-p". From there we can make it more complex, with a greater than rather than equal: encounter 7> dbGet top.nets {.numInputTerms > 32} 0x2aaab3c5c928 0x2aaab3c5c9d0 0x2aaab3cf7898 0x2aaab3cf8c48 0x2aaab40e5890 0x2aaab42533d0 0x2aaab4253a60 0x2aaab44474b0 0x2aaab20ad080 0x2aaab20adc38 0x2aaab20c4180 0x2aaab20c44c8 0x2aaab21fb288 0x2aaab21fbfa8 Or combine two expressions to match the nets with fanout greater than "n" which are not marked as clock nets: encounter 8> dbGet top.nets {.numInputTerms > 32 && .isClock == 0} 0x2aaab3c5c928 0x2aaab3c5c9d0 0x2aaab40e5890 0x2aaab42533d0 0x2aaab4253a60 0x2aaab44474b0 0x2aaab20ad080 0x2aaab20adc38 0x2aaab20c4180 0x2aaab20c44c8 0x2aaab21fb288 0x2aaab21fbfa8 If we wanted to get the names of these nets we could wrap it within another call to dbGet: encounter 9> dbGet [dbGet top.nets {.numInputTerms > 32 && .isClock == 0}].name test_modeI scan_enI {DTMF_INST/TDSP_CORE_INST/alu_cmd[1]} DTMF_INST/TDSP_CORE_INST/ALU_32_INST/n_1716 DTMF_INST/TDSP_CORE_INST/ALU_32_INST/n_1738 DTMF_INST/TDSP_CORE_INST/MPY_32_INST/n_268 {DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/nbus_440[0]} DTMF_INST/TDSP_CORE_INST/EXECUTE_INST/n_4221 DTMF_INST/TDSP_CORE_INST/DECODE_INST/n_4475 DTMF_INST/TDSP_CORE_INST/DECODE_INST/n_181 DTMF_INST/RESULTS_CONV_INST/n_2509 DTMF_INST/RESULTS_CONV_INST/n_6011 I hope this is helpful in making your scripting within Encounter more compact. Check back next time and I'll show how to write these nets to a file, one net name per line by using redirect and a couple of tricks. I'd love it if you subscribed to the Cadence Digital Implementation blogs for notification of new posts. Question of the Day: Have you found cases where dbGet's expression based matching is particularly useful? -Bob Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/collaboration-concurrency-and-convergence-cdnlive-silicon-valley-2012Mon, 19 Mar 2012 18:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1309056BobD/cadence_blogs_8/b/di/posts/collaboration-concurrency-and-convergence-cdnlive-silicon-valley-20120I was out in San Jose last week for CDNLive! Silicon Valley 2012 -- our US user's group conference. I feel like we've been on a good run with this conference during the past few years. I'm seeing users return to present papers year after year. And each year we seem to have new users who are inspired to share what they've been working on at a future conference. Here are three themes I noticed at this year's conference: Collaboration The conference is all about collaboration -- a theme well represented in the keynote speeches. Rick Cassidy from TSMC said that "deep partnership with folks like Cadence sits at the heart of what we need to do." Furthermore, in remarks directed at atttendees, he said that "we (TSMC) will not compete with you." Tom Lantzsch from ARM said "collaboration and partnership is probably the most critical element for our success." And Cadence CEO Lip-Bu Tan (right) said "We need all the key partners to collaborate with us, from the foundry partners to the IP partners all the way to the software developers." (See listings of blog posts on these keynote speeches at the end of this post). This idea of collaboration isn't new in the IC design community. But I appreciate how the guys at the top reinforced this message. It set the tone for the user papers which followed the keynotes. And for informal conversations throughout the two day conference. Personally, this resonated with me because I believe that every interaction with a customer is a chance to improve our solutions, and that if we work together we can achieve great things. Concurrency Mobile computing was a common thread through each of the keynotes. Mobile devices present unique challenges to the digital designer: Would you like high performance or low power? Yes is the answer. Deliverying high performance low power design requires breakthrough concurrent design capabilities.Tom Lantzsch from ARM described how a design team implementing one of their cores pushed performance while reducing power. The final gains that enabled their objectives to be achieved came by leveraging Cadence's Clock-Concurrent Optimization (CCOpt). By concurrently optimizing clock and data signals, CCOpt is able to maximize performance while minizing power consumption. More on CCOpt in this interview with Paul Cunningham -- and more to come in future blog posts. I co-presented a paper with Netronome at this year's conference on the topic. Convergence Lantzsch revealed that ARM is looking beyond mobile computing and is pursuing new opportunities in the server, home entertainment, and automotive marketplaces. A few years ago, he cataloged the number of devices in his home with IP addresses and found 23. He re-assessed the count recently and found that the number of devices actually went down a bit in recent years even though a number of new devices were added. The reason for this: Convergence in the number of functions each device performs. As we look around and see multiple MP3 players, smartphones, and tablets in our homes -- whereas we used to have one or two shared desktop computers -- it's striking how personal this technology has become. The devices have certainly increased the number of functions they perform (MP3 player, GPS, e-reader, and more) but a family has more copies of each device than ever before. The changes we've seen in personal communications devices are just the beginning. As these changes take place in home entertainment and automotive it will be a fascinating space to watch. We see convergence in the digital implementation space as well. Multiple steps are collapsed into single steps within the Encounter Digital Implementation System each release. Concurrent clock and data. Concurrent base and signal integrity delay. Just as we need to mutli-task as engineers, so do the tools we use to get our jobs done. My favorite part of CDNLive! is creating connections. There are connections between users working with similar functionality in our tools. And there are connections with the developers and product engineers responsible for architecting and improving the tools in areas our customers interact with. I'd love it if you subscribed to our Digital Implementation Blogs to be informed of new posts. Bob Dwyer Photo by Joe Hupcey III Blog posts on CDNLive! keynote speeches: CDNLive! - Lip-Bu Tan Keynote Cites Semiconductor Growth Drivers TSMC CDNLive! Keynote - "We Can Beat Moore's Law" CDNLive! Keynote - New Horizons for ARM based SoCshttps://community.cadence.com/cadence_blogs_8/b/di/posts/cdnlive-silicon-valley-2012-abstracts-due-november-11th-2011Wed, 02 Nov 2011 17:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1304960BobD/cadence_blogs_8/b/di/posts/cdnlive-silicon-valley-2012-abstracts-due-november-11th-20110The 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/encounter-quick-tip-dimming-the-display-with-f12Fri, 30 Sep 2011 14:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1301373BobD/cadence_blogs_8/b/di/posts/encounter-quick-tip-dimming-the-display-with-f121I 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/encounter-quick-tip-finding-available-cell-masters-with-dbgetWed, 28 Sep 2011 16:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1301314BobD/cadence_blogs_8/b/di/posts/encounter-quick-tip-finding-available-cell-masters-with-dbget0When 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/tab-completion-with-encounter-s-dbget-command-smarter-than-you-might-thinkThu, 19 May 2011 16:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1277206BobD/cadence_blogs_8/b/di/posts/tab-completion-with-encounter-s-dbget-command-smarter-than-you-might-think4If 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. ...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 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 inserts a trailing space: encounter 3> dbGet top.insts.n encounter 3> dbGet top.insts.name dbGet selected. 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. 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/encounter-quick-tip-how-to-repair-command-line-navigation-when-launching-via-bsubTue, 12 Apr 2011 14:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1267495BobD/cadence_blogs_8/b/di/posts/encounter-quick-tip-how-to-repair-command-line-navigation-when-launching-via-bsub3When 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/encounter-puzzler-solution-renaming-a-net-logicallyWed, 09 Mar 2011 18:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1260745BobD/cadence_blogs_8/b/di/posts/encounter-puzzler-solution-renaming-a-net-logically6Once 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: 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 / : 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 | - {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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/encounter-puzzler-3-renaming-a-net-logicallyMon, 28 Feb 2011 20:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1260627BobD/cadence_blogs_8/b/di/posts/encounter-puzzler-3-renaming-a-net-logically3The 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} { } 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/dbshape-for-all-your-logical-operation-needsWed, 16 Feb 2011 16:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1254487BobD/cadence_blogs_8/b/di/posts/dbshape-for-all-your-logical-operation-needs3This 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 ] [-output ] [AND | ANDNOT | OR | XOR | SIZE | BBOX | MOVE { }] ... -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 # 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 # Specifies the output format. default: rect (string, optional) # polygon or rect or list of polygon and rect. polygon: # {{x y} {x y} {x y} ... }; rect: {x1 y1 x2 y2} (list, required) AND # binary operator: intersection of shapeLists ANDNOT # binary operator: initial shapeList minus OR # binary operator: union of shapelists XOR # binary operator: OR minus AND of shapeList # (string, optional) SIZE # unary operator: increase the size of shapeList by MOVE { } # unary operator: move the shapeList by { } 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 Encounterhttps://community.cadence.com/cadence_blogs_8/b/di/posts/advanced-maneuvers-in-feedthrough-insertion-maximizing-routability-while-minimizing-port-creationMon, 10 Jan 2011 14:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1249096BobD/cadence_blogs_8/b/di/posts/advanced-maneuvers-in-feedthrough-insertion-maximizing-routability-while-minimizing-port-creation0Previously 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/planning-for-hierarchical-design-success-do-you-have-a-robust-feedthrough-insertion-solutionMon, 27 Dec 2010 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1248835BobD/cadence_blogs_8/b/di/posts/planning-for-hierarchical-design-success-do-you-have-a-robust-feedthrough-insertion-solution1Feedthrough 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/cdnlive-silicon-valley-2010-now-available-on-demandThu, 04 Nov 2010 14:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1224726BobD/cadence_blogs_8/b/di/posts/cdnlive-silicon-valley-2010-now-available-on-demand0I 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/keeping-it-high-level-at-cdnlive-silicon-valley-2010Wed, 27 Oct 2010 16:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1202504BobD/cadence_blogs_8/b/di/posts/keeping-it-high-level-at-cdnlive-silicon-valley-20100CDNLive! 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 Dwyerhttps://community.cadence.com/cadence_blogs_8/b/di/posts/using-dbtransform-to-translate-geometric-coordinates-in-encounterTue, 28 Sep 2010 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1179194BobD/cadence_blogs_8/b/di/posts/using-dbtransform-to-translate-geometric-coordinates-in-encounter1This 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 {-inst | {-cell -orient -pt {x y}}} -help # Prints out the command usage -d # Specifies if points are in dbUnit: default is um # (bool, optional) -inst # instance object (db object, required) -cell # 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 # 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'. JasonGhttps://community.cadence.com/cadence_blogs_8/b/di/posts/encounter-puzzler-2-solution-finding-registers-beneath-a-hierarchyFri, 24 Sep 2010 11:00:00 GMT75bcbcf9-38a3-4e2e-b84b-26c8c46a9500:1179027BobD/cadence_blogs_8/b/di/posts/encounter-puzzler-2-solution-finding-registers-beneath-a-hierarchy0Thanks 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 .?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