On Wed, 2007-11-07 at 11:54 -0600, John Griessen wrote: > 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'd not considered embedded, but that is a fine idea in general. For the data-structures proposed some time ago (as a thought exercise), this would be possible as a hierarchical sub-circuit definition. The addition we'd need to make would be a link to the verilog. The structures already support the notion of a "circuit" existing as an external port definition and internal netlist. It was the intention that it didn't need to have a schematic representation. (Inspiration from some Xilinx tools, where you can mix / match VHDL and schematics. Autogenerated symbols for VHDL blocks help here too). > 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. I don't expect any of this functionality "soon", but perhaps eventually ;) > 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. I think this relates to back-annotation, and I'd wondered about doing it the same way we build PCBs in PCB. Import a netlist (some definition of the "truth" a circuit should represent), and display deltas / ratlines / rat-symbols which the user needs to place. Reward user when schematic matches desired "truth". Updates to attributes, perhaps minor alterations could be automated / auto-suggested of course, given programming effort. > Would this require any internal netlist changes? I mean the internal > representation, the simplest form, not any of the output > formats. I'm not sure... I wanted to make some changes anyway, bringing net-listing more into libgeda rather than gnetlist. (gnetlist being a command line exporter the existing guile backends, + libgeda to do the heavy lifting) > We would need some way to do a stack of symbols to equate to vectors of > connections, or busses. I've been meaning to look at how Steve has this implemented, as Peter B and I never finished looking at buses in our (thought exercise) data-structure diagram. > 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. I'm not sure about those questions, but I think the answer might be "yes". > Anyone else been thinking of busses wires and ports as they apply to verilog > and FPGAs? Yes, but only so far as to realise the UI might be "interesting", and to postpone thought on the topic to hack on libgeda + gschem. Best wishes, and thanks for the thoughts! -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
