kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 12/11/2015 3:20 PM, Simon Richter wrote:
> Hi Wayne,
> 
> On 11.12.2015 20:23, Wayne Stambaugh wrote:
> 
>> Not until after the new schematic and symbol library file formats are
>> implemented.  Support for pin and unit swapping will be built in to the
>> new symbol library file format.
> 
> That would be fairly orthogonal to what I'm suggesting -- I'd like to
> add the swap info to the netlist, and don't really care where it comes
> from (with the current symbol standard, pins with the same name are
> swappable, and units in ICs that have "all units are identical" set.

Using pin names is not a good way to determine if the pins can be
swapped.  For logic gate maybe but not for things like micro-controller
I/O pins.  They are all going to have different names.  I would rather
implement a complete solution rather than an intermediate incomplete
solution.  Unfortunately, the current netlist is only unidirectional
from Eeschema to Pcbnew.  Eeschema cannot parse netlist files and Pcbnew
cannot generate netlist files.  I also do not want the netlist file to
be an information storage medium.  It's purpose is to transfer
information between the schematic editor and the board editor. In order
for pin/unit swapping to be properly implemented we really need to
refactor our netlist code so that it can both parse and format netlist
files (actually streams) from both schematic and board objects.  This
would allow the board editor to pass netlist changes back to the
schematic editor when pin/unit swap changes are made.  Until this
happens, a complete pin/unit swapping solution cannot be implemented.

> 
> So I'd like to change (extend) the netlist format mainly.
> 
>> 2) I'm thinking about embedding symbols in the schematic file similar to
>> footprints in the board file.  This would simplify our symbol library
>> management code.
> 
> This would also make it consistent with pcbnew, which would be worth a lot.
> 
> Also, it'd simplify narrowing of pin types -- connectors would have
> "unspecified" pins, and instances would then declare them as the actual
> types -- that should allow us to get rid of quite a few PWR_FLAG
> instances, and make ERC more useful (also allowing "bidirectional" pins
> to be narrowed down to "input", for example).
> 
> In the long run, I'd also like to see hierarchical components and
> footprints that can inherit other components/footprints, which would be
> useful for reuse. For example, a Power over Ethernet design around a
> specific controller would contain several components (that have to turn
> up in the BOM), and there'd be a recommended layout as a footprint, but
> both can be changed in the actual instance.

Inheritance will be supported in the new schematic and symbol library
file formats.

> 
> That would also be made easier by copying rather than referencing symbols.
> 
> The downside is that updates get more complicated, and we'd need a
> diff/merge mechanism. I have a few ideas about that as well, but that's
> not urgent either.
> 
>> 4) Matched pair support for the matched pair router needs to be added to
>> the schematic file format.   The current _P/_N matched pair semantics
>> were just a stop gap measure until we could implement the new schematic
>> file format.
> 
> Yes, that is also congruent with the pin swap extensions in the netlist,
> because swapping differential pairs needs the differential pair
> information as well (and ideally I'd keep that in the component, but
> that requires a configuration system for non-trivial components as well
> -- e.g. an FPGA where two outputs can be either independent or a pair
> needs a way to specify which is used in the schematic, so we can
> properly generate that information).
> 
> The component configuration will affect the file format -- I think I can
> prepare something for when that discussion happens. The more interesting
> question for me at the moment would be whether pin swap information in
> the netlist would be worth pursuing.
> 
>    Simon
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>