The OSDCU PCB layout needs to be updated for rev 1.  The following 3 sets of
changes need to be made:

1. Fix the DFM (design for manufacturability) issues that have been raised by
   Vorhies during the assembly of rev 0 prototype boards.  These issues are
   listed in the assembly-feedback text file.

   Aside from the trivial cosmetic issue of pin 1 indication for JP2 & JP3,
   all of these DFM issues result from my (Falcon's) poor choice of initial
   footprints from the M4 library, and are NOT Ineiev's fault.  The footprints
   whose initial choice has turned out to be poor are the two PLCC32 flash ICs
   (U5 & U6) and all 0603/0805/1206 discretes.

1a: In the case of U5 & U6, the original footprint made no accommodation for
    the size of the socket body, causing the U5 & U6 reference designators, and
    more importantly, the associated bypass caps to be placed in an area taken
    up by the socket body.

    A new PLCC32 footprint has been drawn, in which the silk outline marks the
    space that will be taken up by the socket on the finished board.  Updated
    U5 & U6 elements using the new footprint can be found in the fp-fixed.pcb
    file.  These updated elements need to be moved into OSDCU.pcb, and those
    other objects (components and silk marks intended for the end user) which
    fall into the unavailable space need to be moved away.

1b: The physical R and C parts have been found to fit the footprints on the
    OSDCU rev 0 PCB rather poorly: the footprints were/are too small in the
    long direction.  The assembler had to wiggle the parts slighly sideways
    to solder them down, and that is clearly a DFM problem in need of fixing.

    The IFCTF M4 library has been updated in the recent years to produce
    somewhat different 0603/0805/1206/etc footprints.  Harhan has built some
    small test boards using the new footprints, assembled at Vorhies, and the
    assembler's feedback was positive.  The updated elements, also contained in
    fp-fixes.pcb, should be incorporated into OSDCU.pcb, if it is possible to
    do so without totally disrupting the board layout.  If such non-disruptive
    update isn't possible, some compromise solution will need to be found so
    that we can make more physical boards without expending too much effort
    on redoing the layout.

2. There are some changes in the netlist which need to be reflected on the
   PCB.  The OSDCU.net file located in this directory as a CVS version-
   controlled item is the new authoritative netlist.  The netlist changes
   consist of ECOs 1 and 2 having been adopted for the next board spin; both
   ECOs have been announced on the opensdsl mailing list and have been arrived
   at in the course of bringing up the SDSL/ATM Layer 2 conversion
   functionality.

2a: As part of these netlist changes, U20 and its bypass cap C34 are gone from
    the MCL, hence they are to be gone from the PCB as well.  Perhaps the
    freed-up PCB space can be used to ease the implementation of the other
    necessary layout changes for rev 1.

3. The surge protection circuitry currently implemented on the OSDCU (between
   the line transformer T1 and the SDSL connection jack J3) has turned out to
   be poorly thought through, and will likely be changed to a different circuit
   topology before we send the next PCB rev out to fab.  However, these circuit
   changes aren't known yet: some more research remains to be done, and the
   final choice of footprints to be placed on the PCB will depend on our
   ability to obtain the physical parts which are to be populated onto those
   footprints.

   When the surge protection circuit design changes are finalized, another
   change will be made to the MCL and to the netlist.  However, those changes
   will be strictly confined to the no-ground-plane section of the PCB in the
   corner between T1 and J3, and are thus completely orthogonal to the change
   sets 1 & 2 above.  Therefore, it should be possible to work on the latter
   change sets now, without waiting for the surge protection changes, and be
   confident that no wasted work will occur.

Aside from a slight difference in the generation of the CCITT_115 clock signal
in the L2 converter mode (already reflected in the netlist), OSDCU rev 1 will
be functionally identical to OSDCU rev 0 with ECOs 1 and 2 applied.  Therefore,
it will still suffer from exactly the same performance limitations, and thus
won't be a viable end user product.  The latter will be yet another board
revision, planned name BlitzDSU, in which the Altera FPGA will be changed to a
newer part and the L2 conversion data path will be moved from the MC68302 into
the new FPGA.  However, that new board design is still very far away from
reality (the board level design hasn't been started yet, only the mental
concept and the Verilog code for the new FPGA), and we need *some*, at least
semi-working, SDSL units in the meantime, hence the decision to make OSDCU
rev 1 in the interim.

The implication of the above business logic is that the labor effort expended
on this OSDCU rev 1 should be limited.  If the changes requested above can be
implemented with a small amount of effort, let's do it, otherwise a quicker,
lower-effort compromise interim solution needs to be sought until we are ready
to start building the new BlitzDSU board.
