Q: SKILL++ , how can I enumerate all methods of a generic fu

[fogh]

also when the method is for a system class (like number, string ...)

I really wonder

 

[fogh]

Andrew Beckett wrote:

also when the method is for a system class (like number, string ...)

I really wonder


I have a little macro which uses a private function to do this, and also
discovered that there is already a private function which is pretty close.

One of my colleagues filed this enhancement PCR:

PCR: 765646
Title: need to get methods from a generic function

When you say "enumerate" what do you mean? Do you mean that you want to find
the names of the classes which have methods for the specified generic
function?

Not really, let 's say that I actually know the classes already, and that
there are some non-instanciatable classes. Knowing that, how do I get the methods ?

Also, what do you want this for? Good practical reasons always help influence
the likelihood of this being implemented. That said, the implementation is
mainly a case of providing a public wrapper or alias for the internal function
(it is not named appropriately for a public function), and the documentation
effort.
I want this so I can do very nasty things to oasis. I found lately that I do

not like so much the asi.*Error methods, and I would like to see what they are
made of. I want to customise some field checks in ADE. For example:
- transient stop time can be a design variable, a plain skill variable, or a number
- same with spot frequency in AC sweep on a design variable
- reference instances (ports in transfer analysis, noise reference port, etc
....) can be in an included netlist.


If you do not disapprove to much, I would appreciate to get that macro !



BTW, what is the future for ADE ? I sometimes heard rumors that it is nothing
but a dying horse and that we should all jump in aptivia

 

[fogh]

Andrew Beckett wrote:

On Thu, 03 Feb 2005 00:22:05 -0500, fogh <adff@xs4all.nl> wrote:


also when the method is for a system class (like number, string ...)

I really wonder


I have a little macro which uses a private function to do this, and also
discovered that there is already a private function which is pretty close.

One of my colleagues filed this enhancement PCR:

PCR: 765646
Title: need to get methods from a generic function

So getmethod() will become public ?

What about variable ? Is there a way to request, for instance, that
oblist becomes public ?

 

[fogh]

I think that's fairly unlikely, as it could limit our ability to change low
level implementation details. Also, it's questionable as to what you'd use
this for (legitimately).
Getting out of design trouble ?

When PDK or integrated simulator misbehaves and the client should not
care about this kind of thing but onloy deadlines, is it legitimate to
do a listdiff on oblist between before and after initialisation of PDK
(or simulator) ?

You are competent Andrew. Just illustrate for me where the line is and I
will take it as a golden rule.

 

[Andrew Beckett]

On Tue, 15 Feb 2005 00:44:02 +0100, fogh <adff_at@xs4all_dot.nl> wrote:

I think that's fairly unlikely, as it could limit our ability to change low
level implementation details. Also, it's questionable as to what you'd use
this for (legitimately).
Getting out of design trouble ?
When PDK or integrated simulator misbehaves and the client should not
care about this kind of thing but onloy deadlines, is it legitimate to
do a listdiff on oblist between before and after initialisation of PDK
(or simulator) ?

You are competent Andrew. Just illustrate for me where the line is and I
will take it as a golden rule.

Well, if reverse engineering someone else's IP which they have protected (or
at least obfuscated) by creating an context file is something you think is
ethical, then that's up to you...

You're relying on an implementation feature of the language, which we ought to
be free to change. If we document something like this, it rather limits our
options in the future.

Mostly the reason for SKILL API functions being public (and documented) are:

a) they are useful to customers
b) they are supportable

Private functions are private for the opposite reasons - often they don't do
enough checking, they require internal data structures, and they are part of
the low level implementation. Clearly we cannot ensure that all 50,000 odd
functions in DFII keep the same argument list and behaviour from release to
release, otherwise nothing would ever change. So a reasonable, practical,
subset should be public.

If there is a need for a public function for something that isn't there right
now, we can always ask for one. That said, I often see customers (not so often
the customers I deal with in Europe) asking for Cadence to provide a function
that can be written in a few lines of code, and often for something that is
rather specific to their needs. My objection here is - write your own library
functions! I have built up a collection over the years of functions that I
reuse over and over again, for things that do generally useful things, but I
wouldn't expect Cadence to provide them for me.

