Skill-C interface

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

 

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.

 

After moving to OpenAccess (in future) will we still have Integrators
Toolkit.
If so, why?

Thanks.

regards,
Suresh J

 

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.

 

1. Compatibility - there will be existing code; we can hardly expect customers
to completely rewrite their code.
2. Simplicity - the CDBA interface is probably simpler than the OA interface.

But it would be mainly issue 1 above. I'd expect new applications to be written
using the OA API.

Andrew.

 

A few years ago I had to write a separate C++ program to get around some of
the limitations of SKILL, and then call that program from SKILL. In
particular, SKILL/Cadence crashed when I tried to create a hash table of
several hundred thousand x/y points. Also, I couldn't find any way of
performing bit-level operations in SKILL such as bitshifts, bit masking,
etc. In fact I think skill uses 32 bits in all integers, even when I only
need to store an 8-bit value, and that's 4X memory overhead. I eventually
had to implement the layout database and gometry query functions into my C++
program to aviod writing I/O files of many MB. Now the program is
independent of Cadence, but I wonder if all that work was really worth it.

Oh, and as a side note, is there any way to create a small bitmap image in
Cadence other than building it from single pixel rectangles on the
multi-colored "y0" - "y9" layers in the LSW? It takes a really long time to
do this in SKILL.

Frank

 

<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.

 

Frank,

functions such as bor, band - which are equivalent to operators | and &. Also
bnand, bnor, bxor, bxnor (operators for each of these too).
leftshift, rightshift (<< and >>).
The bitfield, bitfield1 functions as well are useful. These are equivalents
of doing something like:

a=1234
a<4:2> => 4
a<4> => 1
a<<1 => 2468
a>>2 => 308
a&10 => 2
a|5 => 1239
a^2 => 1232 (xor)

Bet you didn't know you could do that ;-(

They're all documented, and have been there for as long as I can remember.

Depends what you want to use the bitmap for. If it's for menu items, icons
etc in DFII, then hiStringToIcon and related functions would help. Some of the
^dl (displayList) functions can be used too (don't get used much, but can be
quite handy).

Andrew.

 

Hi all,
SKILL is slow especially when processing long long lists.
example I want to go through each shape in a list of some millions of
shape to do some processing... I found that doing it in C(ITKDB) is much
faster than SKILL. I can use ITKDB for writing stand alone
tools/functions but as Andrew said thats not what I want.
Mainly what I am looking for is...when I am in df2 session, already most
of the information is in virtual memory...so as data is available
through df2, I just need to write functions in c to operate on it,
instead getting data again using ITKDB.
I am looking for something similar to inline C module for perl, so that
I can access c functions in a perl module..
I dont know how tough it is to provide that type of feature for cadence
and maintain it. Because, we can see that TCL and PERL they all can
handle C functions.And they work pretty well. I have a feeling that
many people need this type of functionality.
BTW, Frank! you said you wrote a C++ function few yrs back and called
it from SKILL, may I know how did u write? did you use ItkDB or IPC or
something else?
Thanks for your responses
Sampath

 

Thanks Andrew.

I didn't know about the bitfield operators and wish I had known about them
earlier. I just tried '&', '|', and '^', and similar operations which didn't
work as intended and no one in my office knew how to do these types of
things.

The bitmap is different. It's for visualization of shapes overlaid on the
gometry. I'm working in lithography, so I would like to overlay images such
as simulation results of printed shapes over the original layout shapes in
Virtuoso. I'm also working on image/pattern matching, so I'm overlaying
approximate images with complex features (pixel accurate curves) onto the
layout. I could probably also do this by taking a screenshot of a layout and
combining that with the image in a graphics program, but then I have to do
everything by hand instead of using the power of SKILL. It works in SKILL,
it's just so slow to create a 128x128 image with 16,384 rectangles on
various layers.

Frank

 

