Peter Clifton wrote: > Fully hierarchical design support > > Workflow agnostic schematic editing.
Hi Peter, et al, What do you think of adding hierarchic schematics that handle instances of subschematics so they are autonumbered, generate a good flat netlist with long names, and support embedded verilog chunks? I see doing some icarus verilog work soon, along with the abits tools for Atmel parts that make a full open source toolchain for FPGA coding, with partial reconfiguration on the fly. It's always helpful to have top level schematics human drawn for graphical meaning rather than deal with stacks of files that cross-reference each other, (verilog modules to input to the FPGA flow). As far as I can tell, we would need some netlist generator work, gschem-->verilog and verilog-->gschem, to get verilog modules automatically from wired connections in a schematic. The point where you connect to non-verilog defined symbols, (store-bought parts) is where this would stop -- an attribute could switch off generating verilog from the wires/ports/modules netlist of the page. To start, I would just make a checker program to see if the hand written verilog module and hand drawn schematic module netlist to the same thing, then see how to automate any of it. Would this require any internal netlist changes? I mean the internal representation, the simplest form, not any of the output formats. We would need some way to do a stack of symbols to equate to vectors of connections, or busses. Would the gschem internal netlist start to use references to instances of subschematics/subnets once you put the "stack of symbols" feature in place? We might be close with busses -- stacks of symbols == port connections-in-order might be the tricky part. Anyone else been thinking of busses wires and ports as they apply to verilog and FPGAs? John Griessen -- Ecosensory Austin TX _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
