[Fedora-electronic-lab-list] Re: [Alliance-users] Question about gcp

[Mukund Sivaraman]

On Mon, Feb 09, 2009 at 10:32:36PM +0100, Chitlesh GOORAH wrote:
> Being a KDE4 user and most of my friends are gnomers, I would
> recommend Tcl/Tk for the following reasons:
> - new users from the digital asic designers are already familiar with
> Tcl - coming from proprietary software
> - more chances to get contributors in, as writing plugins becomes easier
> - the users of herb/alliance are not software developers, thereby if
> it is a Qt/GTK based app, it will be a bit hard to build a community
> around herb as users are not software developers

> I'll respect your choice of gtk, however I believe this decision should :
> - be based on what the advantages are for the designer.
> - not be about ones' favourite API

Let's move this discussion to the herb-developers-list as it's probably
offtopic on the Alliance list :)

We have to be open minded. But we can only do things within our
capacity. It would be a perfect world to provide the exact tool that
any designer needs, but there's no such thing. Your have made some
points, so let's examine them. There are two topics here, though Tcl/Tk
provides both: (1) The choice of GUI (widgets) toolkit, and (2) the
choice of tool control language. The latter is more important as there
are more libraries and non-interactive code which can be scripted, than
GUI tools in Herb.

Any modern toolkit is good for Herb's GUI tools. Note that there are
only a few GUI tools (dreal, graal, xfsm, xgra, xpat, xsch, xvpn). I
haven't asked Jan, but I don't know Tcl and Tk. We think that GTK+
would be a good choice here, given that (1) we already know it very
well, (2) the code is in C, (3) we are going to use glib as a utility
library everywhere to make our C development life easier, and (4) it's
widely available by default on Linux and BSD distributions.

With regards to tool control, the functional aspects of the code
ideally would be resident in libraries. With language bindings, they
can be used from any language such as C (native), Tcl, Python, Perl,
JavaScript, etc. This would be more beneficial as then users can use
whatever language they are familiar with.

As an example of such a GTK+ application, look at GIMP and how it can
be scripted interactively using Scheme, Python, Perl, etc.

> - (this is very important to the opensource EDA community) : more
> compatibilities with other Tcl/Tk based apps such as magic,
> irsim,netgen, xcircuit,...
> 
> The latter is important because currently herb/alliance is more
> digital oriented and having already a handful of tcl/tk based analog
> tools from opencircuitdesign and Graham Petley's standard cells, I
> believeTCL/Tk is the right choice to follow as in the future, there
> will be more chances to have more mixed signal simulation with
> opensource EDA tools. The developer of Ngspice is planning to write a
> TCL/TK based frontend for ngspice and if herb uses Tcl/Tk, we will be
> able to ensure several design flows with opensource EDA tools. Knowing
> as well the fact that Tkgate provides verilog support with a simple
> tcl/tk based app, it would be nice to have easy and quick scripting
> interface to both design and simulation.
> 

Herb provides a complete "digital flow" (if something is lacking, let's
fix it). The maintainer of Magic, xcircuit, netgen, irsim, etc.
provides an alternate digital flow which is pretty neat. It would be
nice to be compatible with regards to exporting and importing data with
these tools, so we can mix and match if necessary. Prof. Shimizu's
tutorials already describe about using Magic with existing Alliance. We
have drivers for a bunch of formats currently.

But I don't understand what you're trying to say. How would using
Tcl/Tk make us more compatible with these tools than any other option?

		Mukund