Sampath,
I wrote a program in C++ that read and input file, processed the
geometry, and wrote an output file. I wrote the input file in SKILL using
the usual printf, then called my program with system("my_program file.in
file.out"), then read the output back into SKILL with scanf. That's all I
did, nothing fancy. It seemed to work well until I ran into large I/O files.

Frank

 

It does depend heavily on how you write the code though - there are good ways
and bad ways of dealing with lists of data to avoid excessive creation and
destruction of list cells (i.e. you don't want to spend all your time in garbage
collection).

That said, we are looking at ways of avoiding the list creation in the first
place (but this is just an idea for a future release - we need to see if there
is really a performance benefit).

Comparing with perl is not entirely fair, because providing a SKILL-C interface
would not be that hard - but almost certainly that would not be enough. People
would want to be able to define their own object types (and this has to be done
at initialisation time, I think), and be able to access all the other data types
already existing in SKILL, and access the graphics, and access the UI, and
access the database, etc. That's what would make it costly to do. Not the
relatively simple SKILL-C interface.

Regards,

Andrew.

 

Hi Frank,

I thought last night after appending about something else I meant to mention,
which is that the underlying hash package was re-implemented by R&D for
the IC5033 release, and it solves some bugs and is much better performing too.

I see the problem for the bitmap processing. One idea might be to create all the
shapes once (on a fixed layer), and then you just need to go through them all
and change the layer to the layer you want. Probably what I'd do is:

for(x 0 127
for(y 0 127
rect=dbCreateRect(cv "y0" list(x:y x+1:y+1)
rect~>myCoord=x:y
)
)

Then when you come to use these at some later point, you might want to build
a hash table to speed lookup of each rectangle:

shapeLookup=makeTable('shapeLookup nil)
y0=car(exists(lpp cv~>layerPurposePairs lpp~>layerName=="y0")))
foreach(shape y0~>shapes
shapeLookup[shape~>myCoord]=shape
)

And then you can go through and do things like

shapeLookup[10:15]~>layerName="y2"

which would be much quicker than recreating each time.

Note the above code is not tested in anyway - just pseudo-skill code.

Andrew.

 

Well it's over 10 years since I did ITK training so my memory
of the CDBA API is a bit vague, but I'd say OpenAccess
is a hell of a lot simpler and cleaner. OA has a well structured
C++ interface and is generally well thought out. And being
open source it compiles on most things, even Windows

- Keith

 

Keith,

Nice to hear from you!

I must admit after writing that, I had second thoughts, and I'd agree the ITK
API is a bit tricky. The main problem is really with the documentation, or lack
of it. It always looks like you're seeing just part of the story - again
probably because there aren't that many customers who use it, and it's never got
the attention it deserved.

OA was designed to be public and open from day one, and also having a C++
object model simplifies writing code - it's much more regular.

So I take back my second point, but I'll certainly stick with the first point -
compatibility. That's why the SKILL API has also remained - compatibility was
absolutely key for migration because of the enormous amount of SKILL code
out there (far, far more than ITK).

Andrew.

P.S. Liked Rob Baker's video on www.cadence.com ;-)

 

Andrew,
Thank you for the example code. I'm using an older version of Cadence
(4.4.6), so it has the slow hashtables. As for the bitmaps, I think all of
the time is spent in the dbCreateRect() call, so it should be better to
create the bitmap once and just change the pixels. However, if I save a
layout with many of these bitmaps the file size is huge. I can save space by
calling leMergeShapes() on the rectangles, which combines them into
polygons. Since there are typically only 2-4 colors used, there are many
large groups of rectangles in the same layer. LeMergeShapes() can actually
take longer than creating the rectangles in the first place sometimes when
several of the images overlap. Perhaps I should try to create polygons or at
least larger rectangles of several pixels in the first place, instead of a
full array of pixel-sized rectangles.

Frank

 

i haven't read the whole thread, sorry if i am repeating.

there is a functionality that may help you i think.
you can launch a process with ipcSkillProcess (that process would be you c
program).
when using this function, two additional channels are open, in addition on
stdin stdout stderr, for your program. they have file handle 3 and 4 i think
these special channels allow you to communicate with the skill code that
launched the process. precisely, you can write skill code to those
channels that will be executed in cadence and you can read the results
in the other channel.
this may allow you to communicate through global variables or through
function calls.

here is an example c code from cadence doc:
/*********************************************** Sample process for
executing SKILL commands* in parent
process.**********************************************/#include
"stdio.h"#define skill_cmd 3#define skill_result 4main(int argc, char
**argv){ int status; char s[100]; sprintf(s, "%s", "(let ()
(println \"Hello world \") (1 + 1))"); printf("Executing %s", s);
fflush(stdout); status = write(skill_cmd, &s[0], strlen(s)); status =
read(skill_result, &s[0], 100); s[status] = '\0'; printf("Result =
%s", s); fflush(stdout); exit(0);}hope this helps,stephane

 

There is a thing called "SWIG" in the opensource world that does that
for lisp-to-C interfacing. I believe it doesn t solve you problem with
lisp, though.
I would be also really interested to be able to call from skill the
functions from libEMF.so , but I am not really interested in
performance, so another solution, like a C-to-skill compiler, could do.