kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 17/11/2017 à 03:24, Jon Evans a écrit :
> Hi Wayne, JP, and others with lots of Eeschema knowledge,
> 
> I am working on a set of features to expand the capabilities of buses in Eeschema (more details
> soon, but in short, extending the concept of a bus beyond just a vector of signals with the same
> prefix, to an arbitrary grouping of signals).
> 
> As I have looked in to this more, I have realized that it would be very useful for the
> implementation of these features (as well as others I can imagine) if the way that connectivity is
> managed were to be refactored/expanded.
> 
> Right now, my understanding of the code is that connectivity between objects is only calculated as
> part of creating a netlist -- in SCH_EDIT_FRAME::BuildNetListBase().  This information is not cached
> anywhere or attached to the graphics objects, so it needs to be recalculated every time it is
> requested (today mostly by the "Highlight Net" feature).
> 
> Since some of the things that I am working on would benefit from having easy access to the
> associated net/bus information for a graphical item, I was thinking that it would be a good idea to
> store this information and update it when the schematic is modified, rather than recalculating it
> every time it is needed.
> 
> If I go down that path, then I start to think about how to store the data -- right now we have
> NETLIST_OBJECT, but this class is mostly targeted at ending up with a netlist suitable for
> ERC/transfer to PCB, and has some behavior that doesn't really line up with what I want -- for
> example, it "explodes" buses into individual objects for each bus member.
> 
> I could either expand/rework NETLIST_OBJECT to do what I want, or I could leave it alone and build a
> different storage structure in parallel.  The latter option might result in some duplicated data,
> but would also somewhat isolate these new features from the netlist generation code, which could
> reduce risk of breaking something.
> 
> Do you have any input about this?
> 
> Thanks,
> Jon

First, thanks to work on this feature (I am aware of this feature).

I do not known exactly do you need to work on netlist connectivity storage, so I am only generally
speaking.

I am guessing you are talking about something known as "incremental netlist" (or "incremental
connectivity")
I mean store connectivity data for each sheet, so this connectivity does not need to be built if the
sheet is not modified (faster global connectivity calculation)

If yes, keep in mind in a schematic editor there are 2 tricky things:
1 - multi-units symbols (with interchangeable units ).
2 - complex hierarchies, that use many instances of the same sheet.

The most *tricky* case is a complex hierarchy using a a multi-units symbol shared by many instances
of the same sheet.
the instances are not exactly the same: the unit differs (I mean U1A is inside a instance, U1B is
inside an other instance)
Eeschema allows that (Unfortunately, when complex hierarchies support was added, the feature looked
like a good idea, but this is not the case).

Therefore:
if you want to add a incremental netlist support (this feature is a good idea), each instance (not
each sheet) must have its own netlist data.
Each instance has its own sheet path, and shares the same sheet, but has is own component reference
(the AR ... ) in .sch file, but each component has the same short time stamp.

of course if no multi-units symbol is shared between sheets, all instances have the same netlist data.

On the other option about duplicate structures, I also still generally speaking, but this is not the
best idea, unless very good reasons.

duplicate structures and duplicate code is always a problem for guys who maintain the code, and are
a source of bugs.

-- 
Jean-Pierre CHARRAS