how to delete all the shapes on a specific layer

Discussion in 'Cadence' started by Marcel Preda, Sep 27, 2010.

  1. Marcel Preda

    Marcel Preda Guest

    Hi there,

    Is there a fast method to delete from a layout (it's a diva extracted
    in fact) all the shapes on a specific layer ?

    For now I'm using:
    ~~~~~~~~~~~~~~~~~~~~~~~
    hiSetUndoLimit(0) ;; disable undo history - spped
    foreach( lp cv~>lpps
    if (lp~>layerName==myName && lp~>purpose==myPurpose then
    foreach( shape lp~>shapes
    dbDeleteObject(shape)
    ) ;; foreach

    ) ;; if
    ) ;; foreach
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    But I've noticed that the function is very slow, when the purpose is
    "net" .
    E.g. if I run the code for something like ("con" "drawing") , number
    of shapes ~59K it tooks ~2 seconds
    For ("via1" "net"), number of shapes ~712K it tooks ~26 minutes ~ 1560
    seconds .

    I think that in case of "net" purpose when the shape is deleted also
    the associated net infop has to be updated.
    Is it write ?
    Is there any way to speedup the code ?


    My icfb version 5.0.33.500.41

    Thank you,
    Marcel
     
    Marcel Preda, Sep 27, 2010
    #1
    1. Advertisements

  2. Marcel Preda wrote, on 09/27/10 10:35:
    Hi Marcel,

    Not really. I have an enhancement request in with R&D to provide a function to
    delete all the shapes on a layer-purpose-pair efficiently.

    That said, it does sound rather slow - you might want to try profiling the code
    with the SKILL profiler to see where it is taking all the time (maybe it's
    garbage collection, or in the list creation - hard to be sure without profiling it).

    That's also a rather old (and definitely unsupported) version - although I doubt
    it would get magically faster in newer versions.

    Wouldn't it be better to just not use saveInterconnect on the layer in the first
    place in the Diva rules?

    Regards,

    Andrew.
     
    Andrew Beckett, Sep 27, 2010
    #2
    1. Advertisements

  3. Marcel Preda

    Marcel Preda Guest

    Hi Andrew,

    Diva rules are/were written by other team, I just want to extend the
    verification with some ERC stuff.
    And is not possible/allowed to modify the rule files (DP freeze,
    etc).

    I've run the skill code using profiling few times, everytime I was
    restarting the icfb .
    And I get:
    Time spent in dbDeleteObject ~ 1100 secs
    Time spent in gc ~ 200 secs

    And my procedure (it deletes all the layers except few of them) is
    bellow.
    Some debug messages are still there.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /*
    Delete from cv all the layers' shapes, keep only shapes on l_lpps
    layers .
    */
    procedure( MyPckg_keepOnlyLayers(l_lpps cv)
    let( (total)
    total=0 ;; count number of deleted shapes
    println(getCurrentTime())
    hiSetUndoLimit(0)
    foreach(lx cv->lpps
    if( !exists(x l_lpps car(x) == lx->layerName && cadr(x) == lx-
    info("--- %L %L %d \n" lx->layerName lx->purpose lx-
    total = total + lx->nShapes
    foreach(shape lx->shapes
    dbDeleteObject(shape)
    )
    println(getCurrentTime())
    ) ;; if
    ) ;; foreach
    info("%L %d\n" getCurrentTime() total)
    t
    ) ;; let
    ) ;; proc
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Could be done any improvement there ?

    BR,
    Marcel
     
    Marcel Preda, Sep 28, 2010
    #3
  4. Did you try to measure your function when executed with dbAccess?
     
    Jean-Marc Bourguet, Sep 28, 2010
    #4
  5. Marcel Preda

    Marcel Preda Guest

    Hi Jean-Marc,

    What is dbAccess ?
    Any doc where I can read about it ?


    BR,
    Marcel
     
    Marcel Preda, Sep 28, 2010
    #5
  6. tools/dfII/bin/dbAccess

    It is probably documented somewhere under doc, but I didn't search
    precisely where.

    It is a skill interpreter which provides all the functions you need here.
    What I'm trying to determine is if the slowness is intrinsic to what you
    are doing or is due to some other maintenance that virtuoso is doing in
    more advanced setup.

    Yours,
     
    Jean-Marc Bourguet, Sep 28, 2010
    #6
  7. Jean-Marc Bourguet wrote, on 09/28/10 10:29:
    In addition to what Jean-Marc suggests trying, you can probably reduce the gc
    overhead by using needNCells() to preallocate additional space (might need to do
    this for list and dbobject types). Call gcsummary() before and after running
    your code to see the number of list cells and dbobject types that have been created.

    At least that should allow you to save 200 seconds.

    Jean-Marc's suggestion will allow us to see if the overhead is due to any
    virtuoso triggers kicking in. Especially if you have the layout open in an
    editor window (and I can imagine it might be worse if it's Layout XL, because
    there are more things that need to be kept up to date there).

    Regards,

    Andrew.
     
    Andrew Beckett, Sep 28, 2010
    #7
  8. Marcel Preda

    Marcel Preda Guest

    Hi there,

    I've run dbAccess and I get the same total time.
    After debuging with gcsummary() and using needNCells() I was able to
    save ~ 3 minutes, as expected.

    BR,
    Marcel
     
    Marcel Preda, Sep 28, 2010
    #8
  9. Marcel Preda wrote, on 09/28/10 16:08:
    Marcel,

    Maybe you could log a service request with http://support.cadence.com and give
    this example and ask for a duplicate CCR to be filed - the existing CCR number
    is 728684.

    Best Regards,

    Andrew.
     
    Andrew Beckett, Sep 29, 2010
    #9
  10. Marcel Preda

    Marcel Preda Guest

    Hi Andrew,

    Is it posible to view the description CCR #728684 on web page ?

    If I go to "View Cadence Change Requests (CCRs)" I get a page with
    message:
    ~~~~~~~~~~~~~~
    There are no CCRs to view.
    ~~~~~~~~~~~~~

    Doing a search by "728684" to "All Content" returns nothing.

    BR,
    Marcel
     
    Marcel Preda, Sep 29, 2010
    #10
  11. Marcel Preda wrote, on 09/29/10 13:37:
    Hi Marcel,

    It can only be viewed if the CCR was filed for you as a customer. This is
    because potentially CCRs might have customer sensitive data in.

    Even then, Cadence Online Support doesn't let you see the description.

    But it's the same issue you're talking about here (I filed the CCR). In fact
    looking at it, I'd also made the same suggestion about improving matters with
    needNCells!

    Rather oddly though, in the example in the CCR, it was only taking 100 seconds
    to delete 5 million shapes. So yours is a LOT slower. My CCR was for IC613, so
    maybe the performance is a lot better in OA for such an operation compared with
    the very old (and unsupported) version you're using?

    Regards,

    Andrew.
     
    Andrew Beckett, Sep 29, 2010
    #11
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.