Stats

  • Locked Locked
  • Replies 10
  • Subscribers 144
  • Views 4380
  • 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

*Error* dbTransformPoint: Invalid point - nil

Reinice

Hi All,

I want to get the points of a terminal(a "polygon" object type) pins(e.g. PLUS-MINUS, E-B-C) from a schematic symbol

Here is my script:

foreach( cell ddGetObj("QCBGB7_09T")~>cells

cvId=dbOpenCellViewByType("QCBGB7_09T" cell~>name "schematic" "schematic" "a")

foreach(inst cvId~>instances

if(inst~>cellName=="ndio" then

when(inst~>purpose == "cell"

foreach(insTerm inst~>insTerms

insTermPntsO=car(insTerm~>terms~>pins~>fig~>points)

ll=nth(0 insTermPntsO)

ur=nth(2 insTermPntsO)

tform=inst~>transform

;;transform ll=lower right and ur=upper right points of a symbol

insTermPntLL=dbTransformPoint(ll tform)

insTermPntUR=dbTransformPoint(ur tform)

);end of foreach

);end of when

);end of if

);end of foreach

);end of foreach

I' am having this error everytime I run this script for the "ndio" schematic symbol. By the way "ndio" is a symbol_xform(symbol pcell)

*Error* dbTransformPoint: Invalid point - nil

But if I use the script first time for other symbol such as pnp, for once I 'am not encountering this error. By the way "pnp" is also a symbol_xform(symbol pcell)

After I run the script again for pnp I' am encountering the same error.

Please correct the wrong part of my script.

Can anyone help me. It will be highly appreciated if anyone can help.

Thank You Very Much in advance.

Thanks and Regards,

Reinice

Parents

  • Reinice,

    1) Yes, although it would be a reasonable amount of change in the code. I'm surprised you don't want the pin to stay in the same place rather than the centre, but that's your choice.  Essentially this is the bit in the code commented "Figure out the transform needed to map from one to another" - in getMapDetails(). You'd also have to change checkMapDetails() so that it didn't insist on pinOrigin being present. The final place is in the bit where it is commented "Otherwise if it is not the pin marked as the origin, wire it up" in replaceInstance(). However, that probably doesn't need changing because if pinOrigin is not present, it would wire up all the pins.

    2) You don't need to modify the code. The abMapAndWire() function takes an optional argument which is the cellViewId to work on - you could call dbOpenCellViewByType() and pass the result to abMapAndWire. It just defaults to the cellView in the current window.

    3) Is it really wired on the edge? I can imagine this might only be the case if the terminals aren't on grid. Given that the wiring created is snapped to the grid specified in the config, you should be able to adjust the xSnapSpacing/ySnapSpacing to get this to work.

    Personally I think the right fix for 1) is to alter it to cope with pcell variants. That would probably entail detecting whether the source was a pcell (look at ~>isParamCell on the master when you open it), and then if so not computing the transform in getMapDetails as it reads the config, but adding a flag to say it's a pcell. Then when you look up the map at the beginning of replaceInstance, if it doesn't find it, build the new array entry on the fly, starting from the info in the mapData array for master~>superMaster, and storing it back in the mapData array so that if you find that variant again it's already done. The pin-based mapping could then be used and computed based on the resolved pcell subMaster.

    Unfortunately I just don't have time to make this change to the code, and test it, before I go on vacation tomorrow (as well as getting the day job done). So all I can do is give you some pointers in the right direction.

    Regards,

    Andrew.

Reply

  • Reinice,

    1) Yes, although it would be a reasonable amount of change in the code. I'm surprised you don't want the pin to stay in the same place rather than the centre, but that's your choice.  Essentially this is the bit in the code commented "Figure out the transform needed to map from one to another" - in getMapDetails(). You'd also have to change checkMapDetails() so that it didn't insist on pinOrigin being present. The final place is in the bit where it is commented "Otherwise if it is not the pin marked as the origin, wire it up" in replaceInstance(). However, that probably doesn't need changing because if pinOrigin is not present, it would wire up all the pins.

    2) You don't need to modify the code. The abMapAndWire() function takes an optional argument which is the cellViewId to work on - you could call dbOpenCellViewByType() and pass the result to abMapAndWire. It just defaults to the cellView in the current window.

    3) Is it really wired on the edge? I can imagine this might only be the case if the terminals aren't on grid. Given that the wiring created is snapped to the grid specified in the config, you should be able to adjust the xSnapSpacing/ySnapSpacing to get this to work.

    Personally I think the right fix for 1) is to alter it to cope with pcell variants. That would probably entail detecting whether the source was a pcell (look at ~>isParamCell on the master when you open it), and then if so not computing the transform in getMapDetails as it reads the config, but adding a flag to say it's a pcell. Then when you look up the map at the beginning of replaceInstance, if it doesn't find it, build the new array entry on the fly, starting from the info in the mapData array for master~>superMaster, and storing it back in the mapData array so that if you find that variant again it's already done. The pin-based mapping could then be used and computed based on the resolved pcell subMaster.

    Unfortunately I just don't have time to make this change to the code, and test it, before I go on vacation tomorrow (as well as getting the day job done). So all I can do is give you some pointers in the right direction.

    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.