SKILL or SKILL++ or Tcl

Dear ALL,

I have aome very general questions (sorry).
I'm creating schematcis currently by SKILL.
From todays point of view I want to switch to SKILL++
BUT, I heard that cadence is going to switch to Tcl in general and
SKILL may be dieing.

I'm working with "@(#)$CDS: icms.exe version 5.1.0 06/04/2007 00:16
(cicln04) $"

My questions:
1) Will SKILL(++) be continued or does cadence switch to Tcl at all ?
2) IF Tcl is the way to go, when to start ? and what about an object
driven Tcl++
3) Can I use SKILL++ with icms 5.1 and later 6.2 version


Sorry for this general questions. But before I continue my work I
would have this things clarified.
Any hint is welcome.
Thanks a lot

Rolf

 

RolfK wrote, on 11/01/08 11:21:

Cadence are not changing the customization language for Virtuoso to Tcl. I'm not
sure where you heard that.

SKILL and SKILL++ are supported in all releases and will continue to be supported.

Regards,

Andrew.

 

Hi Andrew,

I'm glad to here that indeed. I could not imagine throwing away the
thousands of skill customizations we (the IC companies,
universities ...) have developed over the years.
I'm just wondering whether Cadence is investing in Python for the IC6
platform or not. I don't know how Skill compares against Python but as
far as I understand, Python is very suitable for OA since is native
Object Oriented and has good interface with C and C++ classes. It has
also the advantage of being a Public widely used language which might
make it better than Skill from the point of view of the extension. And
as you know, some companies like Ciranova have chosen the Python path.
Any comments about this ?

Regards,
Riad.

 

Hi Riad,

Here at Ciranova, we're definitely seeing an increase in the number of
IC companies who have chosen Python in their CAD flows and their
PDK's. There are three reasons that come up again and again:

1. Open and interoperable. Python is public and Python PyCells work
in any OpenAccess-compliant tool: IC6, Synopsys, Mentor, Magma,
Springsoft, AWR etc.

2. Coding efficiency, as you mentioned. PyCells typically take about
half the coding effort of comparable traditional PCells, and make it
much easier to create process-portable and complex devices like spiral
inductors. I don't know a PDK group anywhere in the world that feels
underworked right now, especially as they go to 65/45/32nm design
rules.

3. Availability of skilled engineers. A lot of infrastructure now
exists around Python - documentation, training, IDE's, and especially
a lot of new university grads and other engineers either already
proficient in Python, or else motivated to become so.

Regards, Eric

 

I wonder what's the root of that false rumor.

There are Cadence's tools which are using TCL as command language (the
Encounter platform and possibly others), , but at the best of my knownledge
there is absolutely no plan of adding support for TCL to tools currently
using SKILL, without even speaking of removing SKILL.

SKILL will continue.

Question with no object.

6.3 supports SKILL.

Yours,

 

Riad KACED wrote, on 11/02/08 23:54:

Whilst I'm not going to get into a language war, there is a lot more needed for
a PDK and tool extensions than just the pcells. So whilst there is a good
object-oriented interface to the OA database with Python (and Tcl for that
matter), that's all it covers.

In the Cadence IC tools, there are roughly 5400 documented public SKILL
functions - providing APIs to lots of different parts fo the tools. Of these,
only about 350 are providing database access, and even if you include all of the
API functions that may be used in pcells, there are something like 750. That's
an awful lot of application-specific API information that would need to be
reimplemented in another language to provide a complete customization
capability, equivalent to what you have right now.

A PDK consists of much more than just the pcells, and to some extent the
language that is used to define the pcell is only a very small part of the problem.

Whilst I rather like Python as a language, I don't think it is really that well
known (compared with, say, Tcl), and amongst IC designers, I would say it is
hardly known at all.

Regards,

Andrew.

 

Tcl seems to be kind of standard on newer tools, maybe because of the
liberal BSD license and its rather easy integration into existing
codebases. Tcl was also written for tool command applications in EDA.
Since Tcl is acompanied by Tk, which also Python use in Tkinter, it is
quite easy to write custom GUIs. My experience is that Tcl and SKILL
(Lisp) does feel very alike when it comes to how commands interact, at
least when SKILL is written the Lisp way. Tcl/Tk is also available
standalone as a scripting language free for anybody to install on
their home computers so that years of corporate programming experience
can be used for other purposes. I tried to program guile (Tcl's Lisp
opponent) based on my experience from SKILL and was pretty soon lost
in translation. Doing command line things inside tools like Modelsim
or Design Compiler is a breeze with Tcl and I can use what I learn
from using Modelsim in Design Compiler and vice versa. And there is
continous development on Tcl where the developers are aware of legacy
code. Python will break backwards compatibility in their 3000 version.
I can still run Tcl/Tk applications that were written for quite old
versions (Tcl7.5/Tk4.2) in the newest Tcl/Tk8.5. It is just a nice
scripting language that happens to be very flexible and not that
difficult to learn. But I think SKILL will be around as long as
Cadence is around.