Stats

  • Locked Locked
  • Replies 3
  • Subscribers 143
  • Views 9155
  • 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

Deleting subRects from a ROD object

BorisD

Greetings,

 I have interesting situation, I thought would be trivial to resolve but as it turns out is more complex than expected. I have shape created using rodCreateRect() with ?subRectArray argument specified. My goal is to be able to delete certain subRectangles that match given criteria. Once I narrow down to specific subRect dbIds, running dbDeleteObject() on them returns t, but it doesn't actually remove the shape from the layout. Further investigation appears to show that these complex rod objects also count as "group" and the unnamed rectangles are its group members. I figured maybe using dbDeleteGroupMemberFromGroup() and dbDeleteObjectFromGroup() can facilitate it but I could not bring this to work and searching thought documentation did not shed much light either. What is the correct way to achieve this?

Any advise would be great! Thanks!

Sample test case:

rod=rodCreateRect(
 ?cvId cv
 ?layer "y1"
 ?name "myRect"
 ?length 0.5
 ?width 0.1
 ?subRectArray list(list(?layer "y0" ?length 0.01 ?width 0.01 ?spaceX 0.01 ?spaceY 0.01))
)

mapcar('dbDeleteObject setof(shapes rod->subShapes <someCriteria>)) => list( t ... t)

Edit #1 -  I found that once I use rodUnNameShape(rod) then I am able to perform dbDeleteObject() on a subRect, but this is still not ideal, as the rod object name is a property that I want to keep. I guess, I can maybe do rodNameObject() to recreate the initial structure. Is there a better way?

Parents

  • You’ll need to use rodUnNameShape as you’ve noted. Unless you can achieve the same behaviour with using the rod function to add chop holes (sorry, I’m on a phone and can’t check), then that’s the only way. You won’t be able to convert it back into a single ROD object afterwards because you’ll have destroyed the multipart behaviour (this doesn’t cater for arbitrary related objects)

  • in reply to Andrew Beckett

    Well, for the particular case this workaround satisfies the requirement as I can still refer to the same rods by name. I think it's far from optimal, because you could have other subRectangle entries in the rod that you don't want to affect, in which case you will still end up with different structure than what you had in the beginning.

    My workaround code:

    let(((table makeTable("rodsTmp" nil)))
    ;; UnName temporary to allow deletion
      foreach(rod rods
        unless(table[rod->name]
          table[rod->name]=rod->dbId
          rodUnNameShape(rod)))
    ;; Delete subRects on y0 that overlap certain 'bBox'
      mapcar('dbDeleteObject dbShapeQuery(pcCellView "y0" bBox))
    ;; Recreate the rods back with same name
      foreach(rod table['?] rodNameObject(?name rod ?shapeId table[rod] ?permitRename nil))
    ); let

    I'd be interested if anyone has different approach to the problem. In any case, thanks for the tip! 

  • in reply to BorisD

    One thing to be aware of after this is that the resulting ROD object will only contain the master shape and the sub-rectangles will no longer be associated with the master shape.

    I realised that multipart rectangles don't support chops anyway, so my thought about adding a chop hole wouldn't have worked.

    This are just the limitations of ROD...

    Andrew

Reply
  • in reply to BorisD

    One thing to be aware of after this is that the resulting ROD object will only contain the master shape and the sub-rectangles will no longer be associated with the master shape.

    I realised that multipart rectangles don't support chops anyway, so my thought about adding a chop hole wouldn't have worked.

    This are just the limitations of ROD...

    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.