gEDA-dev: gEDA-user: gEDA/gaf capabilities

[Peter Clifton]

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!)