writing a GUI (in Java/Tcl) to run SKILL commands

Frustrated by the archaic front-end of analog artist I'm seriously
considering making a GUI interface which will suit my specific
simulation needs. I've kind of made SKILL forms before and I consider
the GUI ability of SKILL to be archaic as well, so I would like to see
about the possiblity of using some other language like Java or Tcl for
this? Question is does anybody have any experience on how to do this?
How do I execute SKILL Functions and translate SKILL datatypes etc
between Java and SKILL? Any ideas? Any example code would also be
appreciated.

thanks,
Jose.

 

Jose,

Here is what you need I've used this to create a K2 verification GUI

http://ic.net/~cflynt/realprog/realwrld/nelson/nelson1.htm

--


\ ~ ~ ///
---- ( @ @ )
| | ======oOOo==(_)==oOOo=======================================
| |__<*> ___ Tracy Groller | Texas Instruments, Inc.
| _|III|_ | ------------------| Wireless RFCMOS Design
_____| /_ III _/ \ TI MSGID: TAG2 | P.O. Box 660199, MS 8729
\_ /III/ | PC Drop: PFLL | Dallas, Texas 75266
\ _ /III/ _| -------------------------------------------------
\_/ \ \___> - Phone: (214) 480-2217 Text Pager
\ / Email:
\ \ =======================================================
\---\

 

Thanks a lot, Tracy. Looks like the exact thing I was looking for.

Jose

 

Don't forget to look at groups.google.com
http://groups.google.com/group/comp.cad.cadence/browse_thread/thread/302
8fde59540881b/bd3587b3f1cb96aa?q=executing+skill+code&rnum=2
#bd3587b3f1cb96aa
for Andrew's solution to the problem.

You want to join efforts? It makes no sense that several people develops
"a better interface" separately.

Can anybody from Cadence say something if they are reworking the ADE
concept in the near or close future?

 

Maybe this helps you also, I've not been through it but
it seems promising.

Tcl/Tk and Skill by Andreas Kulik

www.cadence.com/community/allegro/resources/resources_PCB/SKILL/tp_tclskill_icu2003.pdf

Bernd

 

There is some stuff going on in this area. Can't say more in an open forum.

Andrew.

 

8-o

Quite impressive, Tracy.

 

