Re: gEDA-user: gnetlist verilog back end gnet-verilog.scm

[Mike Jarabek <mjarabek@xxxxxxxxx>]

John Griessen wrote:
> This is probably a Mike Jarabek question:
>   
Could be... Sorry for the delay, got swamped.
> I don't get usable hierarchic netlist output when I have placed schematics and use the gnet-verilog.scm back-end.
> It drops the module definitions and endmodule statements of the placed symbols that refer to schematics.
>   
This is the intended behaviour.  The instantiations of the symbols on 
the page represent instantiations of sub-modules in the design.
> So, is that the normal behavior, and I need to not use hierarchy, and run gnetlist on every schematic, then cat them together?
>   
That could be one way of doing things, but that's not normally how I 
have seen it done with larger digital designs. (I count modest size FPGA 
designs too, anything more than a couple of modules.)
> There seems to be no existing gnetlist concatenate function.  Would handling this in scheme be difficult?
>
> By "this" I mean taking all the files referred to by source= attribs and running gnet-verilog.scm on each in order,
> then putting that to the gnetlist output.   gnet-verilog.scm is ready to create a one level netlist -- one module's worth of 
> verilog.
>
>   
If you include a source attribute in your symbols, you will be able to 
descend into the underlying schematics in gschem, and so will gnetlist, 
if the heirarchy traversal is enabled.  The cost here is that when 
gnetlist runs, it will flatten the netlist down to the lowest level 
where there are no source attributes.  I don't think this is what you 
really want though, you will get a single module with duplicated code 
for every sub module, even if said module is identical to others.
> Using a makefile is the obvious thought.  Make could just take a list or all .sch in a dir and run them and cat them together
> to a filename.
>   
Perhaps you are thinking in too much of a linear way.  This is what you 
probably have to do with a spice deck, but with most Verilog simulators, 
there is usually a mechanism for a 'manifest' file.  I certainly hope 
that the verilog-ams parser you are using is capable of reading such a 
file.  In practice, this file is simply a list of other file names that 
make up the design.  In a pinch you should be able to craft a master 
file that does a series of '' 'include "filex.v"  ''  reading this 
master file into the simulator should have the same effect as using 
cat.  Some times the manifest files are automatically generated, you 
might be able to pull this one off using some make file variables, and 
some shell code to write out the file.  Something along the lines of " 
rm -f manifest ; for i in $(VERILOG_FILES) do echo $i >> manifest ; done 
" (bash-isms aside)
> Handling it without make complexity separate from the back end chosen would be nice
> though, so I ask, "Anyone seen existing scheme code that could use source=verilog_io.sch to trigger running it again on the 
> referenced file then outputting that to the same place as usual?
>
>   
I don't see that you should have to do such things, but such a recursive 
invocation of gnetlist should be possible, at least in theory.  Our 
scheme interpreter has a 'system' call right?
> Thanks,
>
> John Griessen
>   
--------------------------------------------------
                              Mike Jarabek       
                                FPGA/ASIC Designer
  http://www.sentex.ca/~mjarabek                   
--------------------------------------------------



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