Stats

  • Locked Locked
  • Replies 5
  • Subscribers 142
  • Views 14674
  • 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

Undocumented (?) gotcha in pcDefinePCell()

archive

In icfb 5.10.41.500.5.107, this works: procedure(makePCell(lib cell view "t") pcDefinePCell( list(ddGetObj(lib) cell view) ( (parameter_a "default value a") (parameter_b "default value b") (parameter_c "default value c") ) ; This is where I would, like, draw shapes and stuff. t ) ) Output: makePCell("myLib" "pcell" "layout") Generating Pcell for 'pcell layout'. db:219751468 But this does not work: procedure(makePCellBroken(lib cellName view "t") pcDefinePCell( list(ddGetObj(lib) cellName view) ( (parameter_a "default value a") (parameter_b "default value b") (parameter_c "default value c") ) ; This is where I would, like, draw shapes and stuff. t ) ) Output: makePCellBroken("myLib" "pcell" "layout") *WARNING* Invalid cell name - nil nil


Originally posted in cdnusers.org by tweeks

  • Don't use keywords like libName, cellName, viewName, viewType etc. The pcDefinePCell might be using them internally and that's the reason use of such keywords might make it fail.

    RR


    Originally posted in cdnusers.org by rairaj

  • Thanks, Rairaj.

    Has this been fixed in 6.x?

    Isn't it possible to write pcDefinePCell() in such a way that its internal variables do not use the same namespace as variables referenced in the body of a pcDefinePCell() call? If that really is not possible, at least couldn't pcDefinePCell()'s internal variables be given names that users are less likely to choose? For example, "__cellName__"?


    Originally posted in cdnusers.org by tweeks

  • This is due to a phenomenon known as variable capture, which can easily happen with macros and nprocedures (which is what pcDefinePCell is). I've checked, and it's still there in IC612. I see that CCR 547557 has been filed for you on this - there's another recent one on the same subject.

    Regards,

    Andrew.


    Originally posted in cdnusers.org by adbeckett

  • Hi Andrew,

    Thanks for confirming it's also broken in IC612, and thanks for mentioning the technical term "variable capture". Googling that phrase, I found this very interesting article that gives several guidelines for avoiding variable capture in macros. Perhaps I should forward the link to Cadence support? ;)

    Thanks again!

    --tom


    Originally posted in cdnusers.org by tweeks

  • Interesting - I looked at that page, and thought "hey, this looks familiar". Turns out it's the text of a book "on lisp" by Paul Graham. Doesn't seem to mention his name anywhere, so I wonder if it's legal...

    Anyway, in the other CCR on this, they know what needs to be done to cure this. One of our other big LISP guys filed it...

    Andrew.


    Originally posted in cdnusers.org by adbeckett

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.