*Error* dbTransformPoint: Invalid point - nil

Reinice,

The code is clearly wrong because it's looking at inst~>insTerms and should be looking at inst~>instTerms - but then it shouldn't find any instances at all.

I can't see why this would have failed (assuming you spelt instTerms correctly in the real code), unless maybe the symbols weren't loaded and evaluated. Perhaps you need to do dbOpenHier(cvId 2) - something to force the symbol masters to be evaluated?

If you can't get this to work, please contact customer support with a testcase to show the problem then we can properly investigate.

Regards,

Andrew.

Hi Andrew,

Thanks for your quick reply.

In the real code it is inst~>instTerms. It's a typo error(inst~>insTerms) when I composed this e-mail earlier.

1. What do you mean by unless maybe the symbols weren't loaded and evaluated?

2. Can you give me some examples on how to use dbOpenHier(cvId 2)? How do I use this to my current script?

Thanks and Regards,

Reinice

Reinice,

That was an example of how to use it! Place it after the dbOpenCellViewByType() call. It's normally used to force all the sub-cells in a layout to load from disk too - although then you'd typically give a larger second number (the number of levels of hierarchy). Since schematics instantiate symbols, there's no point in specifying a large number for the hierarchy (although it won't do any harm) because symbols don't normally contain hierarchy. My idea was to see if the dbOpenHier() call causes it to force all the instantiated symbols to be loaded from disk, and if they are pcells (such as the symbol_xform views) to be evaluated - it needs to evaluate each variant to produce the subMaster - that's where the pin figures should be defined.

I'm not sure this will fix your problem - mainly because I'm not really sure what your problem is (seeing the database and code would make it much easier to understand) - so this is a bit of guesswork.

Regards,

Andrew

Did you confirm that you were getting points? I looked at instTerms on one of my schematic instances and it didn't have a points attribute, but it had a bBox. I'm sure you could have a pin fig that is a polygon, in which case it should have points, but it looks to me like your are not getting any points.

Test the following in your CIW. Select an instance of "ndio" and run:

css()~>instTerms~>term~>pins~>fig~>??

Do you see "points" as an attribute? Also, note that I changed "~>terms" to "~>term". I hope that was another typo in your email. If not, then that is a problem as well.

Derek

Derek,

Good point - in the strange formatting in the original post, I didn't notice the ~>points . Maybe one of the devices has a polygon pin (might even be rectangular in shape) whereas the other one has rectangular pins. Doesn't really explain why it would work once and then not the next time though... seems a bit strange.

I think my dbOpenHier() suggestion is probably a red herring - not something that I would normally expect to have to do.

Andrew.

Hi Derek,

Thanks for the info on how to know attributes.

"~>terms" is just a typo. The real code has "~>term"

I' am now able to get the "points" of a pin on an instance(schematic).

Hi Andrew,

Remember my previous post about migrating from old process to new process(where you gave a starting point)? This current post is related to that.

Please refer to the original post(this post). In my current code I replaced inst~>master(of "ndio") by masterId of the new process:

masterId = dbOpenCellViewByType("gpdk40" "ndio" "symbol" "schematicSymbol")

My question is how can I get the origin of this instance in the schematic whose master(old process) has been replaced by another masterId(new process). I 'am using inst~>xy but I 'am not getting the right origin(xy).

Thank you very much in advance.

Thanks and Regards,

Reinice

 Hi Reinice,

I'm pretty sure that the inst->xy coordinates are the right ones.
Probable the point does not match with the lower left corner of the symbol's bBox as you expect (try inst->bBox).
If they do not match the reason could be:
- a transform (rotation) was applied on the symbol
- if you open the symbol view probable the lower left corner of the symbol is not 0.0:0.0

Best Regards,

Marcel

Hi Marcel,

Yup, your right the inst~>xy does the job. I' am getting the origin of my instance schematic. It's just a flow issue on my real code. Thanks. = )

Hi Andrew,

On the starting code that you gave to me before(forum #1313594)

1. Is there a way to make placement of new instance(new process) in the center and not depending on pinOrigin from the config.file?

2. How can I modify the code for me to migrate also other cellview other than the curent open cellview without opening them all?

When I migrate old instance that have connection to wire on the edge of it's terminal box, it is left hang and not connected when replaced by the new instance. 

3. How can I wire the new instance(new process) in the middle on each of it's terminal if it's counter part old instance(old process) was wired on the edge on each of it's terminal box?

Thank you very much in advance.

Thanks and Regards,

Reinice

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.

Hi Andrew,

Thank you very much for your quick reply. I'll work around with your suggestion and pointers.

Enjoy your vacation. = )

Thanks and Regards,

Reinice