gEDA-dev: gnetman inspired libgeda datastructures

[Peter Clifton]

On Tue, 2007-03-20 at 13:41 -0500, John Griessen wrote:
> Peter Clifton wrote:
> 
> > We consider "net" to be electrical - rather than graphical, with
> > "NetSegments" being the graphical representation. Similarly, "pins" are
> > the graphical representation of an "Mport" (master port). 
> 
> 
> 
> > Because it makes more sense to associate attributes with electrical
> > entities such as the nets, or Mports, rather than graphical entities,
> > attributes will be stored as abstract data rather than graphical
> > constructs as at present. When text is required on a Page or Symbol (two
> > closely related entities), literal text may be entered, or a reference
> > made to attribute data from the current circuit - or lower in the design
> > tree.
> > 
> 
> 
> Does the above infer that you always first create a netlist from newly defined graphical "NetSegments",
> then you have defined your nets electrically if they pass self consistency checks, then
> and only then can you reconcile mports with nets?     Sounds fine to me -- and implies
> always on netlisting function.

Yes - it was intended to keep the netlist up to date. Obviously, we must
have a way to re-generate it though if an external update invalidates
it. (Or for importing "old" designs)

> When you edit a sub schematic and change its mports, it will cause the higher schematic to be 
> broken.   We will need a way to handle that without confusion -- the netlister may need to go from the bottom up, and stop when it 
> hits trouble, and still be able to use its partial results for the hierarchy from here down...

Depending on how CPU intensive the netlist update is (and how scalable
we wish to be), the netlist update could be triggered to run in a
background thread or process.

Each affected level of schematic hierarchy ought to attempt to update
its netlist. If mports move, or are changed incompatibly, it would
probably require us to sever the net connections where that hierarchy
level.

Thanks your your comments,

Regards,

Peter C.