How to find functions' definition in cadence?

Hi Lei,

In this case the getSGq() SKILL function is mapped from the "~>" operator (get Squiggle Greater-than, implicitly quote the second argument). Depending on the context of how ~> is used, you may see it mapped to other functions, e.g. dbGetq or dbGet, and the following are documented in the Finder / cdnshelp.

Hopefully this answers your question.

Best regards,

Lawrence.

Hi, 

Thanks for your help! 

Now I know that the getSGq() SKILL function is mapped to dbGetq or dbGet, and I find information about these two functions. But  next time, when I come across this undocumented functions, how can I get information? I mean, how can I know that whether or not it is mapped to some other known or unknown, may be even undocumented functions, right?

Lei

Hi Lei,

A really good way to check your SKILL code is using the Tools -> SKILL Development -> Surveyor menu/tool - the survey gathers up all of the SKILL functions being used (you can omit any locally defined functions for privacy if you wish) and then allows you to submit them to Cadence for an automated analysis - this will give you a very good indication of whether you might be using any "private" SKILL function or not.  An undocumented function may well be private, but it is not always the case, as in this example; getSGq() is a public function, but it is not documented.  A SKILL Survey would reveal such information as well as any changes made to a function for any particular release - this is very useful when migrating SKILL code from one software version to the next.  Many changes are "compatible" where existing arguments and functionality remain untouched, but new arguments might be added.  Other changes, such as the removal or deprecation of a function are revealed in the survey results also.

I want to try to impress on you and others that it is fairly rare to encounter an undocumented public function, but the above tool can certainly increase the "comfort level" about one's SKILL code.

Best regards,

Lawrence.

Part of the reason why getSGq is a bit of a special case is that the idea is that we document it being used as an operator ~> but not in its functional form. Since all operators in SKILL are functions, this is a bit of an oddity - and for those of us that write LISP-style code, rather an anomoly. Probably we should just go ahead and document it properly and have done with it! I do remember a discussion about it a few years ago, where we decided that most users would use the ~> form and so documenting it was a bit excessive.

Regards,

Andrew.

Thank you both for your help!

You are welcome.  Incidentally, CCR 819675 was filed to request that setSGq() and getSGq() be documented, so hopefully these questions should be less frequent in future.

Regards,

Lawrence.