Re: gEDA-user: Yet another netlister

[r <nbs.public@xxxxxxxxx>]

On Sat, Aug 1, 2009 at 2:49 PM, A.Burinskiy<alexbour@xxxxxxxxx> wrote:
> I thought about implementing some language for netlist and after all I
> decided to go with plain C++ and get rid of using device attribute
> unless it is absolutely necessary (such as input/output pin) and give
> more strength to user symbol definition relying on the fact that end
> user knows what [s]he does. After all, each symbol translated into very
> fixed semantic (Refdes node1 node2 name attributes ...).

I don't think this is necessary. Sure, some tools (e.g. from Cadence)
provide a simple embedded language that can be used by a designer to
interact with the netlister (typed attributes, pPar(), iPar(),
arithmetic functions etc.) but that's not what I meant (although it
would be nice to have).

> Major problem - if syntax of gschem files will be changed, then gschem
> may loose compatibility with all previously collected works! Thus, if
> gschem will change format of output files it will change it in
> compatible way or being more strict - only on incremental way. In this
> case it would not be hard to make incremental adds to the code, if
> algorithm itself is flexible and transparent enough (C++, pcb/spice
> output formats, flattening/hierarchical some keys in config file). If
> you think of adding more flexibility I will be more than glad to change
> the code.

I'm not sure if I understand you correctly. Yes, accessing the data
files directly is a bit dangerous from API stability point of view.
Ideally, libgeda would provide anyone interested with a set of
functions for accessing the design and traversing the hierarchy. The
benefit of this would be:
1. API abstraction,
2. The same logic and configuration would be used by gEDA tools.

> Speaking more about netlisters. Scriptising netlister - adding language
> inside language (you translate from .sch lang. to .net lang. using
> script) will force netlister to be more "hardcoded" (that is what
> happened with gnetlist, is not it?) instead of expectations to make more
> flexible semantic.
>
> And, finally, me, as a user, will not be happy to change the script each
> time I add new symbol!

No, that's not what I meant. I just suggested that the whole
netlister, as it is now, could be ported to an interpreted language,
so that it was easier to understand and modify for a person who didn't
write it.

The extendability would be useful (although not required) for writing
a library of complex components. Think about checking certain
attributes if they hold legal values for a given process,
precalculating MOS ad,as,pd,ps parameters, modifying netlist for
monte-carlo simulations. You can consider these "very heavy
components" designed for a given technology.

> In one word - I made my life easier choosing C++ without Perl or
> whatever. I think that definite advantage of using script will have tool
> that involves highly interactive tasks, for example analyzing result of
> simulation using waveform viewer, layout creation tool, P&R.... Even for
> schematic entry - I doubt that scriptising schematic capture tool will help!

Scripting is one thing, writing the tool in a scripting language is
another. If performance is not a concern I would prefer to have a tool
written in a scripting language so that I can change/extend it easily.
This is what opensource is about after all. It doesn't mean that
people can't do this with a tool written in C++ but the amount of work
involved is far greater (downloading the source code, compilers,
library headers, using the tool chain etc.) especially for people who
are not programmers in their day jobs.

Thanks again for writing the tool!

Regards,
-r.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user