Sorry, I rather wandered off topic there, but just wanted to say it...

Regards,

Andrew.

 

[fogh]

Andrew Beckett wrote:

On Tue, 15 Feb 2005 00:44:02 +0100, fogh <adff_at@xs4all_dot.nl> wrote:


I think that's fairly unlikely, as it could limit our ability to change low
level implementation details. Also, it's questionable as to what you'd use
this for (legitimately).

Getting out of design trouble ?
When PDK or integrated simulator misbehaves and the client should not
care about this kind of thing but onloy deadlines, is it legitimate to
do a listdiff on oblist between before and after initialisation of PDK
(or simulator) ?

You are competent Andrew. Just illustrate for me where the line is and I
will take it as a golden rule.


Well, if reverse engineering someone else's IP which they have protected (or
at least obfuscated) by creating an context file is something you think is
ethical, then that's up to you...

You're relying on an implementation feature of the language, which we ought to
be free to change. If we document something like this, it rather limits our
options in the future.

Mostly the reason for SKILL API functions being public (and documented) are:

a) they are useful to customers
b) they are supportable

Private functions are private for the opposite reasons - often they don't do
enough checking, they require internal data structures, and they are part of
the low level implementation. Clearly we cannot ensure that all 50,000 odd
functions in DFII keep the same argument list and behaviour from release to
release, otherwise nothing would ever change. So a reasonable, practical,
subset should be public.

If there is a need for a public function for something that isn't there right
now, we can always ask for one. That said, I often see customers (not so often
the customers I deal with in Europe) asking for Cadence to provide a function
that can be written in a few lines of code, and often for something that is
rather specific to their needs. My objection here is - write your own library
functions! I have built up a collection over the years of functions that I
reuse over and over again, for things that do generally useful things, but I
wouldn't expect Cadence to provide them for me.

Sorry, I rather wandered off topic there, but just wanted to say it...

Andrew,

If we could not let some steam off, it wouldn t be a proper news feed
That is pretty much on-topic, and gives me part of the answer. You have
built over the years a library/API for your needs that relies on
features that are not garanteed to keep the same shape and flavour. And
you know they can be useful to customers, because they ask for such library.

As for IP and reverse engineering... I try to keep a no-nonense
approach to this. The business of a partner/customer/provider defines
what is critical IP and what is not. I am convinced that some companies
write SKILL and then obfuscate it not because it is critical IP, but for
the opposite reason: it is a side-activity, and they want to spend as
little as possible on it. Obfuscation then gives them the ability to
hide the dirty laundry, and at the same time limit the risk of user
customisation and change requests. But if they are exposed to the
consequence of incomplete/faulty code in a PDK in terms of risk for the
tape-out, or shown how a missing feature in a custom application affects
design productivity, they just give you "carte blanche" for any reverse
engineering of what is not their core-business.

 

[Andrew Beckett]

On Sun, 20 Feb 2005 22:56:23 +0100, fogh <adff_at@xs4all_dot.nl> wrote:

If we could not let some steam off, it wouldn t be a proper news feed
That is pretty much on-topic, and gives me part of the answer. You have
built over the years a library/API for your needs that relies on
features that are not garanteed to keep the same shape and flavour. And
you know they can be useful to customers, because they ask for such library.

Actually my library of functions for doing various higher level things doesn't
generally rely on things that are not guaranteed to keep the same shape and
flavour. Occasionally I'll write something around a private function as a
short-term fix, but for the most part, my code uses public functions. I have
library functions that I wrote 10 years or more ago which are still useful,
and have not needed any changes in the meantime (sometimes I've enhanced them,
but I've not had to change them because Cadence changed things).

That's precisely why I was involved (along with our friend John Gianni, and a
number of others within Cadence) in a big effort a few years ago to clearly
define what was private and what was function, and set rules and checks such
that R&D don't delete or change (in an incompatible way) the public API. These
rules mean that SKILL code is generally portable to new releases with no
change. Of course, occasionally an API is removed (because the underlying tool
was end-of-lifed and removed), and occasionally a change _has_ to happen - but
these are rare events. SKILL Lint rules, or the "SKILL Advisor" tool in the
SKILL Development toolbox should help inform of those changes and the
necessary changes needed to customer code.

Regards,

Andrew.