kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Jul 14, 2014 at 10:30:51AM +0200, Tomasz Wlostowski wrote:
> - Provide forward and back annotation between the schematic and board
> editors.

I think that we need to better specify the extent of the annotation
capabilities; at the moment we have:

- Forward annotation (sch -> pcb): reference, value, footprint (assuming
  that reading is driven by the unique key i.e. timestamp)

- Backward annotation (to sch): footprint only (thru the cmp file)

Implementing netlist reading in eeschema should give at least attribute
update (but is that useful except for footprint? i.e. what do we gain
being able to change reference/value in pcbnew?)

> - Define netlist file format changes required to handle pin/part swapping.

That would be some attribute declaring which subpart have which pin and
which pin can be swapped with which one. Since the netlist actually
contain the part definition the natural place would be in the netpart
form. eeschema module format will need to change for that, however. What
is the status of the logical unit based one?

Anyway it could be something like
(libpart (lib ...) (part ...)
    (aliases ...)
    (description ...)
    (fields ...)
    (pins ...)
    (subparts (subpart (num ...) (pinswap ...)))) ; <<< DEFINE THIS

> - Update netlist file formatter and parser to handle file format changes.
> - Develop a netlist comparison engine that will produce a netlist diff that
> can be passed between the schematic and board editors.

Thus generating a conventional ECO changelog file.

> - Create pin/part swap dialog to manipulate swappable pins and parts.
> - Add support to handle net label back annotation changes.

Is that for netclass definition?

OK, then, if these are the requisites I see a couple of solutions:

a) doing exactly as specified with a 'netlist diff' tool and then
   doing the traditional ECO-file processing, i.e. a transaction/change
   log to be applied (something like SPECCTRA import);

or

b) making the programs smart enough to spot the differences and apply them
   (correctly, this is not trivial) on netlist reload;

As a computation I'd say is more or less the same thing (for each
component compare the things and process the changes) with the added
effort of specifying the ECO file format. However splitting the process
with an explicit diff step could simplify the annotation itself. Having
done a lot of sorted sequential file processing in the past I'd say it
*could* be a good idea (even if more complex).

> Remember that whatever forward/back-annotation mechanism will be
> implemented, it will have to handle:
> - pin/part/differential pair swapping
> - attribute annotation - take a microwave design as an example: the
> parameters of a microstrip line/circulator/whatever_else inputted on the PCB
> should be transferable back to the schematic (and the other way around).

Maybe netclass, too. I'd love to having it specifiable on the schematic.

> Our proposal is just about comparing two netlists. Usability of such tool
> would not be only limited to PCB<>schematic annotation. Think of tracking
> changes between different versions of the design and visualizing them in a
> human-understandable way.

*If* the requisite is having a tool for documentation then option b) is not
viable; the workflow then would be the 'traditional' one (i.e. orcad
style). IIRC they call it 'autoECO'

In this situation:
- eeschema writes netlist and reads ECO
- pcbnew reads/writes netlist and maybe reads ECO
- cvpcb reads netlist and write netlist. *or* read netlist and write ECO
  (a little irregular... need more thinking)
- new tool reads two netlists and writes ECO (could be a lib function or
  a separate process called when needed, of course)

The 'maybe' in pcbnew is because currently pcbnew takes *all* the
information from the netlist; to be a completely regular process it
should be able to read the ECO to merge into the 'empty' netlist, but it
doesn't seem to be convenient. In an ideal world eeschema/pcbnew/cvpcb
would read ECO and write netlist, while the new tool would read two
netlist and write the diff ECO. I'd do like this if I had to design the
batch process from scratch; however given the current state it would be
too much of work. I agree with Dick that this route is complex and needs
lots of work.

There actually is a c) option (i.e. option b) handling the requirements):

- eeschema writes netlist and reads netlist (detecting and incorporating
  changes)
- cvpcb read netlist and write netlist (simply changes attributes)
- pcbnew read netlist and write netlist (saves its current states with
  changes)
- new tool reads two netlists and writes ECO for documentation purposes
  only :D

I think this is the simplest one to implement given the current
codebase. pcbnew has already all the netlist read/processing done, since
it's its main current use; it needs to be extended to write it back
(keeping around in core some bit it currently doesn't use to reproduce
it correctly, like component definition). cvpcb only needs to touch the
footprints, so if there is a domain model (do we have it?) for the
netlist should be easy to do.  eeschema would be the most 'complex'
since it currently has no idea of reading the netlist and has to do the
diff processing. Given a domain model changing attributes for
backannotation is easy; in future gateswap would be easy (just change
the subpart) but portswap will not, since eeschema parts are very
tied to the library (they are instanced not copied like in pcbnew).

Important thing to check: do some (annotable) changes exist that
couldn't be specified in the netlist? At the moment I don't think so.

Comments?

-- 
Lorenzo Marcantonio
Logos Srl