kicad-developers team mailing list archive

[Simon Richter <Simon.Richter@xxxxxxxxxx>]

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

Attachment: signature.asc
Description: OpenPGP digital signature