On 7/18/07, Svenn Are Bjerkem <svenn.bjerkem@...> wrote:
> On 7/16/07, roucaries bastien <roucaries.bastien@...> wrote:
> > aOn 7/16/07, Gopala Krishna <krishna.ggk@...> wrote:
> > > Dear list,
> > > How this basic idea originated ?
> > > Recently i had few converstions(mail) with ktechlab people. The
> > > project admin had a flair idea of merging qucs-ktechlab when they port
> > > ktechlab to kde4. He also asked my help. Due to exams i couldn't
> > > answer him appropriately. I got some random thoughts about
> > > merging/reusing several available gpl-eda or simulator tools. I
> > > explored geda a bit and i found their goal motivating.
> The goal is motivating, indeed. The problem gEDA has is simply its
> rigidness vs. becoming really useful for chip design in an enterprise
> environment. What do I mean by that? If I want to have a working
> version of gEDA I have to compile it myself. Some of the dependencies
> are really tricky. Guile is the most tricky one and mostly the killer.
> There are developers who have made chips with gEDA, but I only know
> one. That is too few for a program that has a 10 year lifetime.
Dependencies are tricky but sometimes you need to have dependencies.
For instance I do not want to write my own optimized umfpack function,
because it is really really tricky
> The idea of having a separate netlister with plug-ins for the
> netlisting formats are really a good one. Problem is that the
> netlister does not support hierarchies very good, and you have to
> learn a new, difficult programming language to get a new back-end.
> (Difficult is not only because lisp is a bit different, but guile
> development is mostly ignoring backwards compatibility at all...)
I agree that netlist plugger is a really good idea. And we could do
this with qucs using text to xml transform.
> > Geda goals is motivating. Create a true eda is also motivating.
> Yes it is, but on the other side the user base is so small that real
> EDA is still a domain for multi-million companies. Open source
> community does have a lot of alternatives, but they are all scattered
> applications. There must be some glue to tie the all together. Find
> that glue.
Glue is simple, merge all the possible stuff in the main tree.
Morevover we could allow to create new component using pipe command or
a lot of thing.
> > However, please do not commit the same mistake than cadence
> > spice (ie graphic interface must be always used), or geda (a really
> > hard to understand and ugly interface). Please clearly separate the
> > core functionnality (as today) and the graphical layer.
> Actually, newer versions of Cadence have really separated graphical
> layer and simulator. With an extra license you get all the docs you
> need to write the interface for a new simulator in to cadence. But
> don't forget that Cadence sell their own simulator, Spectre, which is
> really expencive and thus Cadence is not so eager that users should
> integrate the qucs or the gnucap or the ng-spice simulators into it.
I do not know that this possibility exist, perhaps my uni version does
not include the whole cadence eda. But using qucs on cadence is not
really useful. Let the two world not overlap
> Spectre is a horror. It has a decent list of simulation features, but
> it has horrible data processing features. Most Hspice users are fairly
> used to do things from the command line with schematic capture from
> cadence composer, but when these guys have to transfer to Spectre,
> there is at first an uproar and then they learn about ocean. Ocean is
> the Cadence scripting language that make the cadence SKILL programming
> language a bit easier for EE's. It is a horrible mix of C and lisp
> syntax and the stand alone interpreter is slow, but the simulations
> are reproducable and things may even run over-night without a simple
> mouse-click. Problem is still that the waveform viewers from Cadence
> are horror stories and the native storage format for analog
> simulations are proprietary.
I do not understand why proprietary softaware reinvent the weel :-)
And I totally agree with you about cadence waveform viewer.
> >And like Sven I do not think scheme is a good scripting language.
> Tcl is the only scripting language that you really should evaluate for
> such operations. It is not the newest language, but it was made with
> EDA automation in mind by somebody who had experience with EDA. (John
> Ousterhout) it is stable, it is well documented and it used to be the
> GUI scripting language of choice until Python occured. Tkinter in
> modern Python is still the Tk part of Tcl/Tk.
What do you think? I do not follow you, you say that the only language
of choise is TCL. I do not agree, because you could have tcl, python
and perl for free :-)
With swig you create your export in three language (and moreover lips
if you want). Nice isn't? See
That will be really useful is to create matlab hook but it is not
really high in the priority list (they exist a outdated port of swig
to matlab http://search.cpan.org/src/DBEAZLEY/swig1.1p5/Examples/MATLAB/)
> But I think it is more important to take small successful steps than
> to have too great ideas and never reach the goal.
I agree, therefore the first step I think to do a big brainstorming on
the type and the function we want to export as programable. Next step
will to create a good data viewer (or allow gtkwave to read data),