Re: gnucap-geda, sym file hndling (was Re: sym to verilog-ams)

On Mon, Apr 04, 2022 at 01:41:21PM +0200, [email protected] wrote:
> Felix:
> ...
> > It's much the same as schematics. geda has top level objects, and
> > verilog doesn't, so you put everything into a module definition. The
> > goal is to reproduce the sym file back from its verilog representation
> > (round-trip).
> 
> The sym files usually stays unchanged. Why not just include the file 
> name of the sym file and its checksum/git commit/svn commit/etc.
> 
> If the checksum is changed we can do a lossy repair of the original file
> which will work as originally inteded or check it out from a repository.

I do not understand what you are trying to do. We need to read in the
symbols in order to work with them. A round trip is to assure data i/o
is working properly (and possibly implemented correctly).

> > In the schematic tests, I use the "list" command, and "list main" prints
> > the main module definition (in verilog mode) and the contents of the
> > schematic (in geda language mode) respectively.
> 
> What is this "list" command you talk about ?

The list command is implemented in gnucap/apps/c_list.cc. Example use

gnucap-geda/tests$ gnucap -a lang_geda.so
gnucap> geda rc.sch module device=main
gnucap> verilog
gnucap-verilog> list main
module main (input:1,nout,passive:1);
[..here it goes..]
endmodule  // main

> > - GEDA_SYMBOL must become a plugin.
> >    either use subckt from d_subckt.cc, or something similar derived from
> > 	BASE_SUBCKT
> > - The parser in GEDA_SYMBOL::GEDA_SYMBOL must be singled out.
> > - GEDA_PIN must be a plugin as well.
> > - GEDA_SYMBOL_MAP, where libgeda is (ab)used, must be dropped.
> >    (this is strictly off-topic.)
> 
> I'm not up to speed with this.

It does require some familiarity with Gnucap. Feel free to question your
way through.

cheers
felix