In case someone tries the above code out (
http://ic.net/~cflynt/realprog/realwrld/nelson/nelson1.htm )
Just one minor mistake (or did I miss something?) on the code in
"skill.tcl" seems to be the line...
regsub -all "%v" $response "\[skill::ilDecode %v\]" response

should be replaced with the following ...
regsub -all "%v" $response [skill::ilDecode %v] response

which I being a tcl novice took about an hour to figure out....

 

Andrew,

If the developments that are not 100% certain/aproved can not be
announced here, where do we have to go ?
Are there "proper channels" for announcements on SL or on the
corporate site ?

 

Announcements will be made nearer to release dates - like with any
product development, you don't start talking about it too early, especially if
some features don't make the final cut. So it's not on sourcelink or the
corporate site either yet. Have to be patient, I'm afraid!

Just because I work for Cadence, doesn't mean that I'm allow to disclose
internal things!

Andrew.

 

<smile on>
This is in great contradiction with the business model of Microsoft.
They announce new features years in advance and "leak" internals that
keep customers happily waiting forever, only to implement a reduced
version of their promises with the promise that it will be improved for
the _next_ release. What is the position of Microsoft vs. Cadence in
their respective market segments?
<smile still on>

 

Still, I think there is a nice balance between "false hope" (Microsoft)
and "no hope" (Cadence) with regard to revealing the future direction
of products to customers. I'm not exactly sure how Cadence works with
Customer feedback on enhancements to its products. I see a whole bunch
of PCRs which seems to be going into this bottomless hole. I have no
idea how Cadence prioritizes them, on what basis they prioritize them
and so on.

When I'm sitting late nights in my cubicle churning out simulation data
in artist, the engineer in me is figuring out that design time can so
easily be cut by 30-to-40% if certain things can be changed in the
fundamental simulation/schematic methodology (which is only amenable to
a very serial sort of design algorithm). I could use OCEAN scripting
after a certain phase but even that is a bit painful. Anyway, there is
a whole chapter to be written on this. Just expressing my frustrations.
That is why I finally decided that I wanted to do my own GUI in tcl.
The enemy is of course TIME. But in the next few weeks or so, I hope to
have put on paper my basic ideas and have something basic to go on in
TCL (assuming frustration levels have not dipped into the subthreshold
region during the Christmas hols) Once that happens maybe others
who are interested in addition to Svenn could colloborate with me on
this?

BTW, I have started on a emacs SKILL mode to replace the now defunct
old emacs SKILL mode. Right now it kind of does SKILL syntax
highlighting etc. Very rudimentary and basic - I hesitate to call it a
major mode - that I was reluctant to post it. If anyone is interested,
please let me know and I can send it to them or post it. Also I hacked
up some SKILL code that I found that allows some sort of history
mechanism in the CIW window. I can post it as well. It uses an
undocumented feature though, so I wasn't sure about that.

 

Yup. I can t honestly believe that there are no openings from CDS for
feedback from their customers on possible future directions. That is a
more proactive way than trying to make sense of all PCRs.

About the tickle GUI, best of luck but that is too far for me. I have
no fluency in TCL. I am also not hooking well with emacs. If I would
work on better SKILL coding gui, that would be either nedit, scite, or
eclipse. The later seem a good framework. But having the syntax
higlighter right is already too much for my own courage. The TCL
reference above showed that is is not too hard to have an IDE interact
with the dfII workbench. But then again, all this could be handled by
CDS themselves: ADE is the most urgent one, but the skilldev is so far
behind IDE standards and needs attention too.

 

It is CDS' responsibility to provide their users with working tools. I
think the license and maintenance is expencive enough for CDS to take
front-end a bit more serious. So far I have the feeling that back-end
and bit-bangers are taken more seriously than the analog guys when it
comes to improving the environment. But, cadence is just reacting to
what is happening in the foundry world. They can't think years ahead as
things change on a daily base and bugs in back-end is crucial for chips
to work.

In my opinion the OpenAccess initiative is good, and I hope that _every_
part of the infrastructure in OA can be replaced by _any_ tool from
_any_ vendor. Then CDS can concentrate on their back-end business and
let specialised guys take care of schematic capture and simulator
control environments, without needing dfii to start them. The single
threaded nature of dfii is a drag when processing large data. You are
stuck with that ball-in-a-wastebucket mousepointer until the data has
been evaluated or fetched from disk somewhere in the matrix.

The "Skill and back again" is a concept which can be used with any
programming language. Instead of having dfii launch the entire script,
it would also be possible to write a little daemon that dfii can start,
and then the controlling applications can communicate with that daemon.
Then everything will be like a client-server thing and the daemon can
protect the dfii session from violent code from the controlling client,
and it is also possible for the daemon to give the client a hint that
the master is playing balls and doesn't want to be disturbed.

What I am most afraid of is that CDS goes on and implement something
like when wavescan replaced awd. The concept of awd fit analog design
very well in my opinion. The changes needed to the interface to make the
program better were probably less effort than bringing the codebase to
qt or gtk toolkit and thus they reimplemented it in java.

 

Andrew,
I am investing some time into creating a utility with SKILL which use
some GUI components in IC5.1. I am a bit concerned that this effort may
be wasted if the GUI is changed in the future. Could you comment on the
probablity that existing SKILL calls will stay close to what they are
today, or will I have to totally rewrite any SKILL code incorporating
GUI items.

 

Whilst the underlying widgets are moving to Qt (from Motif) the hi.* layer
remains compatible - this is necessary so that all the Cadence and customer code
using hi functions does not have to be rewritten.

So you should be OK...

Note, you can always try ICOA5251 (which is released) which uses Qt already
to see what I mean. Also you can use this to check how ready you are to move to
OA 2.2.

Regards,

Andrew.

 

Well, I didn't know about the UI improvements in the 5.2.51 version! So
I did a sourcelink readup of what is new and overall the changes looks
good. Looks like there are a whole bunch of new UI related functions
due to the move to Qt...

Check out the document "User Interface SKILL: What's New in IC 5.2.51"
on sourcelink!