Stats

  • Locked Locked
  • Replies 9
  • Subscribers 144
  • Views 15201
  • 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

layout shape migration

stuso

Hi All, i've written a simple script that grabs all shapes and changes the layerName and purpose as required (to map from one PDK to another). It works fine on small test cells. However i tried it out on a larger layout that has 52000 shapes (MPP's guard rings, looks llike each contact is a shape) & cadence crashes complaining of memory stack.

I think the code itself is efficient, but perhaps not:

foreach( shape_item cv~>shapes

 cond(
  (( nth( 0 shape_item~>lpp ) == "VTLN" && nth( 1 shape_item~>lpp )) == "drawing"
  shape_item~>layerName="OD" 
  shape_item~>purpose="drawing"
  )

nth( 0 shape_item~>lpp ) == "OD" && nth( 1 shape_item~>lpp )) == "drawing"

  shape_item~>layerName="NWELL" 
  shape_item~>purpose="drawing"
  )

...etc

 );end cond

);end foreach

So it sticks all the shapes in a list and then with the foreach it goes through each element of the list and change its layerName and purpose accordingly. If its not ok to have such a large list is it trivial to handle a list in say 500 elements at a time?

Or could it be that in layout land i am changing all these thousands of layer properties without a save and its too much data for the cadence to handle (or the undo stack becomes massive)?

Many thanks

Stu 

 

 

 

Parents
  • stuso

    Hi guys, thanks for the advice so far. I agree my skill code is inefficent & i'll tidy it up. I have heard from one guy who says he has known a list of 8 million elements.

    I tried an experiment putting a dbSave in my foreach so in effect it would save EVERY time it went round the loop, very inefficient i know. However, it did run (for at least 8 hours!!!) BUT it did not crash. Something interesting happened with the MPP's (multi-part path) , the base layer got changed but the subparts (e.g contacts) did not. I guess this ties in with when you "q" the properties of an MPP, you as the shapes other than the base layer are sub-parts that cannot be directly modified. 

    So thinking out loud the options could be:

    1) subpart shapes are editable in a mpp, i just need to allow this somehow

    2) shapes (subparts) are not directly editable in  a mpp, therefore i could select all MPP's, get their required data ( co-ords, layers ..etc) then delete the mpp, do my layer translation, then re-draw the new mpp ( i have the skill for the new mpp's). I see some similar SR's which i need to look into.

    3) flatten the mpp's, highly undesirable 

    I'm guessing that in my test run that the routine is attempting to edit shapes which are not editable and thats an issue.

    Thanks

    Stu 

     

     

     

Reply
  • stuso

    Hi guys, thanks for the advice so far. I agree my skill code is inefficent & i'll tidy it up. I have heard from one guy who says he has known a list of 8 million elements.

    I tried an experiment putting a dbSave in my foreach so in effect it would save EVERY time it went round the loop, very inefficient i know. However, it did run (for at least 8 hours!!!) BUT it did not crash. Something interesting happened with the MPP's (multi-part path) , the base layer got changed but the subparts (e.g contacts) did not. I guess this ties in with when you "q" the properties of an MPP, you as the shapes other than the base layer are sub-parts that cannot be directly modified. 

    So thinking out loud the options could be:

    1) subpart shapes are editable in a mpp, i just need to allow this somehow

    2) shapes (subparts) are not directly editable in  a mpp, therefore i could select all MPP's, get their required data ( co-ords, layers ..etc) then delete the mpp, do my layer translation, then re-draw the new mpp ( i have the skill for the new mpp's). I see some similar SR's which i need to look into.

    3) flatten the mpp's, highly undesirable 

    I'm guessing that in my test run that the routine is attempting to edit shapes which are not editable and thats an issue.

    Thanks

    Stu 

     

     

     

Children
No Data

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.