• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Digital Design
  3. Guest Blog: Using dbTransform to Translate Geometric Coordinates…
BobD
BobD

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
CDNS - RequestDemo

Have a question? Need more information?

Contact Us
Avago
dbTransform
encounter
db access
Digital Implementation
tcl

Guest Blog: Using dbTransform to Translate Geometric Coordinates in Encounter

28 Sep 2010 • 4 minute read

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

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

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

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

The usage, as of EDI9.1USR1:

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

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

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

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

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

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

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

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

 

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

JasonG


CDNS - RequestDemo

Try Cadence Software for your next design!

Free Trials

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information