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. 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. 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
