doc/ideas/database.txt

   1 # $Id$
   2 #
   3 #
   4
   5 Please note that this document is a work in progress and
   6 currently represents a proposal for a future enhancement.
   7 The goal of this document is to define what changes need
   8 to be made to the .pcb file and library handling.
   9 Hopefully with sufficient up front
  10 thought and review, the implementation will correctly address
  11 some of the issues faced in real printed circuit board design
  12 work.
  13
  14 Once the functionality describen in this document have been
  15 implemented, this document will be replaced by a corresponding section
  16 in the manual.
  17
  18 ==========
  19 Motivation
  20 ==========
  21
  22 Currently the elements in the pcb database are stored with the
  23 following features/limitations.
  24
  25 - rotated elements have their internal contents all rotated as opposed
  26   to the element as a group having a parameter specifying a rotation.
  27   This causes two main problems.  The first issue is that there is no
  28   way to determine the rotation of a part without resorting to
  29   looking for which quadrant pin 1 is in relative to the center of the
  30   part.  This algorithm may not be correct for all footprints and
  31   will cause issues with the XY manufacturing file.
  32
  33   The second problem is that it makes it harder to globally update a
  34   particular footprint in a design.  Suppose you find a problem with
  35   your 0402 footprint and you want to update all of them in your
  36   layout.  Your .pcb file currently may have up to 8 versions (4
  37   rotations, 2 sides) of the 0402.
  38
  39   proposal:  store a board side and rotation flag for the element as a
  40   whole.  The internal contents of the element will show top layer
  41   and 0 rotation.
  42
  43 harry: comment
  44   The internal contents should remain rotated and on the layer they are on.
  45   This avoids constantly re-computing these values for every re-draw for
  46   example. The flags can inform the system how to transform the component
  47   back (or transform a replacement version forward) to the "standard"
  48   format. Presumably this would be an uncommon operation in which the
  49   computations take place.
  50 end-comment harry
  51
  52 - footprints largely don't have a concept of where they came from.
  53   This means there is not a convenient way to tell pcb "update all of
  54   the 0402's on this board".  In addition, there is not a good way of
  55   telling if an element has been modified after placement.  For
  56   example, place an element and move the silk location or change the
  57   soldermask clearance.  It would be good to be able to distinguish
  58   these "post-instantiation" changes from the original footprint.
  59
  60   proposal:  store the elements in two parts:  the unmodified
  61   footprint followed by a list of changes (move silk by (+10,+25)
  62   mils, change square flag on pin 1, etc.).
  63
  64 harry: comment
  65   better to again store the modified footprint followed by a list
  66   of how it was modified (thus making the modifications reversible).
  67   Again this saves constantly re-computing with highly repetitive
  68   operations like drawing compared to seldom done operations like
  69   figuring out the un-modified version (which at the moment is not
  70   possible so it is as seldom done as can be imagined.
  71 end-comment harry
  72
  73   proposal:  store the 'newlib' name for the footprint (note that we
  74   plan on adding a step to the build system which extracts a newlib
  75   style library from the m4 libraries so that the core of pcb will
  76   only deal in newlib libraries).
  77
  78   This should allow the implementation of a feature which reports all
  79   elements whose unmodified definitions do not match the library.  In
  80   addition it should allow the implementation of the following
  81   footprint update options:
  82
  83     - update selected instance
  84     - update all instances of the same master
  85     - update all instances of any master
  86
  87     - preserve user changes when doing the update
  88     - clear user changes when doing the update
  89     - preserve a selected set of user changes (like maybe keep the silk
  90       changes but not the square flag change)
  91
  92     - provide a "dry run" report of what would change if the selected
  93       updates actually were applied
  94
  95
  96 - the issue of updating footprints brings up a few other considerations.
  97
  98   When refering to the library search path to see if any footprints are
  99   out of date, how does one deal with multiple footprints with the same
 100   name in different directories?   One thought, based on an idea by
 101   Ales, is to locate all footprints in the library with the same name
 102   and compute a hash on a canonicalized version of the footprint.  This
 103   hash could be compared to a hash for the footprint in question in the
 104   layout.  If none match, the user would probably need to be prompted to
 105   pick which one he/she wants to update to.  If a match is found, then
 106   we know which footprint the master was.
 107
 108