Mail Archives: geda-user/2015/07/09/23:29:12
On Thu, 9 Jul 2015, DJ Delorie wrote:
>
>> How do you think this mapping tool should get the data from the schematic -
>> via a special scheme netlist script or by reading the schematic file itself?
>
> Nothing should read the schematic itself. I thought of two ways:
>
> 1. The various tools that deal with attributes also know about
> "implied" attributes, which are the result of database and ruleset
> queries. Thus, in gschem's attribute window you'd have access to
> the database as well as user-specified attributes. This lets the
> user override the rules while still having the convenience of a
> database.
>
> 2. The netlister would need to feed its data into some sort of engine
> that combines the specific attributes with implied ones, adds in
> other external data and/or back-annotation data, and produce
> whatever the backend needs.
>
Off topic: the other day I used gschem to draw diagrams. The idea goes
like this: I have some graphical info like axis, scales and stuff as lines
and text and I have the set of curves as nets. I translate the whole thing
to 0;0 so sch coordinates are actual values.
At the end I parsed the sch file directly to get the coords of line
segments.
This, and my past adventure with the text/xml/json/lihata gnetlist
backends made me think over my gnetlist-issue again. I still think the
best solution here would be:
I'd like to see a gnetlist library written in pure C so it's easy to
do bindings to whatever languages or tools. We already have a lot of
parts of gnetlist in C... but unfortunately a some of the logics in
scheme scripts. I'd totally decouple scheme from gnetlist, scheme scripts
would only be an optional user of the lib.
The thing I figured while working on that exporter backend was that the C
library of gnetlist did not expose everything about the schematics in a
consistent way. Rather it looked like a semi-random collection of specific
lookups that evolved most probably on a "this thing is needed by my spice
backend script" fashion. Like there is a
"gnetlist:get-all-package-attributes" but for some reason it didn't really
get me _all_ the attributes so I ended up using
gnetlist:vams-get-package-attributes. I think vams is one of the backends
that also needed a list of attributes and also got hit by the fact the
default listing is filtered/altered.
Furthermore I think the library should consists of 2 levels: a low level
that does simple queries without much logics or filtering and a high level
that lists connections for example.
The low level should expose everything possible and let the user filter.
It should show how exactly things are on the schematics. It doesn't do
anything with "implied" attributes. If there are multiple components
placed with the same refdes, each can be accessed independently so the
user can query the attributes of each. The low level shall not be limited
to pins and components and nets, but should be able to operatoe on
all graphical elements, net segments, components, where the actual
component is loaded from, etc. If I want to see on what coordinate a net
ends, I should be able to.
The high level should construct things that are not literally in the sch
but can be calculated. It should have the logics for "anything that has
the same refdes is merged into one by component", it should do the
"implied" attribute magic, it should be able to calculate what's on the
same net, deal with the meaning of pin attributes, etc.
There should be a clear separation between the two levels so when someone
uses. The high level calls should be generic and should often return lists
or arrays of references to low level objects.
So the answer to my own question in the subject: I sometimes parse sch
directly not because that's the proper solution, but because instead of an
endless recursion, I want a simple tool to be done, in a finite time
frame.
There is libgeda; I am not sure about the details but I guess I could use
it to parse the sch for me, but then I'd need to do all the netlisting and
higher level stuff manually.
There is gnetlist; it can do both, but not in a generic way. If
I need anything "unusual" (basically anything beyond accessing the most
common attributes and an abstract list of connections) I either can't, or
would have to write excessive amount of scheme or would have to write a
C callback for scheme.
Regards,
Igor2
- Raw text -