Re: gEDA-user: gnetlist l and m options

[Steve Meier <smeier@xxxxxxxxxxxxxxxxxxx>]

The netlister that I am working on is becoming more of a schem script
engine that allows multiple scripts to be run against the eda library.

I am not proposing getting rid of the l and m options I was wondering
more what effects changing the behavior of the l option would have.

The flow I am think of is where the netlister reads in a series of
schematics and associated symbols building up the PAGE structure.

Then the l option would allow one or more scripts to be loaded and
executed to manipulate the library data structures.

Then the back end script would be executed.


example 1

1) run a script to load schematics and symbols

2) run a script to create a flat netlist

3) run a backend script to export a pcb netlist

example 2

1) run a script to load schematics and symbols

2) run a script to export a bom

example 3

1) run a script to load schematics and symbols

2) run a script to create page level netlists

3) run a backend script to export a hierarchical based
vhdl/verilog/spice netlist

example 4

1) run a script to load schematics and symbols

2) run a script to merge in a back annotation file

3) run a backend script to export a new set of schematics that includes
the slot/pin/footprint swaps

example 5

1) run a script to import (non geda) schematics and symbols

2) run a backend script to write out geda style schematics and symbols



I can't figure out what one expects the m option to do? Clean things up
since it was ment (i think?) to be executed after the backend script.


Steve Meier


Peter Clifton wrote:
> On Fri, 2008-01-04 at 20:19 -0500, Paul Tan wrote:
>   
>> Hi Steve,
>>
>> I am not using that feature currently, but its a nice feature and I 
>> might
>> use the post-backend feature in the future.
>>     
>
> Tangentially related....
>
> To fix the spice-sdb slotting feature (patches not committed yet, but
> awaiting comments), I had to explicitly split gnetlist.scm into two
> parts. I moved gnetlist.scm and the netlist backend to load BEFORE
> traversing the board, and have  gnetlist-post.scm run AFTER.
>
> This is because I introduced (propose to introduce) a scheme hook for
> determining the UREF of a component. This is determined during schematic
> traversal time, so at this point, the backend must have loaded.
> However.. gnetlist.scm also has some (define ...) code which is
> evaluated as soon as gnetlist.scm is loaded, and MUST NOT be run until
> after traveral. (This was the bit I moved to gnetlist-post.scm).
>
>
>   



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