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 doubt this is anything to do with -nograph, but what rather to do with what you're getting back from dbGetOverlaps compared with the selection. For a start, dbGetOverlaps will find any shapes who have bounding boxes that overlap the area, including those on non-selectable layers. geSelectArea() will find the shapes completely within the selection area.

    I'd debug this by running graphically and seeing what the difference is between using dbGetOverlaps and geSelectArea. That might reveal the root of your problem. If it's dbGetOverlaps taking too long to return, that might be hard to do anything about.

    I think customer support should be able to help you here, because this is just guidance on how to implement something with large number of shapes, rather than being version-specific. Yes, you're using IC5141, but the principles should be the same if it was a supported version.

    That said, I'm not sure what you're trying to achieve - it may be that this is an application for which CDB is not well suited - but that's something you can explain more to customer support.

    Kind Regards,

    Andrew.

Reply

  • I doubt this is anything to do with -nograph, but what rather to do with what you're getting back from dbGetOverlaps compared with the selection. For a start, dbGetOverlaps will find any shapes who have bounding boxes that overlap the area, including those on non-selectable layers. geSelectArea() will find the shapes completely within the selection area.

    I'd debug this by running graphically and seeing what the difference is between using dbGetOverlaps and geSelectArea. That might reveal the root of your problem. If it's dbGetOverlaps taking too long to return, that might be hard to do anything about.

    I think customer support should be able to help you here, because this is just guidance on how to implement something with large number of shapes, rather than being version-specific. Yes, you're using IC5141, but the principles should be the same if it was a supported version.

    That said, I'm not sure what you're trying to achieve - it may be that this is an application for which CDB is not well suited - but that's something you can explain more to customer support.

    Kind Regards,

    Andrew.

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.