Stats

  • Locked Locked
  • Replies 15
  • Subscribers 143
  • Views 19005
  • 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

Most efficient db function to move all shapes in a design?

jaleco

Working in ic5141, what is the most efficient way to move all shapes in a design using the db functions?

I'm dealing with millions of shapes and would like to use a function like Move Origin, but this is not a db function.

Is it more efficient to create a figure group, add each shape to the group and move the group, or to select and move each shape?

Neither seem like good options for a list of millions of shapes.

Parents
  • I recall having performance problems in 5.1.41 when dealing with many flat shapes. I was able to get much better results after pre-allocating some memory to help eliminate garbage collection. If I recall correctly, I had to use needNCells on the dbobject. The following command will set aside enough memory to handle 4 million objects before garbage collection. You could also try increasing the number (but you'll need to stay within the memory limits of the tool). Use "top" to see how much memory your icfb or layout process is using before and after this command:
    needNCells('dbobject 4M)

    You can use gcsummary to see a list of all the object types and how many times garbage collection was run on that object in the last column.

    Another possibility is that dbProduceOverlap is more efficient in 5.1.41 than dbGetOverlaps. In 6.1.7, they appear about equal. The doc says this:
    Returns a list of all the shapes in a cellview whose bounding boxes overlap the area specified by l_bBox. This function interface is simpler than dbGetOverlaps if you are only interested in finding the overlapping shapes.

    Derek
Reply
  • I recall having performance problems in 5.1.41 when dealing with many flat shapes. I was able to get much better results after pre-allocating some memory to help eliminate garbage collection. If I recall correctly, I had to use needNCells on the dbobject. The following command will set aside enough memory to handle 4 million objects before garbage collection. You could also try increasing the number (but you'll need to stay within the memory limits of the tool). Use "top" to see how much memory your icfb or layout process is using before and after this command:
    needNCells('dbobject 4M)

    You can use gcsummary to see a list of all the object types and how many times garbage collection was run on that object in the last column.

    Another possibility is that dbProduceOverlap is more efficient in 5.1.41 than dbGetOverlaps. In 6.1.7, they appear about equal. The doc says this:
    Returns a list of all the shapes in a cellview whose bounding boxes overlap the area specified by l_bBox. This function interface is simpler than dbGetOverlaps if you are only interested in finding the overlapping shapes.

    Derek
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.