protected skill environment?

[stefano zanella]

Hi,

I have a set of ocean scripts that I run on an unknown environment
(i.e. on machines with IC installations that I do not own or control).
Sometimes common SKILL commands are aliased with other commands that do
not do the same thing (don't ask me why). Is there a way to run an ocean
script in such a way that those aliases do not affect the script being run?

Thanks,
Stefano

 

[G Vandevalk]

.... why? (sorry ... I had to ask ... )

Typically large installations will have you run a wrapper setup script
overtop
of the tools in question. (Usually to point at where they install stuff and
setup
their license files ... and sometimes alias common commands ... to something
slightly different ... just to make you go crazy ... (actually they usually
have a
reason that does not apply in your case ... )

I have occasionally created a bare-bones script that only runs the tool and
as little
baggage as possible. (License files .. Cadence source only. ... )
This will not contain many site customizations that the local users want.
(plotting, libraries of custom devices etc. )
This is the method I often use to isolate problems of the software
(Cadence's bug)
from problems of installation/local cutomization etc. )

This will help you in finding out what commands are aliased ... (can you
unalais them.)

- good luck ...

-- G





"stefano zanella" <stefanoDOTzanella@pdf.com> wrote in message
news:116urd5blmgfdd0@corp.supernews.com...

Hi,

I have a set of ocean scripts that I run on an unknown environment
(i.e. on machines with IC installations that I do not own or control).
Sometimes common SKILL commands are aliased with other commands that do
not do the same thing (don't ask me why). Is there a way to run an ocean
script in such a way that those aliases do not affect the script being
run?

Thanks,
Stefano

 

[Stefano Zanella]

Hi,

Thanks a lot for your answer. Unfortunately, I have no control over
the environment which my ocean scripts are executed on. I also have no
way of knowing which commands are aliased (i.e. which functions have
been redefined) for the simple reason that my scripts are part of a tool
we sell. So, if they redefine a command and Artist breaks they just
think: "We have screwed up". If my tool (which runs on Cadence) breaks
because of that, now my tool does not work.

Regards,
Stefano

PS: I don't know why! Probably you are right: for a very good reason
that I simply fail to understand

G Vandevalk wrote:

.... why? (sorry ... I had to ask ... )

Typically large installations will have you run a wrapper setup script
overtop
of the tools in question. (Usually to point at where they install stuff and
setup
their license files ... and sometimes alias common commands ... to something
slightly different ... just to make you go crazy ... (actually they usually
have a
reason that does not apply in your case ... )

I have occasionally created a bare-bones script that only runs the tool and
as little
baggage as possible. (License files .. Cadence source only. ... )
This will not contain many site customizations that the local users want.
(plotting, libraries of custom devices etc. )
This is the method I often use to isolate problems of the software
(Cadence's bug)
from problems of installation/local cutomization etc. )

This will help you in finding out what commands are aliased ... (can you
unalais them.)

- good luck ...

-- G





"stefano zanella" <stefanoDOTzanella@pdf.com> wrote in message
news:116urd5blmgfdd0@corp.supernews.com...

Hi,

I have a set of ocean scripts that I run on an unknown environment
(i.e. on machines with IC installations that I do not own or control).
Sometimes common SKILL commands are aliased with other commands that do
not do the same thing (don't ask me why). Is there a way to run an ocean
script in such a way that those aliases do not affect the script being

run?

Thanks,
Stefano

 

[Andrew Beckett]

Hi Stefano,

It can be really frustrating when things like this happen. A little while ago
I spent some time working with a customer who was having problems with an
OCEAN script failing - they were trying to use ocnPrint with some of the
arguments that defined the precision and formatting - and it was falling over.

By a bit of luck (and a flash of inspiration) I found that the design kit they
were using redefined ocnPrint - and did not support all the keyword arguments
that it has done for several releases.

That's why I always recommend against redefining Cadence functions - the
caveat being "do it if you really know what you're doing, and don't complain
to us when things break...".

Andrew.

On Fri, 29 Apr 2005 15:54:29 -0700, Stefano Zanella
<stefanoDOTzanella@pdf.com> wrote:

Hi,

Thanks a lot for your answer. Unfortunately, I have no control over
the environment which my ocean scripts are executed on. I also have no
way of knowing which commands are aliased (i.e. which functions have
been redefined) for the simple reason that my scripts are part of a tool
we sell. So, if they redefine a command and Artist breaks they just
think: "We have screwed up". If my tool (which runs on Cadence) breaks
because of that, now my tool does not work.

Regards,
Stefano

PS: I don't know why! Probably you are right: for a very good reason
that I simply fail to understand

G Vandevalk wrote:
.... why? (sorry ... I had to ask ... )

Typically large installations will have you run a wrapper setup script
overtop
of the tools in question. (Usually to point at where they install stuff and
setup
their license files ... and sometimes alias common commands ... to something
slightly different ... just to make you go crazy ... (actually they usually
have a
reason that does not apply in your case ... )

I have occasionally created a bare-bones script that only runs the tool and
as little
baggage as possible. (License files .. Cadence source only. ... )
This will not contain many site customizations that the local users want.
(plotting, libraries of custom devices etc. )
This is the method I often use to isolate problems of the software
(Cadence's bug)
from problems of installation/local cutomization etc. )

This will help you in finding out what commands are aliased ... (can you
unalais them.)

- good luck ...

-- G





"stefano zanella" <stefanoDOTzanella@pdf.com> wrote in message
news:116urd5blmgfdd0@corp.supernews.com...

Hi,

I have a set of ocean scripts that I run on an unknown environment
(i.e. on machines with IC installations that I do not own or control).
Sometimes common SKILL commands are aliased with other commands that do
not do the same thing (don't ask me why). Is there a way to run an ocean
script in such a way that those aliases do not affect the script being

run?

Thanks,
Stefano

 

[stefano zanella]

Hi Andrew,

Thanks a lot. Essentially, you are saying that there is no solution.
Does Cadence states this position officially, or is it something that is
known and that's it.

Is there a way to know if a function has been redefined?

A friend of mine, who used to work at Cadence, suggested that I may
try to reload all the context files that define functions I use. What do
you think?

Thanks again,
Stefano

Andrew Beckett wrote:

Hi Stefano,

It can be really frustrating when things like this happen. A little while ago
I spent some time working with a customer who was having problems with an
OCEAN script failing - they were trying to use ocnPrint with some of the
arguments that defined the precision and formatting - and it was falling over.

By a bit of luck (and a flash of inspiration) I found that the design kit they
were using redefined ocnPrint - and did not support all the keyword arguments
that it has done for several releases.

That's why I always recommend against redefining Cadence functions - the
caveat being "do it if you really know what you're doing, and don't complain
to us when things break...".

Andrew.

On Fri, 29 Apr 2005 15:54:29 -0700, Stefano Zanella
stefanoDOTzanella@pdf.com> wrote:


Hi,

Thanks a lot for your answer. Unfortunately, I have no control over
the environment which my ocean scripts are executed on. I also have no
way of knowing which commands are aliased (i.e. which functions have
been redefined) for the simple reason that my scripts are part of a tool
we sell. So, if they redefine a command and Artist breaks they just
think: "We have screwed up". If my tool (which runs on Cadence) breaks
because of that, now my tool does not work.

Regards,
Stefano

PS: I don't know why! Probably you are right: for a very good reason
that I simply fail to understand

G Vandevalk wrote:

.... why? (sorry ... I had to ask ... )

Typically large installations will have you run a wrapper setup script
overtop
of the tools in question. (Usually to point at where they install stuff and
setup
their license files ... and sometimes alias common commands ... to something
slightly different ... just to make you go crazy ... (actually they usually
have a
reason that does not apply in your case ... )

I have occasionally created a bare-bones script that only runs the tool and
as little
baggage as possible. (License files .. Cadence source only. ... )
This will not contain many site customizations that the local users want.
(plotting, libraries of custom devices etc. )
This is the method I often use to isolate problems of the software
(Cadence's bug)
from problems of installation/local cutomization etc. )

This will help you in finding out what commands are aliased ... (can you
unalais them.)

- good luck ...

-- G





"stefano zanella" <stefanoDOTzanella@pdf.com> wrote in message
news:116urd5blmgfdd0@corp.supernews.com...


Hi,

I have a set of ocean scripts that I run on an unknown environment
(i.e. on machines with IC installations that I do not own or control).
Sometimes common SKILL commands are aliased with other commands that do
not do the same thing (don't ask me why). Is there a way to run an ocean
script in such a way that those aliases do not affect the script being

run?


Thanks,
Stefano

 

[fogh]

Stefano,

you can test wether the func is an alias :
get(func 'alias)
wether it is a wrapper to a Cfunction :
bcdp(func)
wether it bears the info for finder etc:
plist(func)

The environments where your prog runs would have to be seriously
messed up if Cfunctions are redefined. You can trust they are plain vanilla.

A redefinition of cds functions using getd/putd will forget the
property list info, so you can detect a redefine with plist() this way.

The suggestion to load context is OK for you, but you will break
you-don-know-what because you replace all customised funcs by the
original ones globally. This may even break a tool that is
needed/cooperates with yours. You would in fact have to save the
customised definitions , load the contexts, run your stuff, and restore
the customised funcs on exit. And do this everytime one of your
functions is called. Probably doable, but it does not sound reasonable.

You say you have no control on the environment. You can at least give
in your tools docs and legal blurb the proper disclaimers, that your
tools will work only with the cadence original API. I don t remember
seeing it in the cadence docs, but it is common sense that it s a very
bad idea to redefine a cadence function. I myself gave up on the idea of
redefining simplifyFileName() , even if the temptation was great and I
could not foresee bad consequences.

Now, I am curious: what is that tool of yours ?


stefano zanella wrote:

Hi Andrew,

Thanks a lot. Essentially, you are saying that there is no solution.
Does Cadence states this position officially, or is it something that is
known and that's it.

Is there a way to know if a function has been redefined?

A friend of mine, who used to work at Cadence, suggested that I may
try to reload all the context files that define functions I use. What do
you think?

Thanks again,
Stefano

Andrew Beckett wrote:

Hi Stefano,

It can be really frustrating when things like this happen. A little
while ago
I spent some time working with a customer who was having problems with an
OCEAN script failing - they were trying to use ocnPrint with some of the
arguments that defined the precision and formatting - and it was
falling over.

By a bit of luck (and a flash of inspiration) I found that the design
kit they
were using redefined ocnPrint - and did not support all the keyword
arguments
that it has done for several releases.

That's why I always recommend against redefining Cadence functions - the
caveat being "do it if you really know what you're doing, and don't
complain
to us when things break...".

Andrew.

On Fri, 29 Apr 2005 15:54:29 -0700, Stefano Zanella
stefanoDOTzanella@pdf.com> wrote:


Hi,

Thanks a lot for your answer. Unfortunately, I have no control over
the environment which my ocean scripts are executed on. I also have
no way of knowing which commands are aliased (i.e. which functions
have been redefined) for the simple reason that my scripts are part
of a tool we sell. So, if they redefine a command and Artist breaks
they just think: "We have screwed up". If my tool (which runs on
Cadence) breaks because of that, now my tool does not work.

Regards,
Stefano

PS: I don't know why! Probably you are right: for a very good reason
that I simply fail to understand

G Vandevalk wrote:

.... why? (sorry ... I had to ask ... )

Typically large installations will have you run a wrapper setup script
overtop
of the tools in question. (Usually to point at where they install
stuff and
setup
their license files ... and sometimes alias common commands ... to
something
slightly different ... just to make you go crazy ... (actually they
usually
have a
reason that does not apply in your case ... )

I have occasionally created a bare-bones script that only runs the
tool and
as little
baggage as possible. (License files .. Cadence source only. ... )
This will not contain many site customizations that the local users
want.
(plotting, libraries of custom devices etc. )
This is the method I often use to isolate problems of the software
(Cadence's bug)
from problems of installation/local cutomization etc. )

This will help you in finding out what commands are aliased ... (can
you
unalais them.)

- good luck ...

-- G





"stefano zanella" <stefanoDOTzanella@pdf.com> wrote in message
news:116urd5blmgfdd0@corp.supernews.com...


Hi,

I have a set of ocean scripts that I run on an unknown environment
(i.e. on machines with IC installations that I do not own or control).
Sometimes common SKILL commands are aliased with other commands
that do
not do the same thing (don't ask me why). Is there a way to run an
ocean
script in such a way that those aliases do not affect the script being


run?


Thanks,
Stefano

 

[Andrew Beckett]

Frederic,

On Sun, 01 May 2005 00:18:42 -0400, fogh <adff@xs4all.nl> wrote:

Stefano,

you can test wether the func is an alias :
get(func 'alias)
wether it is a wrapper to a Cfunction :
bcdp(func)
wether it bears the info for finder etc:
plist(func)

This is only true if you've previously called help() or listFunctions() (I
think).

The environments where your prog runs would have to be seriously
messed up if Cfunctions are redefined. You can trust they are plain vanilla.

Yes, this would involve hacking the executable.

A redefinition of cds functions using getd/putd will forget the
property list info, so you can detect a redefine with plist() this way.

No it doesn't.

The suggestion to load context is OK for you, but you will break
you-don-know-what because you replace all customised funcs by the
original ones globally. This may even break a tool that is
needed/cooperates with yours. You would in fact have to save the
customised definitions , load the contexts, run your stuff, and restore
the customised funcs on exit. And do this everytime one of your
functions is called. Probably doable, but it does not sound reasonable.

When a context is loaded, it does not redefine any function that already
has a definition. This is one way people redefine Cadence functions, by
defining it .

Also, you can't reload a context already loaded. You get the following:

*WARNING* (loadContext): context schView already loaded
nil

(the nil indicates that the loadContext didn't do anything).

So this approach will not work.

You say you have no control on the environment. You can at least give
in your tools docs and legal blurb the proper disclaimers, that your
tools will work only with the cadence original API. I don t remember
seeing it in the cadence docs, but it is common sense that it s a very
bad idea to redefine a cadence function. I myself gave up on the idea of
redefining simplifyFileName() , even if the temptation was great and I
could not foresee bad consequences.

I would suggest giving a warning to this effect somewhere.

Now, I am curious: what is that tool of yours ?

Take a look at http://www.pdf.com and
http://www.cadence.com/partners/connections/member.aspx?member=member_PDFSolutionsInc

Now to Stefano's question to me:

stefano zanella wrote:
Hi Andrew,

Thanks a lot. Essentially, you are saying that there is no solution.
Does Cadence states this position officially, or is it something that is
known and that's it.

I think this is common sense - I'm not sure it's stated anywhere (it may be).
I think if you're hitting this problem, then you should tell the customer that
redefining standard Cadence functions is asking for trouble!

Is there a way to know if a function has been redefined?

I don't think so....

A friend of mine, who used to work at Cadence, suggested that I may
try to reload all the context files that define functions I use. What do
you think?

No - see my response to Frederic above.

Regards,

Andrew.

 

[fogh]

Andrew Beckett wrote:

Take a look at http://www.pdf.com and
http://www.cadence.com/partners/connections/member.aspx?member=member_PDFSolutionsInc

Circuit surfer. Nice if you have the proper data in the design kit.
But these are definitely a worthy improvements for designers:
- DOE techniques, Hadamar and Taguchi tables rather then simplistic
"corners" and "worst case" sweeps.
- sensitivity to process parameters rather than CPU costly Monte-Carlo
runs.

Now to Stefano's question to me:
stefano zanella wrote:

Hi Andrew,

Thanks a lot. Essentially, you are saying that there is no solution.
Does Cadence states this position officially, or is it something that is
known and that's it.



I think this is common sense - I'm not sure it's stated anywhere (it may be).
I think if you're hitting this problem, then you should tell the customer that
redefining standard Cadence functions is asking for trouble!


Is there a way to know if a function has been redefined?


I don't think so....


A friend of mine, who used to work at Cadence, suggested that I may
try to reload all the context files that define functions I use. What do
you think?



No - see my response to Frederic above.

Sorry if I lured Stefano. I found that plist() worked in certain cases,
but it indeed does not in general. It seems he has not much choice apart
from fixing things adhoc , convincing the client to use uncustomised IC
, or rewriting all with Cfunctions.

 

[David Cuthbert]

Andrew Beckett wrote:

Is there a way to know if a function has been redefined?
I don't think so....

Indeed, I took a look at the SKILL source, and there's no marker bit
whatsoever. Not that I expected to find one... SKILL truly is a general
purpose language, and Cadence's (non-binary) SKILL functions are no
different from anyone else's. Ask it to shoot yourself in the foot...
it'll gladly oblige. (when (footp obj) (shoot obj)) ...

I can empathize with Stefano all too well. I wish I had an extra
vacation day or two for every broken PDK I've had to support, requiring
me to mutilate some code just to push things along. Stuff like
redefining fboundp (yes, I've done this). There's no generic way around
this, either -- every PDK is broken in its own special way.

And, lest you think that it's all golden on the Cadence side of the
fence... heh, no. I've heard of a case where we had to supply a
special DFII build which lied about its version number because a
customer absolutely, positively, had to have some feature, but their PDK
couldn't cope with seeing a different version number. As always, a
tapeout deadline was looming...

 

[Stefano Zanella]

Hi All,

Thanks a lot for the sympathy, nice words and good advice. Now I know
what I can and what I can't do.

It also good to know that I am not alone and that there are a lot of
sympathetic people

Thanks so much for all the help,
Stefano

PS: Andrew, do you remember taking training on Circuit Surfer 3 years ago?




fogh wrote:

Andrew Beckett wrote:

Take a look at http://www.pdf.com and
http://www.cadence.com/partners/connections/member.aspx?member=member_PDFSolutionsInc



Circuit surfer. Nice if you have the proper data in the design kit.
But these are definitely a worthy improvements for designers:
- DOE techniques, Hadamar and Taguchi tables rather then simplistic
"corners" and "worst case" sweeps.
- sensitivity to process parameters rather than CPU costly Monte-Carlo
runs.


Now to Stefano's question to me:

stefano zanella wrote:

Hi Andrew,

Thanks a lot. Essentially, you are saying that there is no
solution. Does Cadence states this position officially, or is it
something that is known and that's it.



I think this is common sense - I'm not sure it's stated anywhere (it
may be).
I think if you're hitting this problem, then you should tell the
customer that
redefining standard Cadence functions is asking for trouble!


Is there a way to know if a function has been redefined?



I don't think so....


A friend of mine, who used to work at Cadence, suggested that I may
try to reload all the context files that define functions I use.
What do you think?



No - see my response to Frederic above.


Sorry if I lured Stefano. I found that plist() worked in certain cases,
but it indeed does not in general. It seems he has not much choice apart
from fixing things adhoc , convincing the client to use uncustomised IC
, or rewriting all with Cfunctions.

 

[G Vandevalk]

"fogh" <adff@xs4all.nl> wrote in message
news:42753249$0$15623$e4fe514c@news.xs4all.nl...

Andrew Beckett wrote:

Take a look at http://www.pdf.com and

http://www.cadence.com/partners/connections/member.aspx?member=member_PDFSolutionsInc

Circuit surfer. Nice if you have the proper data in the design kit.
But these are definitely a worthy improvements for designers:
- DOE techniques, Hadamar and Taguchi tables rather then simplistic
"corners" and "worst case" sweeps.
- sensitivity to process parameters rather than CPU costly Monte-Carlo
runs.

I think you mean Hadamard Tables for Taguchi method of DesignOfExperiment.
This assumes that the process parameters you are attempting to characterize
are orthogonal. (unlikely)

(in other words ... if you measure orthogonal (unrelated) process parameters
in several experiments,
you can isolate their contributions quicker!)

I find that if you work with a process that the Fab has already isolated the
orthogonal components
to be much more efficient.

(in other words .. I prefer when the POLY sizing is the same as the
GATE-LENGTH variation and
it is the same as a parameter in POLY-RESISTOR rho since the driving factor
is the same physical
input. When these directly correlated parameters are monte-carlo-ed (to
pick a bad new verb) separately,
we now get a rms bloat of parameters.

Then again, not all fabs have nice monte carlo input numbers.

YMMV

-- G

 

[Stefano Zanella]

Hi,

We use Taguchi (among others). We called them Process+Design
experiment (we used to call them Taguchi, but Cadence didn't like it
). As G. points out, it is hard to measure orthogonal parameters.
However, there are techniques to produce statitical SPICE models that
contain orthogonal parameters. I will stop here, as this forum is not
meant for advertising, but feel free to write me personally if you want
to discuss more.

Regards,
Stefano

G Vandevalk wrote:

"fogh" <adff@xs4all.nl> wrote in message
news:42753249$0$15623$e4fe514c@news.xs4all.nl...

Andrew Beckett wrote:


Take a look at http://www.pdf.com and


http://www.cadence.com/partners/connections/member.aspx?member=member_PDFSolutionsInc

Circuit surfer. Nice if you have the proper data in the design kit.
But these are definitely a worthy improvements for designers:
- DOE techniques, Hadamar and Taguchi tables rather then simplistic
"corners" and "worst case" sweeps.
- sensitivity to process parameters rather than CPU costly Monte-Carlo
runs.



I think you mean Hadamard Tables for Taguchi method of DesignOfExperiment.
This assumes that the process parameters you are attempting to characterize
are orthogonal. (unlikely)

(in other words ... if you measure orthogonal (unrelated) process parameters
in several experiments,
you can isolate their contributions quicker!)

I find that if you work with a process that the Fab has already isolated the
orthogonal components
to be much more efficient.

(in other words .. I prefer when the POLY sizing is the same as the
GATE-LENGTH variation and
it is the same as a parameter in POLY-RESISTOR rho since the driving factor
is the same physical
input. When these directly correlated parameters are monte-carlo-ed (to
pick a bad new verb) separately,
we now get a rms bloat of parameters.

Then again, not all fabs have nice monte carlo input numbers.

YMMV

-- G

 

[Andrew Beckett]

On Mon, 02 May 2005 11:13:42 -0700, Stefano Zanella
<stefanoDOTzanella@pdf.com> wrote:

PS: Andrew, do you remember taking training on Circuit Surfer 3 years ago?

Certainly! I was quite impressed with the tool (although I think I raised a
few (minor) potential problems ;-> if I remember rightly). Is Bill Nye still
with PDF? If so - say hi to him from me...

Andrew.

 

[fogh]

David Cuthbert wrote:

Andrew Beckett wrote:

Is there a way to know if a function has been redefined?

I don't think so....


Indeed, I took a look at the SKILL source, and there's no marker bit
whatsoever. Not that I expected to find one... SKILL truly is a general
purpose language, and Cadence's (non-binary) SKILL functions are no
different from anyone else's. Ask it to shoot yourself in the foot...
it'll gladly oblige. (when (footp obj) (shoot obj)) ...

ROTFL

better implemented with triggers, of course:

dacutTwitchTwitch=lambda((obj)
(when (footp obj) (shoot obj))
)

aaAddEventCB("il-hard-core:foot-in-sight"
dacutTwitchTwitch 1 ?safe nil)

 

[Andrew Beckett]

On Thu, 05 May 2005 21:34:06 -0400, fogh <adff@xs4all.nl> wrote:

aaAddEventCB("il-hard-core:foot-in-sight"
dacutTwitchTwitch 1 ?safe nil)

(when (uses 'frederic 'privateFunction)
(give "stern ticking off")
)

 

[fogh]

Andrew Beckett wrote:

On Thu, 05 May 2005 21:34:06 -0400, fogh <adff@xs4all.nl> wrote:


aaAddEventCB("il-hard-core:foot-in-sight"
dacutTwitchTwitch 1 ?safe nil)


(when (uses 'frederic 'privateFunction)
(give "stern ticking off")
)

tk tk tk ...

The naming convention for customer first name is a capital prefix thus :
while( not(member('Frederic TopBigTenCorpsWhoHappilyMisusePVTFuncs)) && (uses
'Frederic 'privateFunction)
callNextMethod()
)

 

[John Gianni]

fogh wrote:

tsk tsk tsk ...
The naming convention for customer SKILL function is a capital prefix

You know the message has gotten across when it finally shows up in
programmer jokes.

Back on topic, the best way to 99.99% determine if you've re-defined
any Cadence production (documented or otherwise) function is simply to
run a five-minute SKILL SURVEY (CIW: Tools->SKILL Development->SKILL
Surveyor)!

Why?

Because the SKILL Survey compares your list of functions with EVERY
SINGLE Cadence DFII function shipped on a Virtuoso CDROM (no matter
where it's defined, whether it be in a context or an IL file or defined
in binary code).

In addition, Cadence is adding the SKILL defined in other software
CDROMs, e.g., the former Neolinear analog synthesis and QTrek layout
migration tools) to the SKILL Survey as we type.

The SKILL Survey (currently free to product #900 licensees on
maintenance) mechanism compares every function you defined to those
functions to let you know which functions were redefined Cadence
functions for every release of DFII up to and including releases to be
shipped next year (i.e., IC6061).

I don't know of any other way that is more efficient or accurate than
the five minutes it takes to run a SKILL Inventory and SKILL Survey to
tell which Cadence functions you've (accidentally or on purpose)
redefined.

John Gianni
--
Nothing whatsoever I post here is prior sanctioned by my employer.

 

[John Gianni]

John Gianni wrote:

... the best way to determine if you've re-defined ...
any Cadence production function is simply to ...
run a five-minute SKILL SURVEY ...

I should note the 5-minute SKILL Survey helps you much more than just
telling you which functions you've defined which are already defined in
a version of Cadence software that you may or may not yet even own.

The 5-minute SKILL Survey (which was designed & developed by Andrew,
Iain, me, and others) also gives you a fantastic inventory of your
SKILL!

For example, the first part of the SKILL Survey reports to you:
- Every SKILL function you've defined
- Every SKILL function you've called
- For every function defined, which file it was defined in
- For every function called, which file called it
- Every function you defined but never called
- Every function you defined and called and how many times called
- A summary file which can be sent to Cadence if you so choose
etc.

If you choose to have the data further analyzed, you receive:
- A list of functions you defined yet were already defined by Cadence
- A list of functions you called which nobody defined (not you nor
Cadence)
(this happens all the time due to your code dependencies or mistakes)
- A list of functions you called which are not documented or supported
- A pie chart, colorized to show the percentages of various functions
- The list of functions you called which are public and supported
- The list of functions you called which have changed between releases
(note this covers releases that will be shipped next year to give you a
head start on any changes expected so you better plan your resource
efforts)
- The description of the changes to each of those changed functions
- The list of functions you called which were deleted between releases
- The description (if available) of how to recover from those
deletions,
etc.

In short, I'd like to suggest everyone who has product #900 (SKILL
Developemnt Environment) on maintenance run a quick 5-minute SKILL
Survey today just for themselves and report back to comp.cad.cadence
what you found interesting ... and if you so choose ... send in the
non-proprietary summary file to Cadence (press the button for that
purpose) and you'll receive by return email even more wonderful
information.

Please post back to comp.cad.cadence whether or not you see value in
the results given the effort expended.

John Gianni
--
Nothing I post here is prior reviewed by my employer!