• 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. Community Forums
  2. Custom IC Design
  3. How to flatten layout cells and preserve pin names when...

Stats

  • Locked Locked
  • Replies 10
  • Subscribers 126
  • Views 19731
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to flatten layout cells and preserve pin names when pin names from different cells are the same

twen
twen over 9 years ago

I am using virtuoso version 6.1.6-64b 12/07/2015 20:18 (sjfbm186) .

Suppose I have a top level cell T, and T contains two cells A and B, and there are a pin called P in both A and B. When I flatten cells A and B by gui (Preserve pins, preserve ROD Objects) to by foreach(s list(dbA dbB) dbFlattenInst(s 1 t t t t t t t)), the pin P in cell A is brought up into cell T without any problem. However, the label on pin P in cell B is renamed to something like dbNet032. I see this can be useful in certain cases, but it is not what I want.

Is there anyway that I can flatten A and B and brought up the pin P to cell T and keep both pins' label as it was?

Thanks in advance,

TJ

  • Cancel
  • Quek
    Quek over 9 years ago

    Hi TJ

    After flattening 2 instances I1 and I2, you should have the following 2 pins at the top level:

    pinName : I1|pinP
    terminalName: pinP

    pinName : I2||pinP
    terminalName: dbNet1
    (IC617 will name it as "I2|pinP")

    The following warning will also be shown in CIW:
    *WARNING* (DB-270000): dbCreateTerm: Terminal with name 'pinP' already exists

    Suppose Virtuoso preserves the terminal name for inst2, we would have the following situation:

    pinName : I2||pinP
    terminalName: pinP

    In terms of pin connectivity model, this would mean that pins "I1|pinP" and "I2|pinP" are strongly connected under the terminal "pinP". By setting the terminal name as "dbNet1", the 2 pins would not be related to each other.

    If creating strongly connected pins is really what you need, you will have to use a SKILL script to post process the flattened results so that the terminal names are the same.

    Best regards
    Quek

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Quek
    Quek over 9 years ago

    One correction:

    >>> this would mean that pins "I1|pinP" and "I2|pinP" are strongly connected under the terminal "pinP"

    this would mean that pins "I1|pinP" and "I2|pinP" are weakly connected under the terminal "pinP"

    2 pins (each with 1 fig) under 1 terminal => weakly connected
    1 pin with 2 figs under 1 terminal => strongly connected

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Maybe this will help. I wrote this a long time ago - haven't tested it recently though.

    /* abFlattenInst.il
    
    Author     A.D.Beckett
    Group      Custom IC (UK), Cadence Design Systems Ltd.
    Language   SKILL
    Date       Jul 29, 1998 
    Modified   
    By         
    
    Instance flattener which doesn't rename pins
    
    Can be used in place of dbFlattenInst() or leFlattenInst()
    The arguments are the same with the exception of the additional netSuffix argument,
    which can be ignored as it is optional. 
    
    Ended up slightly more complex because of having to deal with the case
    that you can't dbMergeNet two nets which both have terminals 
    
    ***************************************************
    
    SCCS Info: @(#) abFlattenInst.il 03/23/99.22:04:30 1.2
    
    */
    
    (procedure (abFlattenInst inst levels @optional pcells? preservePins? 
                              (netSuffix "_abFlatTmp"))
      (let (result termName oldNet newNet renamedNets cellView pinFigs)
           (if preservePins?
               (progn
                (setq cellView (dbGetq inst cellView))
                /* see if any of the terminal names on the instance match any
                   existing nets in the parent cellView; if so, rename them */
                (foreach term (dbGetq (dbGetq inst master) terminals)
                         (setq termName (dbGetq term name))
                         (when (setq oldNet (dbFindNetByName cellView termName))
                               (setq renamedNets (cons termName renamedNets))
                               /* rename the net */
                               (setq newNet (dbMakeNet cellView (strcat termName netSuffix)))
                               (dbMergeNet newNet oldNet)
                               /* rename the terminal, to stop it clashing too */
                               (when (dbGetq newNet term)
                                     (dbSetq (dbGetq newNet term) (strcat termName netSuffix) name))
                               )
                         )
                /* do the flattening */
                (setq result (dbFlattenInst inst levels pcells? preservePins?))
                /* any nets which were renamed have to be renamed back to the original name */
                (foreach netName renamedNets
                         (when (setq oldNet
                                     (dbFindNetByName cellView (strcat netName netSuffix)))
                               (setq newNet (dbMakeNet cellView netName))
                               /* get the figures which are the pins, and delete the "new"
                                  terminal */
                               (setq pinFigs (dbGetq (dbGetq (dbGetq newNet term) pins) fig))
                               (dbDeleteObject (dbGetq newNet term))
                               (dbMergeNet newNet oldNet)
                               /* rename the terminal back again */
                               (when (dbGetq newNet term)
                                     (dbSetq (dbGetq newNet term) netName name))
                               /* go through the old pin figures and reattach them to the
                                  new net */
                               (foreach fig pinFigs
                                        (dbCreatePin newNet fig))
                               ))
                result
                )
               /* otherwise, if preservation of pins is off, just flatten as normal */
               (dbFlattenInst inst levels pcells? preservePins?)
               )
           ))
    

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • twen
    twen over 9 years ago

    Hi, Quek,

    Thank you for explaining the complications of the issue.
    TJ

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • twen
    twen over 9 years ago

    Hi, Andrew,

    Thank you for the code. I'll need to study your code and debug it in order to explain why it still renames the pins. Here is how I used your code after selecting 5 instances:
        foreach(sel geGetSelSet() abFlattenInst(sel 1 t t ""))

    *WARNING* (DB-270000): dbSetTermName: Terminal with name 'P' already exists

    *Error* dbDeleteObject: argument #1 should be a database object (type template = "d") - nil

    I'll post the detail once I found it out.

    TJ

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    The problem is that you passed "" as the fifth argument to abFlattenInst. That will break the code completely, because it means that it tries to rename each net to the same name it is already - the whole point is that it temporarily renames the nets with a suffix (default called "_abFlatTmp") to avoid a clash, flattens, and then merges them back afterwards. The temporary name no longer exists at the end - so you should not have to specify this at all except in the unlikely event that you already have nets/terms with the suffix "_abFlatTmp".

    The comments at the top of the code also suggest you can ignore the suffix comment.

    By specifying the suffix as "", nothing gets renamed, and hence you end up with the clash still every time it tries to flatten.

    I ran:

    foreach(sel geGetSelSet() abFlattenInst(sel 1 t t))

    and that worked fine.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • twen
    twen over 9 years ago

    Oh, that explains part of the problem. The reason that I use "" as the suffix is try to avoid this problem without careful thinking.

    *WARNING* (DB-270000): dbMakeNet: Input name (or member): ov_out<79>_abFlatTmp has improper bus syntax

    So I changed your code to use it as prefix instead of as suffix and this warning went away.

    The only remaining issue is that the duplicated pins brought up are preserved as expected but their attached labels are deleted from all pins except those pins from the first flattened instance.


    TJ

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Ah, the perils of a program I wrote 18 years ago and obviously hadn't tested that much!

    I'll take a look tomorrow to update it to make sure it preserves the labels and textDisplays.

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • twen
    twen over 9 years ago

    Hi, Andrew,

    I am impressed that the program your wrote 18 year ago is still working and is sort of working in my case!

    I am wondering if you could create a new version of dbFlattenInst() instead of wrapping around the existing dbFlattenInst() so you do not need to do the renaming and deleting, provided that the existing dbFlattenInst() is not thousands-line long and would not take you too long?


    TJ

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 9 years ago

    Hi TJ,

    dbFlattenInst is not implemented in SKILL (it's in C++) and so wrapping the existing flatten is the most pragmatic approach (there are other ways, but most of the problems would be similar anyway). So I can't just rewrite the existing dbFlattenInst. This would be a good enhancement for dbFlattenInst2, potentially (this is a new form with a few additional options, but it doesn't have this behaviour yet).

    Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

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

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