Re: Skill-C interface

<getOutClause>
What follows is entirely my personal opinion, and not any official view from
Cadence - the same as everything else I post here.
</getOutClause>

The number of people who want to do this kind of thing these days
to commercial tools is not that great - we don't get that many requests for
this - and it's not just because it can't be done right now.

Also, there's the whole issue of stability when you've got external libraries
linked in.

I'm not saying it would be impossible, or useful, just I'm not convinced it's
worth the bang for the buck.

DFII is already incredibly customisable, and there's a huge amount you can
do with the tools as they stand, using a customisation language that is
generally pretty safe; you don't need to worry about memory allocation and
scribbling on bits of memory you shouldn't because SKILL takes care of that
for you.

Now giving people flexibility is one thing - it actually presents a big issue
for Cadence in terms of maintainability and ability to migrate to later
releases; we have to be exceedingly careful about compatibility between
releases. We don't always get it right, but in general I think we do quite
a reasonable job (and there have been big efforts to improve in this area).

Adding a C level interface adds to the danger and would make the requirements
for migration even harder, because there are all sorts of places that people
would want hooks for their particular application. For example, you're not just
talking about calling a C function to do some computation - you presumably
would want hooks into the graphics engine at various layers for your
code to work well. Someone else would want hooks to the database, others
to build forms, others to results post processing. We'd end up having to
develop (or make public) a huge API at the C level for a _very_ small
number of users. Making it public is one thing - it needs to be documented,
maintained (for migration), tested as a public API. A huge cost. We have
over 5000 public SKILL functions to do particular things - would we end
up having to have a similar number of public C functions? Quite possibly...

It would be neat to be able to do all these things, I know.

I'm sure most customers would sooner we spent money on improving the tools
and adding functionality to deal with modern technology issues, and living with
the pretty enormous amount of customisation that can be done right now.

Regards,

Andrew.

On 25 Nov 2003 01:53:15 -0800, [EMAIL PROTECTED] (Rajeswaran M) wrote:

>I dont think "it is rarely necessary". Currently it looks rare because
>of the current limitations.
>
>If there is a flexiblity of accessing highly core level functions,
>through "C" code,  lot of useful open source would come up. For
>example there is no functions in DF2 UI skill to draw and move ghost
>image of a object, along with the mouse pointer. However I wrote a
>skill + C code using hilite layers and ipc function calls, but the
>cost of it is 90% CPU time to draw that ghost image.
>
>Andrew Beckett <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
>> You could use the Integrators Toolkit (ITK-DB). This allows you to write
>> standalone applications which access the database from C, and there is some
>> (limited) support for invoking SKILL from this.
>> 
>> However, I suspect this is not what you want. You can't (for example) link in
>> some C code with DFII and call that from SKILL (we don't support that, for
>> a variety of reasons - one being that it is rarely necessary). What you can do
>> however is to write your computationally intensive tasks in a separate program,
>> which you can then invoke using the ipc function calls (e.g. ipcBeginProcess),
>> and then communicate to that external program either synchronously or
>> asynchronously. This can be quite an effective means of doing things outside.
>> 
>> What sort of intensive operations are you talking about? SKILL can be pretty
>> quick provided that you do things correctly (it's byte-code compiled,
>> and runs on a virtual machine).
>> 
>> Regards,
>> 
>> Andrew.
>> 
>> 
>> On Mon, 24 Nov 2003 15:20:13 -0700, sampath <[EMAIL PROTECTED]> wrote:
>> 
>> >Hi,
>> >is there anyway that i can mix skill and c code,
>> >I am looking for a way to do some runtime intensive operations in c and 
>> >get the data into a skill code?
>> >can somebody tell a solution?
>> >sampath

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd