Open source SDSL Debug and Connectivity Unit (OSDCU)
Hardware design specification

Created by Harhan Engineering Co.
for the International Free Computing Task Force

NOTE: the OSDCU board design has already been deemed to be a dead-end in terms
of L2 conversion performance, and the intent is to supplant it with a different
board design using a newer (more capable) FPGA and other board-level design
changes.  The new project name is BlitzDSU; interested parties are encouraged
to subscribe to the opensdsl mailing list.  OSDCU rev 1 is being built as a
transitional step: BlitzDSU is still very far away from realization, and it felt
prudent to "close" the OSDCU project in a cleaner state, with the outstanding
ECOs incorporated and DFM issues fixed.  This document has been updated in those
places where rev 1 boards will differ from rev 0, but the parts describing ideas
that have been abandoned have been left alone as historical artifacts.

The relevant sections for rev 1 changes are: 2.2.2, 2.4.4, 2.4.6.1, 2.5.3.

1. Introduction

This is the design for a hacker's gadget that attaches to an SDSL line through
the RS8973 2B1Q transceiver (bitpump) chip controlled by a microprocessor, and
is intended to support the following functions:

* Direct control of and experimentation with the bitpump through the
  microprocessor.

* Identification of the SDSL flavor used on the line when it's unknown.

* Reverse engineering of SDSL flavors that are not yet fully understood.

* Interfacing the SDSL line to an external router through the synchronous DCE
  port in operational mode.

2. Design overview

The device consists of the following principal components:

* RS8973 bitpump and copper loop interface
* MC68302 microprocessor with RAM and flash
* Altera EPF10K30A FPGA (optionally populated)
* Synchronous serial DCE port
* Asynchronous serial console port

The following figure presents a block diagram of the device.

                                                    +---------+
              +-----+ +-------+                     | RS8973  |
+---------+   | RAM | | Flash |                     | bitpump |
| MC68302 |   +-+-+-+ +--+-+--+                     |         |
|   CPU   |     | |      | |                        |         |
|         +-----+ +------+ +------------------------+ uProc   |
|         |         M68K addr/data/ctrl bus         | i/f     |
|         +----------------------------+ +----------+         |
|         |                            | |          |         |
|         |                          +-+-+--+       |         |
|         |                          |      |       |         |
|         |                          | FPGA |       |         |
|         |                          |      |       |         |
|         |                 +-----+  +-+-+--+       |         |
|    SCC1 |-->--------------|     |    | |          |         |
|         |<----------------|     +----+ +--------->|         +----------------
|         |                 | MUX | SDSL bit stream |         | Copper loop i/f
|         |           +-----|     +--------------<--|         +----------------
|         |           |+----|     |                 |         |
|         |           ||    +-----+                 |         |
|         |           ||                            +---------+
|         |           ||    +-----+
|         |           |+----|     |
|         |           +-----|     |                 +------+
|         |                 | MUX |---------------->| DCE  |
|    SCC2 |-->--------------|     |--------------<--| port |
|         |<----------------|     |                 +------+
|         |                 +-----+
|         |
|         |      +---------+
|    SCC3 |-->---| Async   |
|         |<-----| console |
|         |      | port    |
|         |      +---------+
|         |
|         |      +-----------+
|    GPIO |------|   Misc    |
|    pins |------|  control  |
|         |------| functions |
+---------+      +-----------+

NOTE: The data path multiplexing shown in the block diagram above is simplified
and does not exactly match reality.  See section 2.2 for a more accurate
explanation.

2.1. MC68302 microprocessor

The microprocessor chosen for this design is Motorola/Freescale MC68302
Integrated Multiprotocol Processor (IMP), which consists of an MC68000 core, a
System Integration Block (SIB) and a Communications Processor (CP) with 3
Serial Communication Controllers (SCCs).  This microprocessor has been chosen
for the following reasons:

* The M68000 architecture and the MC68000 core are very classic and a pleasure
  to hack on.

* The SIB eliminates a lot of external glue logic which would complicate the
  hardware design.

* The SCCs are quite useful for OSDCU's intended functionality as explained in
  the next section.

2.1.1. MC68302 system clock frequency

The standard MC68302 system clock frequency for the OSDCU board is 25 MHz.
25 MHz is the highest MC68302 speed grade available in the PQFP132 package for
which our PCB is currently laid out, and it is also the system clock frequency
planned for in the original design.  This system clock frequency should be used
for all configurations that involve on-the-fly Layer 2 conversion: see the
following section.

It possible to run with a lower system clock frequency by populating a different
crystal (see section 2.8), and one can also populate an MC68302 part of a lower
speed grade.  Our first prototype board has been populated with an MC68302CFC16C
part running at 16.67 MHz, but our subsequent board builds have been using
MC68302EH25C parts running at 25 MHz.  The 16.67 MHz configuration is not
recommended for on-the-fly Layer 2 conversion, but it is perfectly sufficient
for bit-transparent DSU operation at all SDSL data rates.

Unfortunately MC68302EH25C is an RoHS part.  The SnPb version (MC68302FC25C)
was only available with a cost-prohibitive minimum order quantity, hence we have
never had such parts.  Only the lower speed grade (MC68302CFC16C) has been
obtained in SnPb.

2.2. Data path multiplexing

The hardware design described in this document was conceived with the goal of
supporting as many different modes of operation with a single hardware platform
as possible without undue complexity or cost.  The design arrived at supports
the following modes of operation:

(1) The bitpump's channel unit interface is connected to the DCE port and
    the MC68302 provides only supervisory functions.  The SCCs are unused.
    This mode supports connectivity to SDSL Flavor B.

(2) The bitpump's channel unit interface is connected to one SCC on the
    MC68302 and the DCE port is connected to another SCC.  A different protocol
    or encapsulation format can be presented on the DCE port than what goes
    over the SDSL link, and code running on the MC68302 mediates the
    conversion.  This configuration has been used successfully to convert from
    Nokia SDSL/ATM to HDLC.

(3) The bitpump's channel unit interface is connected to the FPGA which
    implements a framer, an ATM TC-PHY or any other bit or quat level
    processing necessary to support the quat stream format used by the SDSL
    flavor.  The DCE port can be connected to an SCC and code running on the
    MC68302 can mediate a Layer 2 conversion.  This configuration is currently
    in use at Harhan for converting Nokia SDSL/ATM to HDLC: it is the most
    efficient (least awkward) way of implementing this conversion that is
    currently available to us.

(4) The bitpump's channel unit interface is connected to the FPGA as in
    mode 3, but the DCE port is also connected to the FPGA instead of an SCC,
    and the MC68302 provides only supervisory functions as in mode 1.  This
    mode is the most convenient for supporting SDSL flavors such as HB in which
    only a bit stream framer is needed.  It can also be used to implement a data
    encryption scheme at Layer 1.

(5) The device is used for debug and reverse engineering experiments in which
    nothing is connected to the DCE port.  The bitpump's channel unit interface
    can be connected to an SCC which is then put in the transparent mode, or
    one can connect it to the FPGA instead and hack in HDL.

The following data path multiplexing arrangement is used to support these
different modes:

* SCC1 on the MC68302 is the bitpump interface.  Its receive side is connected
  to the bitpump's RDAT pin and its transmit side is one of the possible data
  sources for the bitpump's TDAT pin.

* SCC2 on the MC68302 is the DCE port interface.  Its receive side is connected
  to the DCE TxD line and its transmit side is one of the possible data sources
  for the DCE RxD line.

* A MUX selects data going to the bitpump's TDAT pin from the following 4
  sources:

  + DCE TxD line
  + inverted DCE TxD line
  + SCC1 transmit output
  + FPGA

* Another MUX selects data going to the DCE port RxD line from the following 4
  sources:

  + bitpump's RDAT pin
  + bitpump's RDAT pin passed through an inverter
  + SCC2 transmit output
  + FPGA

* The bitpump's data and clock outputs and the bit stream received from the DCE
  port are also fed to the FPGA.

The inverted data option is provided because it appears to be a possible option
in SDSL Flavor B.

2.2.1. Bitpump's channel unit interface

The digital interface on which the bitpump chip presents bits received from the
SDSL line and on which it expects bits to be transmitted is called the channel
unit interface because in the original HDSL application it was connected to the
HDSL channel unit.  The bitpump supports 4 modes of operation for this
interface:

  + Parallel master
  + Parallel slave
  + Serial, magnitude bit first
  + Serial, sign bit first

Our data path is bit-oriented and one of the serial modes needs to be used.
Whether the sign or the magnitude bit of each quat comes first is an aspect of
the SDSL flavor.

2.2.2. Clocking arrangement

In data path multiplexing scenarios such as ours it is important to consider
not only the data path itself, but also how it is clocked, as we are dealing
with synchronous serial communication which requires a clock alongside the data
line.

In the transparent bit stream access operation mode (bit stream from the
bitpump connected to the DCE port) the bitpump has to be the clock source.  In
the serial mode it outputs the bit clock on its BCLK pin, drives Rx data on the
RDAT pin on the rising edge of BCLK and samples Tx data on the TDAT pin on the
falling edge of BCLK.  In order to allow the external DTE to sample the Rx data
and provide the Tx data at the right time the BCLK output from the bitpump
needs to be MUXed to the DCE-source Rx and Tx clock lines on the DCE
interface.  However, since we can't tell the bitpump to sample TDAT at any
other time than when it wants to, the DTE-source Tx clock will be ignored in
this operation mode and the DTE has to obey the DCE-source Tx clock.  Normal
or 180 phase clock may be driven on the DCE port in order to accommodate a
wider range of different DTE types and cabling arrangements.

A different semi-transparent operation mode is possible in which the FPGA
implements a framer on the SDSL quat stream, so bits from the bitpump are not
presented directly to the DCE port, but the payload bits within the frame
structure form a bit stream that is presented to the DCE port (e.g.,
Flavor HB).  This mode can be supported by clock gating, i.e., the FPGA framer
and the entire data path operates in the BCLK clock domain, but the clock
driven on the DCE port (MUXed from the FPGA) is a gated version of BCLK that is
gated on for the payload bits in the frame and off for the overhead bits.

A significantly different operation mode is also possible in which the DCE port
functions essentially as a software data link between the external DTE host and
the MC68302 independent of the SDSL bit stream.  In this mode the clock on this
data link can be essentially anything, but because we are the DCE, we have to
provide it.  What should it be?

Using the SDSL bit clock seems natural, but may not always be ideal.  The
considerations are different in the Rx (OSDCU->DTE) and Tx (DTE->OSDCU)
directions:

* In the Rx direction optimal performance will be achieved if the clock rate is
  set to the highest which the DTE can comfortably handle, irrespective of the
  actual SDSL data rate.  For example, if the DTE is a T1-grade router, the
  OSDCU->DTE bit pipe clock can be set to somewhere around 1.5 Mbps, even if it
  is used with a lowly 384 kbps SDSL service.  The packet rate on this interface
  will still be determined by the rate at which packets arrive over SDSL, having
  this interface run at a higher speed will ensure that no Rx packets ever get
  lost regardless of how the ATM->HDLC conversion works out, and because the
  time it takes for each packet to be retransmitted on this synthetic HDLC link
  is added latency, this added latency component is minimized by maximizing the
  bit clock rate.

* The Tx direction is trickier.  Making this interface run much faster than the
  underlying SDSL connection would result in the attached router doing wasted
  work queueing packets for WAN transmission only to have the OSDCU discard
  them, and the useless work of receiving HDLC packets only to discard them
  would not be good for the MC68302 processor on the OSDCU board either.  OTOH,
  setting the bit rate for this interface too low would result in the SDSL Tx
  bandwidth being underutilized.  Determining the exact optimal bit rate is a
  very non-trivial problem, but using the SDSL data rate (BCLK) ought to be a
  sensible starting point.

A "software clock" option is provided in the hardware in order to drive the
DCE-source Rx clock and DCE-source Tx clock lines with a clock that has no
direct relation to the SDSL bit stream and hence to BCLK.  The original design
which is embodied in PCB revision 0 was to use 2xBCLK (double BCLK frequency)
as the "fast software data link" clock; this clock was to be generated by
dividing the bitpump's otherwise-unused HCLK output (16 times the symbol rate =
8 times BCLK) by 4 with a 74HCT74 divider.  However, that design was never
implemented in practice: the rev 0 boards which we have built have had an ECO
applied to use the MC68302's previously-unused BRG1 output instead; see the
ECO 1 document for the details.  This ECO has been incorporated into PCB rev 1.

In summary, the following clocks can be multiplexed to the DCE-source Rx clock
and DCE-source Tx clock lines of the DCE port:

  + BCLK
  + Inverted BCLK (180 phase shift)
  + SWCLOCK
  + A clock from the FPGA

Independent MUXes are provided for the DCE-source Rx clock and DCE-source
Tx clock lines.

Clocks also need to be provided to the SCCs.  Each SCC has separate Rx and Tx
clock inputs.  SCC1 is always connected to the bitpump if used at all,
therefore its clock needs to be BCLK and can be hard-wired without
multiplexors.  MC68302 RCLK1 and TCLK1 are connected to BCLK through an
inverter because MC68302 expects the opposite clock polarity from that used by
the bitpump.

SCC2 on the other hand is always connected to the DCE port if used at all, and
supports the software data link operation mode for the DCE port.  RCLK2 is
connected to the DTE-source Tx clock line from the DCE port; the TCLK2
connection differs between rev 0 and rev 1 boards as explained below.

It needs to be observed that the DTE-source Tx clock is only used when the OSDCU
operates as a software-mediated Layer 2 converter, and in the latter mode it is
actually the *only* clock that matters for the DTE->OSDCU direction.  The clock
provided on CCITT circuit 114 (DCE-source Tx clock) effectively acts as a
"suggestion" for the DTE, and the DTE is perfectly free to generate its own
clock on circuit 113 (DTE-source Tx clock).  It also needs to be noted that if
the DTE obeys the clock on circuit 114 but does not echo it back on circuit 113
(that may be an issue with DEC DSV11 cards), such DTE cannot be used directly
with the current OSDCU in the L2 converter mode.  There are no plans to fix this
limitation on the OSDCU board, but on the BlitzDSU the issue will be solved
trivially inside the FPGA.

Aside from the case of the DTE generating its own Tx clock, on OSDCU rev 0
boards with or without ECO 1 it is not possible to use two different non-BCLK
clocks for the OSDCU->DTE and DTE->OSDCU directions of the software data link
because there is only one "software clock" fed to both CCITT_114 and CCITT_115
MUXes.  Therefore, if two different clocks are desired, one of them has to be
BCLK.

The clocking design has been changed slightly for OSDCU rev 1.  On rev 0 boards
the MC68302 IMP's TCLK2 pin was an input connected to the output of the MUX
driving the CCITT_115 signal to the DCE port; on PCB rev 1 it is an output from
the MC68302 and is connected to one of the inputs of that MUX.  The BRG1 output
is now used only by the other clock MUX, the one driving the CCITT_114 signal.
It is thus no longer possible to use BCLK for the OSDCU->DTE clock in the L2
converter mode, but instead it is now possible to use two different software-
controlled clocks for the two directions.  This clocking arrangement more
closely matches the plans for the BlitzDSU board.

2.2.3. SCC1 modem control signals

In addition to the data and clock pins SCC1 on the MC68302 has 3 modem control
signal pins: CD1, CTS1 and RTS1 (all active low).  These pins are dedicated and
not multiplexed with any other functions.  CD1 and CTS1 are inputs to the
MC68302 and therefore need to be connected to something in order not to float;
RTS1 is an output.  In the design arrived at CD1 is connected to QCLK, CTS1 is
unused and pulled up, and RTS1 is unused and unconnected.

On MC68302 SCCs the CD signal has its traditional meaning of "RxD is good".  As
the SCC1 RxD pin is connected directly to the bitpump's RDAT pin in this design,
SCC1 always receives the SDSL Rx bit stream regardless of whatever else is going
on the board.  It would therefore make logical sense to consider RxD1 to be
always "good" and to indicate so to the SCC by tying CD1 (active low) to GND.
However, in the normal HDLC mode MC68302 SCCs provide a way for software to
ignore the external CD signal and receive regardless; having external CD
asserted is only necessary for the transparent/promiscuous bit stream capture
mode.

In the transparent bit stream capture mode the capture will start only when CD
is sampled low; the first bit captured will be the one immediately preceding
the clock on which CD was sampled low.  Furthermore, once CD has been sampled
low and the capture has started, all further toggling of this pin is ignored.
The implication is that if CD1 is pulled high, promiscuous bit stream capture
cannot be performed, whereas if CD1 is tied low, the capture can be initiated
at any moment by software command.

It thus appears so far that tying CD1 low would be optimal.  However, it turns
out to be even better to connect it to QCLK instead.  Since the transparent mode
requires CD to be sampled low only once and ignores it thereafter, having CD1
connected to QCLK would cause the promiscuous capture to have a known
relationship to the quat boundaries.  (Specifically, the capture will always
start in the middle of a quat.)  HDLC operation is unaffected if the software
CD/CTS mode is selected.

CTS1 and RTS1 are related to the Tx side of SCC1.  The original intent was to
connect them to the FPGA to support injection of locally generated management
packets into the Tx bit stream which is normally sourced from the DCE port.
This capability was intended for implementing CMCP for Copper Mountain, but
it has been defeatured since we now know that CMCP can be disabled per-port on
the DSLAM and since the XSB-2000 DSU which serves as our reference does not
implement such a feature either - it's a totally bit-transparent DSU just like
ours, yet it was officially supported by Copper Mountain as an approved CPE
device.

Since we are not using the CD1 and CTS1 signals in the traditional manner and
they are not wired for such operation, the Diagnostic Mode bits in the SCC1
SCM (SCC Mode Register) need to be set to "software operation".

2.3. M68000 address/data bus

The M68000 bus is used in the 16-bit mode.  As shown in the block diagram,
the devices connected to it are:

* RAM
* Flash memory
* Bitpump's microprocessor control port
* FPGA (if populated and loaded with HDL that uses it)

MC68302 chip select logic is used for all of the above, thus no board level
address decoding or other M68000 bus interface glue logic is needed except
trivial combinational logic to produce traditional output enable and write
enable from R/W, UDS and LDS.  The 4 chip selects are used as follows:

  CS0 - Flash memory
  CS1 - RAM
  CS2 - Bitpump
  CS3 - FPGA

As all bus slave devices are selected by the MC68302 chip select logic and each
chip select bank is no larger than 1 MB, the highest used external address line
is A19.  No traces are wired on the PCB for the upper 4 address lines A23:20.

No devices other than the MC68302 will act as masters on the M68000 bus.
Although it would be possible to allow the FPGA to master the bus, this
capability is sacrificed in this design in favor of reducing the number of
traces that need to be routed on the PCB and thus the cost.  (In addition to
the obvious requirement of wiring the bus arbitration signals, allowing the
FPGA to master the M68000 bus would require wiring all of its regular signals,
many of which are currently omitted thanks to the MC68302 chip select logic.)

If absolutely necessary it might be possible to give the FPGA the ability to
master the M68000 bus by connecting the complete set of bus signals to it with
blue wires.

Motorola has designed the M68000 bus so that it can be treated as either
synchronous or asynchronous.  In this design the bus is treated as asynchronous
for the most part, but the FPGA has the option of treating it as synchronous
when doing so is more convenient.

2.3.1. RAM

The system RAM is 1 MB of SRAM, 16-bit wide to match the M68000 data bus.  This
RAM is implemented with two HM628512BLFP-7 (512K x 8) SRAM chips covering the
two halves of the 16-bit data bus.  These are 70 ns SRAM parts and the MC68302
chip select logic is programmed for 0 wait states; everything appears to work
fine on our 25 MHz boards.

2.3.2. Flash memory

There is a total of 1 MB of flash memory in two 29F040 type chips (512K x 8)
covering the two halves of the 16-bit data bus.  The flash chips are in PLCC32
packages and socketed.  As explained in the software design specification,
flash chips with a uniform sector layout of 8 64KB sectors must be used.  It is
also desirable to use parts fast enough to run with 0 wait states.  Like for
SRAM, we are currently using 70 ns flash parts on our 25 MHz boards.

2.3.3. Bitpump's microprocessor control interface

The RS8973 bitpump has an 8-bit microprocessor control interface (MCI) with a
256 byte register address space.  Because it is connected to a 16-bit data bus
without high/low byte multiplexing, bitpump registers appear 2 bytes apart in
the M68K address space.  The high half of the data bus is used so that the
bitpump registers appear at even addresses in this big-endian architecture.

The bitpump operates mostly in the SDSL clock domain and as a result its MCI
timing is a little unusual.  In its preferred synchronous mode read and write
cycles can take a fairly long time and a READY signal is provided.  The details
can be found in the RS8973 datasheet.  Most designs, including a Copper
Mountain design with an MC68302 family microprocessor have used the bitpump in
its asynchronous mode in which read and write cycles have a fixed short
duration.  However, Conexant's ZipWire Software User Guide contains a note in
section 5.8.4 that's clearly addressed to M68K users and recommends using the
bitpump in its preferred synchronous mode and using READY as DTACK.  We follow
this recommendation in our design and tie the bitpump's READY open drain output
to DTACK and configure the bitpump's chip select (CS2) not to generate an
automatic DTACK.  A separate chip select is dedicated to the bitpump and not
shared with anything else so that its unique timing requirements do not affect
any other devices.

2.3.4. M68K interrupts

The MC68302 interrupt controller is used in the dedicated mode to allow
external interrupts to be signaled with single pins without need for the full
M68000 bus interrupt protocol.  Two interrupt lines are used on the OSDCU.
IRQ1 is connected to the bitpump's interrupt pin and IRQ6 is connected to the
FPGA.

The FPGA is also able to use an additional interrupt line via PB11 (an
MC68302 GPIO pin with interrupt capability) as explained in section 2.5.4.
If the FPGA implements both a cell/frame receiver and a cell/frame transmitter
for SDSL/ATM, it is useful to have separate interrupt lines for the two
with different priorities.

2.4. RS8973 bitpump and copper loop interface

The RS8973 bitpump implements almost the entire line transceiver on-chip.
The only thing standing between the bitpump's analog transmit and receive pins
and the copper loop is a number of passive components.  These consist of a
special line transformer that isolates the copper loop from the terminal unit's
internal circuits, some circuit side passive components required by the RS8973
design, and surge protection (line side and circuit side).

Some of these loop interface passive components need to be optimised for
operation at particular frequencies.  As the frequency spectrum of the SDSL
signal is directly related to the data rate, designing a copper loop interface
circuit that operates at all SDSL data rates from 144 to 2320 kbps without
hardware modifications is a very difficult challenge.  (Notice that the range
of SDSL speeds and hence frequencies spans an order of magnitude.)  Furthermore,
it is actually impossible to have a single circuit that functions optimally at
all data rates, and the loop interface circuits used in commercial multirate
SDSL products are compromises designed to function satisfactorily if not
optimally at the data rates which the product needs to support.

Since our device is a hacker's gadget rather than a commercial product, we can
actually do better.  Since we don't anticipate mass production ever and expect
that each OSDCU will be built individually by hand, we should be able to taylor
each unit's copper loop interface circuit to the data rate at which it is
expected to operate.  This custom tayloring can be done by varying the values
of some resistors and capacitors and choosing the optimal line transformer part.

2.4.1. Circuit side passive components

The circuit between the RS8973 chip and the line transformer's secondary
winding is the one given in section 4.1 of the RS8973 datasheet.  This circuit
consists of the compromise hybrid, impedance-matching resistors in the transmit
path and anti-aliasing filters on RS8973's receive and hybrid inputs.

It appears from examination of some existing SDSL products that some vendors
have made some slight modifications to this circuit.  However, in the absence
of a full understanding of these modifications and their merits we have decided
to stick with the reference circuit given in the RS8973 datasheet.

The reference circuit consists solely of resistors and capacitors.  As explained
above, this circuit is sensitive to the SDSL data rate.  Whereas the RS8973
datasheet presents a circuit that is supposed to work at all data rates, the
documentation for the earlier Bt8960 and Bt8970 transceivers instructed one to
taylor this circuit for the data rate actually used.  In each case the topology
of the circuit has remained the same and only the component values change.
We have laid our board out for the circuit recommended in the bitpump chip
documentation, but we allow ourselves the leeway to vary the component values
if necessary or desired.  On our current boards we have populated the component
values listed in the RS8973 datasheet for the all-rate compromise; in all of our
testing so far the boards have worked fine at all SDSL data rates.

If interest arises, we have the ability to experiment with different values
from here.

2.4.2. Line transformer

This is a very application-specific transformer made by Midcom (and a few other
vendors too, but only Midcom transformers were used in those existing SDSL
products which served as our reference at the beginning of the project)
specifically for use with the Brooktree/Rockwell/Conexant/Mindspeed HDSL/SDSL
transceivers.

Midcom has made several different versions of their HDSL transformer optimised
for use with different bitpump chips at different data rates.  While in our case
the bitpump chip is known (RS8973), the data rate can still vary by an order of
magnitude from 144 to 2320 kbps, and some of the transformer specifications
(the primary inductance and possibly others) are sensitive to the frequency
spectrum of the SDSL signal which is directly related to the data rate.

It is currently unknowable what is the best compromise, and again the argument
applies that since ours is a hand-made hacker's gadget, we can do better than
one size fits all and custom-taylor our loop interface circuit including the
line transformer to the actual expected data rate.  We thus leave the specific
Midcom transformer part unspecified and leave it to experimentation once the
board is built.  All Midcom HDSL transformers have the same footprint[*] and
pinout, and it should be easy to experiment with different parts.

The transformers which should be interesting to experiment with are:

 + Midcom 50050 (or the older equivalent 671-7928 found in the (in)Efficient
   Networks routers which make perfect sacrificial units for parts): recommended
   by the RS8973 datasheet, 2 mH primary inductance, apparently optimised for
   high data rates.

 + Midcom 50051: 3 mH primary inductance, optimised for 784 kbps, may be better
   for the lower data rates common in typical SDSL deployment as a cheaper
   alternative to T1.

 + Midcom 50772: 2 mH primary inductance and improved total harmonic distortion,
   recommended by Midcom for RS8973 and used by Mindspeed with their M289xx
   G.shdsl chipset.

[*] Midcom actually offers both through-hole and SMT versions of their HDSL
transformers.  We have chosen the TH footprint for our design; all Midcom part
numbers given above are the TH versions.  Some have SMT versions and others do
not; we are not aware of any Midcom HDSL transformer that's available only in
the SMT footprint and does not have an equivalent TH version.  The "junk" SDSL
CPE devices which we use as part donors also contain through-hole Midcom
transformer parts.

2.4.3. DC blocking capacitor

The primary winding of the HDSL transformer is split and a DC blocking capacitor
needs to be connected across the central break.  The RS8973 datasheet (4.2)
specifies this capacitor as 1 uF; the capacitors found in all examined SDSL CPE
devices are 1 uF, 250 V, fairly big physically.  The same capacitor specs are
used on our OSDCU board; the physical part is the one that appears in the first-
generation SDSL CPE devices which served as our reference at the beginning of
the project.

2.4.4. Surge protection

NOTE: this part of the board has been completely rethought between rev 0 and
rev 1.

A functional SDSL terminal unit could be built by connecting the ends of the
line transformer's primary winding directly to the line connection jack, without
any additional components such as surge protection.  However, all existing SDSL
CPE devices that have been examined for comparison do have various additional
components in this area.  The observed minimal set of additional components
consists of just two surge protection elements: a crowbar-type overvoltage
protector and a current-limiting fuse.

The design of the surge protection block for OSDCU rev 1 has been guided by the
following 3 principles, in this order:

* First, do no harm - if there is a realistically plausible scenario under which
  a given surge protection scheme would do more harm than good, that scheme is
  undesirable.  This principle drives the choice between a 2-terminal TVS
  (tip & ring only) versus a 3-terminal one (with a ground leg) as explained
  below.

* Do no worse than the competition - if a certain element appears consistently
  in all competing SDSL CPE products, we should have it too - but this argument
  need not apply to those elements which appear only in some specific vendor
  designs but not in others.

* Keep it simple - do the minimum we can get away with in terms of both part
  count and design labor.  Life is too short to be stressing too much over such
  below-the-line design nitpicks, and a user who needs some extra circuitry in
  this area can always implement it externally to the DSU.

The surge protection design that has been chosen for OSDCU rev 1 consists of
just two components: a SIDACtor overvoltage-protecting crowbar switch and a
Telelink fuse (in one leg only) between that crowbar and the line connection
jack.  Unlike rev 0 boards, the intent is that these two components will always
be populated.

2.4.4.1. Overvoltage protection component

Every SDSL CPE device that has been examined for comparison has been found to
contain a transient voltage suppressor (TVS) of the crowbar type.  Most of the
existing designs that have been examined feature SMT components of the DO-214
form factor which appear to be Teccor/Littelfuse SIDACtor (SIDAC-thyristor?)
parts.  Only two deviations from the SIDACtor norm have been observed: the
Siemens 5890 router (M28945+M28927 chipset) uses a GDT instead, and the XSB-2000
DSU uses both TVS types simultaneously.  (The latter seems to be heavily over-
designed, and hence does not serve as our example to be imitated - violates our
goal of simplicity.)

The most common and arguably most sensible design uses a single 2-terminal
SIDACtor; this is the design that has been adopted for OSDCU rev 1.

The fundamental limitation of a single 2-terminal TVS (SIDACtor or GDT) is that
it can only deflect differential-mode surges, but won't do anything for a
common-mode surge.  The best thing that one can do with common-mode surges
would be to deflect them to true Earth ground, but such a true Earth ground is
not practically feasible in the conventional CPE device form factor.

Some designs have used a 3-terminal SIDACtor or GDT, with the middle leg
intended to be the ground connection.  The 3 known examples in the CPE realm
are the XSB-2000 DSU, Mindspeed's reference schematic in the M28927 datasheet
(for their G.shdsl solution), and our own OSDCU rev 0, which was based on the
latter.  However, this design has been disfavored for OSDCU rev 1 on the
reasoning that a true Earth ground connection is infeasible in our application,
and once the Earth ground connection is defeatured, a 3-terminal TVS no longer
makes any sense, and thus the simplest possible single 2-terminal TVS approach
becomes the preferred one.

It is possible that Mindspeed's suggestion of using a 3-terminal SIDACtor with
an Earth ground connection was envisioned for a CO environment, in which a
reliable Earth ground connection for every piece of equipment is normally a part
of the overall plan.  All CO equipment is specially designed for the single
purpose of terminating loops which go out to subscribers, and handling the
possible surges is simply a part of that job.

But the situation is quite different in a typical minicomputer machine room
environment into which our SDSL DSUs are intended to go.  A lightning-arrestor-
grade Earth ground connection simply cannot be expected to be available in our
target environment, and using the circuit ground instead (which is what the
XSB-2000 DSU does) or even the chassis or AC power cord ground would violate
the principle of "First, do no harm".  If the SDSL CPE device uses a 3-terminal
TVS that redirects incoming line surges to the circuit / chassis / AC power cord
ground, it effectively allows such surges to propagate to other equipment in the
machine room, and possibly even shock a human user who happens to be touching
the chassis at the unlucky moment of a lightning strike or power cross.  OTOH,
that same surge may likely stop at the DSU if that DSU uses a 2-terminal TVS
isolated from everything else, or no surge protection elements at all.

Hence the on-board surge protection design for our SDSL DSUs is being changed
from a 3-terminal SIDACtor to a simple 2-terminal one: the never-used ground
connection point is eliminated, and the SIDACtor footprint changes from TO-220
to DO-214.

The availability of DO-214 SIDACtor parts poses no problem: if a sacrificial
EN 5851 unit is used as a parts donor for the expensive EPF10K30ATC144-2 FPGA,
the RS8973 bitpump and the Midcom transformer, the P31B SIDACtor can be pulled
as well.  And if someone needs to build an OSDCU without using a sacrificial
EN 5851 unit, the same SIDACtor part and other variants (same footprint) are
readily available from Digi-Key.

2.4.4.2. Current-limiting fuse component

All existing SDSL CPE devices that have been examined for comparison include
fuses (either the conventional melting type or Raychem PolySwitch PTC resistors)
in addition to the SIDACtor or GDT TVS.  Some designs feature two identical
fuses, one in each leg (tip and ring) between the TVS and the line connection
jack; other designs use a single fuse in only one leg.  The symmetric approach
(two identical fuses) is clearly needed for designs with a 3-terminal TVS
(DSLAM line cards and uncommon CPE like XSB-2000); for designs with a 2-terminal
TVS (no ground path) a single fuse ought to be sufficient, but both approaches
have been observed among the existing CPE variety.

On the OSDCU rev 0 PCB each leg (tip and ring) passes through a Raychem
TR600-150 PTC resistor footprint between the line connection jack and the inside
circuits (the line transformer and the optionally populated SIDACtor).  For
OSDCU rev 1 and the future BlitzDSU, the design is being changed to use only one
fuse (sensibly matching the 2-terminal TVS design), and the fuse type is being
changed from Raychem PolySwitch PTC to Littelfuse Telelink 1.25 A, a melting
fuse.

The switch to a melting fuse is motivated by the principle of "First, do no
harm".  On a first-glance analysis, the fuses appear to be superfluous, and
possibly even deleterious - if the whole point of a crowbar TVS is to dissipate
surges by shunting them, why defeat the TVS by applying the surge voltage to a
PTC resistor instead?  The resistors also needlessly attenuate the SDSL signal.

For a while we were tempted to eliminate the resistors/fuses altogether, but
that approach would violate the principle of "do no worse than the others".
But using a melting fuse of the type that has been found in all of the last-
generation SDSL CPE devices (Siemens 5890, Netopia 4652 and Adtran NV3133)
seems to solve the dilemma perfectly: the normal resistance of this fuse is so
negligible that it is practically a wire jumper, the 1.25 A rating is pretty
high, hence this fuse won't block the shunting of surges until the amount of
energy passing through the shunt starts approaching a fire hazard, and if the
latter condition does occur, having the fuse melt open would be clearly
preferable to the possibility of starting a fire.

The choice of the specific fuse type, including the 1.25 A rating, is justified
on the basis that it is the exact type and rating found in both Siemens 5890 and
Adtran NV3133 CPE devices, hence we are merely copying what the "big guys" are
doing.  This fuse type is a convenient SMT part, and it is readily available
from Digi-Key.  (In contrast, the Raychem PolySwitch PTCs appear to have become
obsolete to the point of no longer being available new.)

2.4.5. Circuit side clamping diodes

It appears to be the standard practice to put 4 clamping diodes on the circuit
(secondary) side of the line transformer, clamping each leg of the secondary
winding to between GND and +5V.  I readily admit to not really understanding the
purpose of this clamping, but it appears in the reference schematics (explicitly
in the M28927 datasheet, and hinted at in the RS8973 one) and in all existing
CPE devices which I've taken the time to examine in detail.  These clamping
diodes are present on OSDCU rev 0, populated on all boards we have built; these
boards work fine, and this part of the circuit will remain unchanged in rev 1.

On our boards (both rev 0 and rev 1) the 4 diodes are packaged in two dual-diode
SOT-23s; the specific part number has been taken from Mindspeed's G.shdsl
schematic+BOM in the M28927 datasheet.

2.4.6. Line connection jack

The SDSL connection jack on the OSDCU is of the 8-position type (RJ-45/RJ-48
style), matching the general convention which seems to have been followed by all
SDSL CPE vendors supporting SDSL/ATM and multiflavor SDSL.  (The only two SDSL
CPE devices known to the Open WAN Connectivity Project which have 6-position
jacks are CR201 and XSB-2000.)  Of course there is no rational connection
between the physical jack type and specific flavors of SDSL/2B1Q (a logic and
software issue), but the distinction may be relevant psychologically when
showing our CPE devices to ISP/CLEC technicians - a "narrow" connection jack
may be associated with the Copper Mountain flavor in someone's mind.

In any case, our use of the "wide" (8-position) line connection jack is now a
part of our form factor for which the sheet metal enclosure design has been
made, hence there are no plans to change it.

2.4.6.1. Tip & ring polarity

At the beginning of the project, the circuit between the RS8973 pins and the
line connection jack has been created by combining the G.shdsl schematic in the
M28927 datasheet with the incomplete schematic given in the RS8973 one.

The RS8973 bitpump has 3 differential pin pairs coming out of it for the line
interface.  The manner in which they are combined outside the chip is shown in
the RS8973 datasheet; the polarity matches up in the naturally intuitive manner.
But the polarity with which the line transformer and the jack should be wired is
not shown in the RS8973 datasheet, hence we had to resort to back-porting from
the G.shdsl version.

Just before OSDCU rev 0 was sent out to PCB fab, I had decided to swap the tip
and ring polarity between the line transformer and the jack relative to the one
depicted in the M28927 reference schematic.  Subsequent experiments with the
functional OSDCU rev 0 boards have revealed, however, that my decision was poor
and that the T/R polarity I had copied originally from the M28927 datasheet
was/is more correct.  (See the tipring-notes file for the full discussion.)

For OSDCU rev 1, the T/R polarity is being reversed relative to rev 0.  The
reversal is being made between the line transformer and the jack: the overall
circuit thus reverts to being what it was originally, and in terms of the
physical PCB layout, this T/R polarity change can be done trivially together
with the surge protection changes (see 2.4.4), without disturbing the good
layout on the secondary side of the line transformer.

It also needs to be noted that this issue of T/R polarity is a purely cosmetic
one: after traveling a few cm inside the terminal device, the SDSL circuit will
run over many meters or kilometers of inter-building/under-street/etc wiring,
and there are many points at which the wire pair might be flipped over.
Therefore, all known SDSL flavors include a software-driven mechanism that
automatically detects and corrects the line polarity on every startup cycle,
effectively masking the difference between "right" and "wrong" wiring polarity
choices.

2.5. FPGA

The FPGA part is Altera EPF10K30ATC144-2 on our current boards.  It is a
population option because it's an expensive part.  (So far we've been sourcing
these parts from sacrificial EN 5851 routers.)  It is not necessary for playing
with the bitpump, bit stream capture and transparent DCE operation (Flavor B),
but it becomes necessary if one wants to implement a framer, an ATM TC-PHY, or
some other bit stream processing beyond the capabilities of the MC68302 SCCs.

The current practical use for the FPGA is implementing a Nokia frame transmitter
with internal buffers which are filled from the M68K bus and serialized out
onto SDSL_TDAT.  Doing so allows the Layer 2 converter from Nokia SDSL/ATM to
HDLC to perform slightly better than it can using the MC68302 alone.  (See the
report on the relative performance of different CPE devices for Nokia SDSL.)

We also have an FPGA logic function that implements SDSL Flavor A (I.432.1) in
both Rx and Tx directions, but it's still experimental.

OSDCU rev 1 plans: because this board revision is merely a transitional step
toward the future BlitzDSU, we don't plan on building more than a minimal
number of these boards.  We expect that each OSDCU rev 1 board we build will be
made from a sacrificial EN 5851 unit (the "new" version that has the FPGA part
we need), and will thus have the FPGA populated for use with the Nokia flavor.

2.5.1. Board signal connections

Connections are provided from FPGA I/O pins to the M68000 bus and to most
of the SDSL data path.

2.5.1.1. M68K bus

The FPGA acts as an addressable slave on the M68K bus.  Our current logic
functions use this capability as follows:

* Each logic function has some control and status registers;

* EPF10K30A embedded array blocks are used to construct dual-ported RAM buffers
  for the ATM cells or Nokia frames to be received or transmitted.  Tx buffers
  appear as regular RAM (R/W access) from the M68K bus; Rx buffers appear as
  read-only to the CPU core.

Connections have been provided to the 16 bit wide data bus, to address lines
A<12:1> and to decoded chip select, read and write strobes.  Providing address
lines only up to A12 has been deemed sufficient because there is very little
memory inside the EPF10K30A device, and reducing the number of signals to wire
reduces the labor cost of PCB layout and routing.

All 16 data lines are connected so that if this interface needs to carry
payload data, full throughput can be achieved.

2.5.1.2. SDSL data path

The FPGA connects passively to the following signals in the SDSL data path:

- BCLK
- QCLK
- SDSL_RDAT
- DCE_TxD

It is able to source the following signals through MUXes:

- SDSL_TDAT
- DCE_RxD
- CCITT_114
- CCITT_115

There also are two FPGA I/O pins wired for the HECSYNC extension as described
in section 2.6.2.

2.5.2. I/O pin assignments

FPGA I/O pins have been chosen for the signals listed in the previous section
for ease of PCB layout and trace routing.  While it is generally a good practice
to let the FPGA compiler choose the I/O pin assignments based on the P&R of the
FPGA design, doing so is infeasible in our design as this is a hacking platform
and it's completely unknown what HDL designs will be loaded into the FPGA.
Therefore we have optimised the I/O pin assignments for the PCB layout and
trace routing instead.

2.5.3. Dedicated clock and input pins

The EPF10K30A device contains 6 global on-chip nets for distributing clocks
and other global signals to the entire design, and there are 6 corresponding
dedicated input pins.  2 of them are for clocks and the other 4 are for other
global control signals.

Which clocks should be fed to the two dedicated clock pins?  There are 4 clocks
available on the board that may be potentially useful to the FPGA: BCLK, QCLK,
HCLK and MC68302_SYSCLK.  The first three are for the FPGA's primary purpose of
operating on the SDSL data path and the last may be helpful for building a
synchronous interface to the M68000 bus.  The CCITT_113 signal from the DCE port
(DTE-source Tx clock) is also a clock and may be useful to the FPGA.

Since the rest of our data path is purely bit-oriented, it makes the most sense
for the FPGA to treat it as being bit-oriented as well, even if the SDSL flavor
deals with quats, i.e., to treat BCLK as the primary clock for the data path
and to treat QCLK as a regular input along with SDSL_RDAT and the various
transmit data sources.  Therefore, QCLK is not connected to either of the
dedicated clock pins and is connected to a regular I/O pin instead.

PCB rev 1 connects one of the two dedicated clock pins to BCLK and the other to
MC68302_SYSCLK.  PCB rev 0 connects the other (non-BCLK) global clock input to
CCITT_113; that decision had been made on the assumption that the M68K bus
interface was going to be treated as asynchronous and that MC68302_SYSCLK was
therefore not needed.  However, it has turned out that the embedded RAM blocks
in the EPF10K30A are single-ported, and the arbitration logic necessary to make
them behave like dual-ported RAM becomes much saner if the internal RAM is
implemented as synchronous with respect to the M68K bus.  Therefore,
MC68302_SYSCLK is needed.

The subsequent experience with implementing NOKFTX and I.432.1 logic functions
has confirmed that the two needed clocks are MC68302_SYSCLK and BCLK; the HCLK
output from the RS8973 bitpump is not needed.

The 4 non-clock dedicated input pins are tied to ground.  None of the signals
listed in section 2.5.1 seem fit for distribution to the entire FPGA via the
global on-chip nets, but those global nets can also be driven internally, in
which case the external pins cannot be used.  The Altera datasheet tells us to
tie these pins to a known logic state and not allow them to float.

The DEV_CLRn and DEV_OE functions are not used in this design either.

2.5.3.1. Loss of the CCITT_113 signal

The CCITT_113 signal from the DCE port (ultimately originating from the attached
WAN router or other DTE) is unavailable to the FPGA on OSDCU rev 1 and on rev 0
with ECO 2 applied; the latter being necessary for the FPGA to be practically
usable.  This signal is not needed for the currently implemented logic
functions, and it is not a concern going forward, as all future development
will be done on the new BlitzDSU board instead.

2.5.4. Configuration

EPF10K30A is an SRAM-based FPGA and supports 3 configuration modes: passive
serial (PS), passive parallel synchronous (PPS) and passive parallel
asynchronous (PPA).  The full details are given in Altera's documentation.
Software on the MC68302 will configure the FPGA in the PS mode using
configuration images stored in flash.

The original intent was to use the PPA mode.  The interface provided for
configuration in the PPA mode is essentially an SRAM-like microprocessor bus
interface just like our M68K bus with decoded chip selects and read and write
strobes, furthermore, the FPGA pins that perform these functions in the PPA
configuration mode become regular I/O pins in the user mode, so the intent was
to kill two birds with one stone by connecting the M68K bus signals to the pins
designated by Altera for PPA configuration.

The plan was changed during PCB layout however.  The layout was improved by
rearranging some of the I/O pin assignments (see section 2.5.2 above), and the
new arrangement precludes the use of the PPA mode.  The PS mode will therefore
be used to configure the FPGA; the resulting miniscule increase in software
complexity is far outweighed by good PCB layout.

The PS configuration mode uses two dedicated pins: DATA0 and DCLK.  They are
connected to MC68302 GPIO pins MC68302_PB7 and MC68302_PB6, respectively.

The FPGA also has 4 dedicated pins that control and monitor the configuration
process at the high level: nCONFIG, nSTATUS, CONF_DONE and INIT_DONE.  They
are connected to MC68302 GPIO pins.  Of these 4 pins INIT_DONE may be
reconfigured as a user I/O pin, and since it is connected to GPIO pin PB11
which has interrupt capability, there is a possibility of using this connection
as a secondary interrupt line in addition to FPGA_IRQ_L which is wired to IRQ6.
(See section 2.3.4 for the explanation.)

2.5.5. JTAG pins

Harhan Engineering Co. does not plan to use the FPGA's JTAG port, and as
described in the previous section, configuration will normally be done by the
MC68302 through GPIO pins.  However, as this is an open source hacking platform
intended for the community, the JTAG pins are wired to a 10-pin header
footprint as prescribed in Altera's documentation.  This connection should
allow Altera's JTAG tools to be used if desired.

2.6. Synchronous serial DCE port

The possible functionality of this port is explained in section 2.2 on data
path multiplexing.  The port's electrical specifications are EIA-422
differential for the data and clock lines and EIA-423 single-ended for the
modem control lines.  Only the drivers are different between EIA-422 and
EIA-423.  Differential receivers are used on all lines that are compatible with
EIA-422, EIA-423 and EIA-232.  The mechanical interface is EIA-530 (DB25F).
The same choice of mechanical interface has been made by several other DSU
manufacturers for exactly the same reason -- the DB25 connector is much more
convenient than the extremely bulky V.35-style one.

2.6.1. Modem control lines

The following modem control lines are implemented on the DCE port: DTR input,
RTS input, DSR output, CD output, and CTS output.  They are under pure software
control as described in section 4.2.

DSR, CD and CTS are driven with single-ended EIA-423 drivers.  The EIA-530
pinout and cabling standard provides wire pairs for these signals and requires
differential receivers; the negative side is tied to ground at the source
end if a single-ended driver is used.  The user must ensure that there is no
EIA-422 termination resistor on the other end of the line -- for the EIA-423
driver this resistor is essentially a short!

2.6.2. HECSYNC extension

The HECSYNC extension to the industry standard synchronous serial interface
provides TxAM and RxAM (alignment mark) signals that run parallel to TxD and
RxD respectively and mark octet, cell or frame boundaries in the bit stream.
When the HECSYNC extension is used TxAM replaces RTS and RxAM replaces CTS.
Because they run in parallel with the main data stream, TxAM and RxAM need to
have the same electrical interface as TxD, RxD and clock signals, in our case
EIA-422.

The OSDCU can optionally use the HECSYNC extension when the FPGA is populated
and implements a framer.  A pair of jumpers connects pins 5 & 13 on the EIA-530
connector either to the single-ended CTS driver and ground or to the
differential RxAM driver.  The situation is simpler for RTS/TxAM because the
receivers used are universal for EIA-422 and EIA-423, and the receiver output
is connected both to the MC68302 GPIO pin used as RTS and to the FPGA for use
as TxAM.

The FPGA is the sole source for the differential RxAM driver's input.  The
original intent was to provide a weak pull-up on that net so that the driver's
input does not float when the FPGA is not populated or not configured, but the
26LS31's internal 22 kOhm pull-up has been deemed sufficient.

2.6.3. Termination resistors and jumpers

Termination resistors are built on-board in front of differential receivers for
TxD and DTE-source Tx clock lines, connected across the wire pair.  The
resistor value is 100 Ohm.  These termination resistors are always necessary on
differential transmission lines operating at high baud rates, and having them
on-board would certainly be appreciated by cable makers.  As these termination
resistors are perceived as always necessary, no jumpers are provided for them;
in the very unusual case that they need to be removed they can be desoldered
from the board.

Similar termination resistors are provided in front of the differential
receivers for DTR and RTS lines, but a jumper is placed in series with
each resistor to make termination an option.  These jumpers will be off by
default because the DTE is much more likely to use single-ended EIA-232 or
EIA-423 drivers for modem control signals, in which case differential
termination resistors must not be used because to a single-ended driver such a
resistor is effectively a short.  If the DTE drives the modem control signals
with differential EIA-422 drivers (e.g., a DEC DD50 multistandard synchronous
serial port), one can install the termination jumpers, but doing so should
generally be unnecessary when modem control signals do not operate at a high
baud rate.  However, if the RTS line is redefined as TxAM (HECSYNC extension),
it needs to be driven by a differential driver and terminated at the receiving
end.

Jumpers are also provided between EIA-423 drivers for DSR, CD and CTS and
the corresponding EIA-530 connector pins.  Because these drivers are single-
ended, there must be no differential termination resistors on the other end.
However, if the DTE has such termination resistors and the user does not wish
to modify the DTE or the cable, and the modem control signals are not needed,
one can instead disconnect them by removing jumpers on the OSDCU board.

2.6.4. Why not V.35?

To the average user the generic concept of a synchronous serial port, the kind
used to connect routers to DSUs, is synonymous with the label of "V.35".  So
why in the world are we building an EIA-422/423 interface and not a V.35 one?

What is less well known is that V.35 is actually the name of a CCITT
recommendation, and the actual CCITT V.35 spec has nothing to do with
1.5-2 Mbps router interfaces which every network administrator today
automatically associates with the "V.35" label.  Instead it was a specification
for a 48 kbps interface.  That's right, 48 kbps!  Moreover, "was" is an
important word, as Recommendation V.35 has been withdrawn by CCITT even before
that standards body became ITU-T.  Therefore, the ubiquitous router-DSU
interfaces that go by the name "V.35" should actually be called V.35-like
interfaces for their use of a V.35-style connector, V.35-like differential
signaling on the data and clock lines, and use of EIA-232 specifications for
modem control lines as in V.35.

When CCITT withdrew Recommendation V.35, the recommended replacement was V.11,
CCITT equivalent of EIA-422, with V.10 (equivalent of EIA-423) for control
lines.  Considering this fact, as well as the fact that EIA-422 is an active
current standard approved for baud rates up to 10 Mbps and a report
(http://www.advice1.com/v35.htm) that despite different specifications on paper
the two interfaces are interoperable in practice, we have decided to design our
interface to EIA-422/423 specifications rather than V.35 ones.

Also note that it is extremely rare to see a V.35 port directly on a router.
Most routers have their own multistandard synchronous serial ports like Cisco
DA60[*] and DEC DD50 and come with cables designed to plug into a V.35 connector
on a DSU.  When DSU manufacturers similarly avoid this extremely bulky and
inconvenient connector and provide their own pigtail cables, one ends up with a
"V.35" interface that exists only in the form of a mated pair of connectors
laying on the floor between the router and the DSU.  One can then just as well
skip this "V.35" middleman and connect the router's DA60 or DD50 directly to
our EIA-530 port.

For more information see the DCE Port Interconnect Application Note.

[*] Cisco calls their connector "DB60", but because it is actually a DA shell
(not DB) with 60 contacts inside, we call it DA60 instead.

2.6.5. Drivers and receivers

The signals received by the DCE port are TxD, DTE-source Tx clock, DTR and
RTS/TxAM.  These 4 signals are received by a single SN75173 quad EIA-422/423
differential receiver.  SN75173 is similar to the classic 26LS32 but accepts
common-mode input voltages of 12 V, which exceeds the EIA-422 and EIA-423
specifications but which we need to support because DTR and RTS may have EIA-232
specifications in a V.35-style configuration.

A single 26LS31 quad EIA-422 differential line driver drives RxD, RxAM, and the
DCE-source Rx and Tx clocks.

The EIA-423 drivers for DSR, CD and CTS are provided by 3 driver sections of an
SN75LBC784 quad EIA-423 transceiver which is also shared with the HEC423
asynchronous console port.

2.7. Asynchronous console port

The console port is standard asynchronous at 9600 baud.  The UART function is
provided by the MC68302's SCC3.  The mechanical and electrical interface is
HEC423, compatible with both EIA-232 and DEC423 (MMJ) and using a convenient
RJ45 style 8-position modular jack connector just like the asynchronous console
ports on Cisco routers.  Only the data leads are used.  The outgoing DTR is
always on and the incoming DTR is ignored.  SCC3 has CTS and CD inputs and an
RTS output, however they are unused.

The console port's line transceiver is an SN75LBC784.  It's an EIA-423
transceiver IC specifically designed to be compatible with both EIA-232 and
EIA-423 interfaces, and contains 4 drivers and 4 receivers.  The asynchronous
console port uses 1 driver and 1 receiver, and the other 3 drivers are used by
the synchronous serial DCE port's modem control signals.

The outgoing DTR is driven directly from the +12 V supply through a resistor.

In addition to being fed to the HEC423 connector J2, the EIA-423 driver output
and ground are wired to a 2-pin header J6.  This header provides a "tap" of the
console output character stream for applications where the OSDCU will be
piggy-backed with a router board in the same enclosure, allowing the router
board to capture a log of the OSDCU board's console output.

2.7.1. SN75LBC784 transceiver tuning

The SN75LBC784 EIA-423 transceiver has the following features that need tuning
in each particular application:

* Series resistors in front of the differential receiver inputs (used only for
  the async console port RxD line in this design)
* Resistor between the Rws pin and the +5 V rail controlling the driver slew
  rate.  This slew rate control is shared for all 4 drivers.

Our PCB provides 0805 footprints for each of these resistors and the optimal
resistor values will be determined experimentally.  The initial population is
470 Ohm and 20 kOhm for the HEC423 RxD series resistors and the slew rate
control resistor, respectively.

2.8. Clock sources

There are 3 primary clock sources on the board:

* MC68302 system clock crystal
* 10.240 MHz crystal for the RS8973 bitpump, used in the generation of various
  SDSL clocks
* An additional 1.843200 MHz oscillator connected to the TIN1 pin on the
  MC68302 to produce standard asynchronous baud rates on the console port.

MC68302 and RS8973 chips both have built-in clock synthesizers and can use
either a crystal or an external clock source.  This design uses classic HC49
crystals for both.

RS8973 has a special requirement that the crystal's load capacitance must be
15.5 pF, and thus a special crystal must be used.  The RS8973 datasheet lists
two recommended crystal suppliers and part numbers, which are custom parts.
Fortunately one of them (GED) is located in close geographic proximity to
Harhan Engineering Co. and sells its crystals in prototype quantities, thus
that part is used.

For the MC68302 system clock crystal GED has told us that no special part is
needed and that there is no need for exactly matching the load capacitance,
because it is perfectly acceptable for the CPU system clock to be slightly off.
This clock is not used for any critical timing: all SDSL clocks are derived from
the RS8973 clock crystal instead, and the baud rate for the asynchronous console
port is derived from the canned oscillator on TIN1.

For general-purpose software timers it is preferable to use TIN1, although it is
also possible to use the MC68302 system clock as long as it is kept in mind that
some boards run at 16.67 MHz while others run at 25 MHz (see section 2.1.1).
See the software design specification for more details.

2.9. MC68302 GPIO pins

MC68302 GPIO pins are used for the following functions:

* LEDs
* DCE port modem control lines
* Data path multiplexor control
* FPGA configuration

MC68302 GPIO pins are PA<15:0> and PB<11:0>.  Some of the pins however are
shared with other functions and don't act as PAn/PBn in this design.  The GPIO
pins are assigned as follows:

Pin	Function
PA0	RxD2 (not GPIO)
PA1	TxD2 (not GPIO)
PA2	RCLK2 (not GPIO)
PA3	TCLK2 (not GPIO)
PA4	Data path MUX control
PA5	Data path MUX control
PA6	Data path MUX control
PA7	Data path MUX control
PA8	RxD3 (not GPIO)
PA9	TxD3 (not GPIO)
PA10	Line Status LED
PA11	Line Status LED
PA12	Data path MUX control
PA13	Data path MUX control
PA14	Data path MUX control
PA15	Data path MUX control
PB0	DCE port DSR output
PB1	DCE port CD output
PB2	DCE port CTS output
PB3	TIN1 (not GPIO)
PB4	DCE port DTR input
PB5	DCE port RTS input
PB6	Connected to FPGA DCLK pin
PB7	Dual function, see below
PB8	FPGA CONF_DONE
PB9	FPGA nCONFIG
PB10	FPGA nSTATUS
PB11	FPGA INIT_DONE

PB7 serves a dual function.  It is connected to FPGA DATA0 pin for PS
configuration mode, and it also controls the red side of the Unit Status
bicolor LED (see section 2.10).  The two functions do not conflict because the
FPGA's DATA0 input is ignored at all times except during configuration,
allowing free use of the signal for the LED, and having the LED blink oddly
during the brief FPGA configuration sequence is deemed acceptable.

Three additional multifunction pins are CTS3/SPRxD, RTS3/SPTxD and CD3/SPCLK.
Neither function is used in this design.  We nonetheless treat them as CTS3,
RTS3 and CD3 as this is the default power-up configuration.  The CTS3 and CD3
inputs are tied to GND and the RTS3 output is unconnected.

2.10. LEDs

One must connect the asynchronous serial console port in order to obtain
detailed information about the state of the device, SDSL status and current
operations and to exercise control over the unit and its operations.  However,
a small number of LEDs are provided for light path diagnostics:

* A green power LED - always on, not under software control.

* A bicolor red/green Unit Status LED. The green LED lights simultaneously
  with the assertion of the DSR modem control signal on the DCE port to indicate
  that the unit is running operational software (i.e., operational connectivity
  function rather than debug/experimentation). The red LED will light on severe
  software error conditions such as exceptions which trap to the monitor.

* A bicolor red/green Line Status LED. This LED is under full software control
  via two dedicated GPIO pins and is intended to indicate SDSL status.
  Specifically, it is intended to correspond to the CD modem control signal on
  the DCE port, perhaps with some additional indication (the CD signal can only
  have 2 states whereas a bicolor LED has 4). Green should correspond to CD
  asserted (link up) and the other 3 states (off, orange, red) should correspond
  to different link conditions under which CD would be negated (not attempted,
  in progress and failed, respectively).

* A green LED not under software control indicating the DTR signal received
  from the DTE.

3. Additional hardware considerations

3.1. Physical realisation

The original intent was to fit the OSDCU board inside the enclosure from a
gutted (in)Efficient Networks router (in the place of its main PCB) by copying
its form factor.  Those abominable routers have inflicted an incredible
amount of pain and grief on SDSL users, and that pain and grief was one of the
main driving factors behind the Open SDSL Connectivity Project, so it seemed
like a fitting twist to replace the abominable router with an open source
solution by gutting it and sticking a new open source board inside.  The
(in)Efficient Networks logo should be removable from the plastic with chemical
solvents.

However, this idea was eventually decided against.  Even though it would have
been a great twist and would have given us an enclosure for free, there are also
benefits to having a form factor chosen by us rather than someone else.  The
final physical design which has been reduced to practice is a simple rectangular
PCB, although some of its features date back to the historical plan of copying
FP/EN's form factor.  This board has been used bare on a lab bench during the
initial bring-up process, but then Harhan Engineering Co. had contracted with
Vinatech Engineering Inc. in San Diego, California to design and manufacture a
custom sheet metal enclosure for our form factor.

One feature of the OSDCU which dates back to the historical plan of copying
FP/EN's form factor is the power supply.  Our board takes DC power input, and
the intent is that this power will be provided by an Amperor AOF25 open frame
power supply like that used in EN routers.  The enclosure designed by Vinatech
provides mounting places for the OSDCU board and for the AOF25; an IEC 320 AC
mains entry module snaps into a cutout on the rear panel.

3.2. Power supplies and logic voltages

This is a 5V design.  All principal components including the MC68302 and the
RS8973 have 5V TTL inputs and outputs, and 5V parts have been chosen for the
other components for an all 5V design.  However, the RS8973 bitpump needs 3.3V
core voltage (core only, no 3.3V I/O pins), so both 5V and 3.3V power supplies
are necessary.

3.3V supply is also needed for the FPGA.  5V FPGAs are no longer available
unfortunately, and the closest that could be found was Altera EPF10K30A, a 3.3V
part.  This part requires 3.3V core voltage and has MultiVolt I/O pins, however
on 3.3V parts the I/O voltage cannot be 5V, only 3.3V or lower.  Therefore we
have to operate the FPGA with 3.3V I/O pins.  However, the inputs on this part
are perfectly 5V tolerant and the outputs with a 3.3V I/O supply meet the TTL
high level spec, so the 3.3V FPGA should work OK in our otherwise all 5V design.

Additional +12V and -12V power supplies are needed for the SN75LBC784
EIA-423 transceiver.

The AOF25 provides +5V, +12V and -12V power supplies.  The OSDCU board has a
6-pin power input connector like that used in EN routers.  12V is used for the
SN75LBC784 and the rest of the board runs off the +5V supply as follows:

* One inductive filter produces +5VDD from the primary +5V input, powering all
  digital +5V logic.
* Another inductive filter produces +5VAA from the primary +5V input, powering
  the analog side of the SDSL bitpump.
* A third inductive filter produces a dedicated power supply for the RS8973
  chip's VPLL pins from the primary +5V input.
* A linear regulator provides 3.3V for the RS8973 core.
* Another linear regulator provides 3.3V for the FPGA.  It is a population
  option along with the FPGA itself.

3.3. Reset

MC68302 needs a power-on reset signal and is designed to provide a software
reset to other system components (RS8973 is the only other component in this
design that has a reset pin).  MC68302 has separate RESET and HALT pins, both
of which need to be pulsed low on power-up, however, they should remain separate
nets.  This design provides separate SYS_RESET and M68K_HALT nets, each with the
appropriate pull-up resistor.  An ADM709 power supply monitor generates the
primary reset pulse which is then applied to the SYS_RESET and M68K_HALT nets
by 74LS07 open collector buffers, very similar to the sample design given in
the MC68302 manual which has the same arrangement for the RESET and HALT nets
and has LS05 open collector inverters pulling both nets low given an active
high reset pulse from the reset timer circuit suggested there.

The SYS_RESET net is also connected to the RST pin on the RS8973 bitpump.
The bitpump will thus be reset on power-up and also whenever the MC68302 pulls
the SYS_RESET net low as a result of executing the RESET instruction.  The
pull-up resistor on SYS_RESET is 1.2 kOhm as given in the MC68302 manual for
full bidirectional reset function.

3.4. Part selection

Most components are surface mount, however, components with wide pin spacing
have been chosen whenever possible for ease of soldering.  No BGAs are used.
Although unfortunately some of the components are now only available
lead-free, traditional SnPb parts will be used whenever possible for
classicness and reliability.

3.5. Debug headers

The most critical step in bringing this board up (aside from the smoke test)
was getting the MC68302 to execute some instructions from flash, to blink some
LEDs and to talk on the console port.  This part was actually more critical
in terms of bring-up than anything to do with SDSL (the ostensible primary
function of the device), and indeed the first board assembled for bring-up
didn't even have the bitpump or the FPGA populated to make it easier to
concentrate the bring-up efforts on the M68K subsystem (MC68302, RAM, flash,
console port).

It is generally a good practice to add debug header footprints to boards in the
design phase to ease the subsequent bring-up phase.  However, as always there is
a trade-off between looking ahead to the bring-up phase and expending additional
labor in the design and layout phases.  Based on the reasoning above regarding
subsystem criticality, the compromise chosen by this designer was to place debug
headers around the MC68302 on those M68K bus nets which were deemed sufficiently
critical and not to put any debug headers or test points in parts of the circuit
deemed non-critical (such as around the FPGA).

The OSDCU board has two MICTOR38 connectors providing logic analyser access to
the M68K bus, which if necessary can allow one to see all bus cycles made by the
processor.  The following signals are brought out:

* M68K address bus M68K_A<19:1>
* M68K data bus M68K_D<15:0>
* M68K bus control signals: M68K_AS, M68K_DTACK
* SYS_RESET, M68K_HALT, MC68302_BERR
* Decoded read/write strobes: M68K_URDS, M68K_UWRS, M68K_LRDS, M68K_LWRS

4. Hardware-software interface

4.1. Memory map

Although the memory map is under software control on the MC68302, it is best
treated as an aspect of the hardware design.  The following memory map has been
adopted:

Start		End		Resource
00000000	000FFFFF	RAM
00200000	002FFFFF	Flash memory
00600000	006001FF	Bitpump registers
00700000	00700FFF	MC68302 internal 4 KB DPRAM and register block
00800000	008FFFFF	FPGA

4.2. MC68302 GPIO registers

The control and data direction registers will need to be programmed as follows
(see section 2.9):

PACNT = 0x030F
PADDR = 0xFCF0
PBCNT = 0x0008
PBDDR = 0x02C7

PADAT assumes the following functions:

Bit	Access	Function
<15:14>	R/W	SDSL transmit bit source select:
		00 - DCE port TxD line
		01 - DCE port TxD line, inverted
		10 - SCC1
		11 - FPGA
<13:12>	R/W	Data select for the DCE port RxD line:
		00 - SDSL RDAT bit stream
		01 - SDSL RDAT bit stream, inverted
		10 - SCC2
		11 - FPGA
<11:10>	R/W	Line Status LED code as follows:
		00 - off
		01 - green
		10 - red
		11 - orange
<9:8>	-	Reserved
<7:6>	R/W	DCE-source Tx clock select:
		00 - BCLK
		01 - Inverted BCLK (180 phase shift)
		10 - SWCLOCK (see section 2.2.2)
		11 - FPGA
<5:4>	R/W	DCE-source Rx clock select, same encoding as <7:6>.
<3:0>	-	Reserved

PBDAT assumes the following functions:

Bit	Access	Function
<15:12>	-	Reserved
<11>	R	FPGA INIT_DONE
<10>	R	FPGA nSTATUS
<9>	R/W	FPGA nCONFIG
<8>	R	FPGA CONF_DONE
<7>	R/W	Used for FPGA passive serial configuration
<6>	R/W	Used for FPGA passive serial configuration
<5>	R	RTS input from the DTE (1=asserted)
<4>	R	DTR input from the DTE (1=asserted)
<3>	-	Reserved
<2>	R/W	CTS output to the DTE (1=asserted)
<1>	R/W	CD output to the DTE (1=asserted)
<0>	R/W	DSR output to the DTE (1=asserted)

5. Layout and mechanical design

5.1. PCB outline

The OSDCU is laid out on a 130 mm by 165 mm PCB.  It approximately matches
the size of existing SDSL boards of similar complexity, namely CM's CopperRocket
and the functional section of the (in)Efficient Networks 5851 router's board.

5.2. Mounting elements

The placement of the mounting holes is detailed in the PCB drawing.  The larger
holes accommodate M4 screws and are intended for primary securement of the board
to the future enclosure.  The smaller holes in the corners accommodate M3 screws
and are included "just in case".

5.2.1. Chassis ground

If an enclosure is later built for the form factor described herein, it will
certainly be metal.  It is thus desirable to provide a "chassis ground" to which
we would connect the shield ground pin of the EIA-530 connector and which would
presumably be physically grounded via the ground wire of the AC power cord.

The copper annuli of the mounting holes described in section 5.2 serve as our
chassis ground.  The two mounting holes for the DB25F connector (J1) are plated
as well and their copper annuli are also connected to our chassis ground, as
the connector part has a piece of metal which inserts into these holes and is
connected to the outside metal shell.

This chassis ground will normally be separate from the circuit ground, but a
footprint has been provided for a zero ohm resistor that can connect the two if
desired.

5.3. Fixed component locations

5.3.1. External connectors

The following connectors are placed along one edge of the PCB with the
intent of protruding through the rear panel of the eventual enclosure:

* RJ45-style console port
* EIA-530 DCE port connector (DB25F)
* RJ45-style DSL connector

Although it won't become a hard requirement until we make the enclosure, the
locations of these connectors should not change in subsequent PCB revisions.
The edge along which these connectors are placed is logically called the top
edge in layout.

5.3.2. LEDs

The LEDs are placed along the opposite edge of the PCB from the external
connectors, which is logically called the bottom edge in layout.

The LEDs are of the right angle type and shine parallel to the board surface.
Two different LED parts are used (green and bicolor red/green), but they have
identical physical dimensions.  As with the connectors, the intent is for the
LEDs to protrude through the eventual enclosure.

Just like the external connectors, the LEDs should not change their location in
future PCB revisions.

The order of the LEDs from left to right is:

* Power
* Unit Status
* Line Status
* DTR

5.3.3. DC power input connector

The exact location of this connector is not critical; in the current revision
of the PCB it is located in the lower left corner.  This location is expected
to become fixed once we make the enclosure with a designated place for the
AOF25 power supply.

5.4. PCB layout description

5.4.1. Layers

The PCB has 4 copper layers.  One of the middle layers is a mostly-solid ground
plane, the other carries signals and a number of power traces.

The layer stack-up is:

L1	Component (top)
L2	Ground plane
L3	Middle signal layer
L4	Solder (bottom)

5.4.2. Component placement

It is highly preferable to place all surface mount components on the top side
of the board.  Having components on the underside of the board makes assembly
more difficult and expensive and creates additional concerns for the future
enclosure design; the fact that none of the other existing SDSL CPE products
examined so far have any components on the underside clearly indicates that a
design of this complexity does not require going to two-sided population.

This being said, if placing certain components on the underside of the board
makes the layout significantly easier or cleaner, an exception can be made as
long as the number of components on the underside is kept to a minimum.

5.4.3. Ground plane

There are 3 grounds on this board: digital ground, SDSL analog ground and
chassis ground.  The chassis ground is not a part of the ground layer, instead
it consists of a few fattish traces on the bottom layer interconnecting the
copper annuli of the mounting holes and the EIA-530 shield ground pin; there is
also a trace on the top layer leading to the footprint for the optional
resistor connecting chassis ground with the circuit ground.

The ground layer is used for both the digital ground and the SDSL analog ground.
The PCB is divided into 3 logical and physical areas with respect to the ground
plane:

* Digital ground section
* Analog ground section
* No ground section

The digital ground section comprises most of the board.  The DC power input
connector is located in this section; since it is a through-hole part and thus
penetrates all layers, its ground pins connect directly to the digital ground
plane.  The microprocessor subsystem, the FPGA, the DCE and console serial
ports and all miscellaneous logic are laid out in this digital ground section.

The analog ground section of the PCB contains the part of the circuit between
the analog side of the SDSL transceiver chip U2 and the circuit side of the
line transformer T1.  This circuit is shown on page 6 of the schematic drawing
and described in section 2.4.1 of this document.  (Note that all components in
the analog ground section are passive.)

The no ground section has no ground plane at all (a clearing in the ground
layer) and contains the part of the circuit between the SDSL jack J3 and the
primary side of the line transformer T1.  The only components in this circuit
are the line side surge protection and the DC blocking capacitor.  This
part of the circuit connects directly to the line from the telco and needs to
be completely isolated from all CPE internal circuits, including power and
ground, hence no ground or power planes in this section.

SDSL transceiver U2 and line transformer T1 are critical components in terms of
physical location, as they demarcate the boundaries of the 3 sections just
described.  U2 sits on the boundary between the digital and analog sections,
whereas T1 needs to sit on or next to the boundary between the analog and no
ground sections (see below).

The RS8973 bitpump chip comes in a rectangular PQFP-100 package, and its pinout
directly facilitates the division of the PCB into digital and analog sections.
Viewing the pinout from the top with pin 1 on the upper left, the line
separating the two sections passes vertically between pins 48 & 49 and between
82 & 83.

Our PCB has both the digital ground plane and the analog ground plane on the
same layer.  The two are divided by a clearing in the plane, but are also
connected by a copper bridge at a single point.  The clearing passes directly
underneath U2, coinciding with the digital-analog boundary in the chip's own
pinout; the bridge is made on the bottom layer and connects to each side of the
ground plane with a set of stitching vias.

The boundary between the analog and no ground sections at line transformer T1
may be implemented in two different ways.  One way is to place the transformer
so that its secondary winding pins land in the analog section (with the analog
ground plane underneath) and its primary winding pins land in the no ground
section; the analog ground plane would end somewhere underneath the transformer.
The other way is to place the transformer completely in the no ground section,
but align it so that its secondary winding pins are right next to the section
boundary; the traces from these pins would lead into the analog section and the
analog ground plane would end outside the transformer's footprint.  The
designer's preference is for the second approach; this approach is implemented
in the current revision of the PCB.

5.4.3.1. Ground nets in the schematics and layout

Although the digital ground plane and the analog ground plane are different in
the physical layout, they are electrically connected and thus have to appear as
one net in the netlist.  Net name GND in our netlist refers to both grounds.
The schematic drawings use different graphical symbols for the two grounds, but
both symbols refer to net GND.  Careful attention must thus be paid during
layout as to which ground is used and the graphical schematic drawings need to
be consulted for clarification.  However, since all circuits which logically
and physically fall into the digital section of the PCB use digital GND and all
circuits which logically and physically fall into the analog section use analog
GND, the real potential for confusion is not great.

Chassis ground is a separate net named Chassis_GND and no potential for
confusion exists there.

5.4.4. Power routing and bypass capacitors

While most of the board runs on +5V, there are actually several different +5V
power nets to be concerned with:

"raw" +5V
+5VDD
+5VAA
+5V_8973PLL

The ONLY components powered from the "raw" +5V net (the one that comes directly
from the DC power input connector J4) are the 3 inductive filters which produce
the other 3 +5V nets listed above and the two linear regulators for +3.3V.
Most of the board is powered from +5VDD, whereas the other two filtered +5V
power supplies are dedicated for the SDSL analog section and the RS8973 clock
PLL, respectively.

Filter inductors L1 through L3 should be placed next to the DC power input
connector J4; the "raw" +5V net does not have to be carried far in this
arrangement.  The power layer will be dedicated mostly to +5VDD and polygons may
be used liberally; however, +5VAA and +5V_8973PLL also need to be carried from
their respective filter inductors to the area of the board where they are needed
(around U2).

In the current schematics the 3.3V regulators U17 and U21 are powered from the
"raw" +5V, thus necessitating the routing of this power net past the filter
inductors area to wherever those regulators are placed.  This arrangement is
preferred, but if routing this extra power net proves too burdersome, it would
be possible to change the design and have the regulators powered from +5VDD
instead.

C27 is the only bypass capacitor which is not dedicated for only one chip.
It serves the entire digital part of the circuit and should be placed directly
after filter inductor L3.  All other bypass capacitors are component-specific
and their placement is described in the following subsections.

5.4.4.1. Power supply for microprocessor U1

The MC68302 microprocessor has a single power supply.  It is realised as a
local power mini-plane in the form of a solid rectangle contained inside the
rectangle of the PQFP pads on the component layer.  All microprocessor power
pins have traces going inward from the pads to the power mini-plane.

4 bypass capacitors are used.  All 4 caps are placed on the component layer
around the corners of the PQFP and connect with traces to the corners of the
power rectangle.  There is one larger 1206 cap (C30) and 3 smaller 0805 caps
(C31, C32, C33).  The power input to the entire arrangement is a pair of
stitching vias carrying +5VDD from the power layer to the component layer.

5.4.4.2. Power supplies for SDSL transceiver U2

RS8973, the SDSL transceiver aka bitpump, requires a total of 4 separate power
supplies:

* Digital core (3.3V)
* Digital I/O pins (5V)
* Analog section including line transmitter power (5V)
* Dedicated clean power supply for the PLL (5V)

Due to the hostile relationship between our project and the chip vendor, no
reference design or other authoritative advice can be obtained from the latter
regarding power supply or other layout considerations; the only documentation
is the RS8973 datasheet.  The following power layout is proposed by the present
designer (look at Figure 1-3 on page 1-5 of the RS8973 datasheet as you read):

* The VDD2 (digital I/O) supply shall be a strip on the component layer running
  under the chip vertically from pin 98 to pin 33, with a branch to pin 17 on
  the left.  Two 0805 bypass caps (C20 and C21) shall be placed at its top and
  bottom ends (on the component layer "hugging" the chip) and the +5VDD input
  from the power layer shall go to one of those caps.

* The VAA supply shall be a similar strip on the opposite side of the package
  (right in the pinout drawing) running from pin 81 at the top to pins 54 & 55
  at the bottom, branching to the other VAA pins in between.  3 bypass
  capacitors shall be used: one larger 1206 (C22) and two smaller 0805s (C23 and
  C24).  All 3 shall be placed on the component layer as close as possible to
  the chip.  C22 shall be placed next to VAA pins 63 & 64, C23 and C24 shall be
  placed at the ends of the strip.  The +5VAA net shall go from C22 directly to
  filter inductor L2 where this supply is "generated" from the "raw" +5V.

* The VPLL pins are 41 and 46, and each has a directly adjacent PGND pin.  All
  pins in question are located to the left of the imaginary line dividing the
  digital and analog sections, i.e., on the digital side.  Physically adjacent
  VPLL and PGND pins clearly call for bypass capacitors to be placed directly
  across these pins, as close to the chip as possible, and we shall do so.
  These caps are C41 and C42.  0402 caps would have been ideal, but our current
  PCB has been laid out for 0603 caps.

  Past the bypass caps, the PGND pins are connected with vias to digital
  ground, whereas traces from the VPLL pins going past the caps form the
  +5V_8973PLL net going to filter inductor L1 where this supply is "generated"
  from the "raw" +5V.

* The VDD1 (digital core, +3.3V) supply is a power mini-plane, a rectangle with
  4 bypass caps in the corners similar to that for U1.  However, in order to
  reduce clutter on the component layer, it has been decided to move this power
  mini-plane to the bottom layer along with the caps.  It is a rectangle
  underneath the chip on the opposite side of the board, with care taken so that
  it doesn't cross into the analog section of the board and stays completely on
  the digital side.  All VDD1 pins connect to this rectangle through vias.

  4 bypass caps are placed on the underside of the board at the corners of this
  rectangle, with care taken that the ground they connect to is digital GND,
  i.e., on the digital side of the "moat" in the ground plane.  There is one
  larger 1206 cap (C15) and 3 smaller 0805 caps (C16, C17, C18); the +3.3V_8973
  trace from 3.3V regulator U17 goes through a set of stitching vias and
  connects to the power rectangle near C15.

Unless another exception is made for some other components, 4 bypass capacitors
C15 through C18 shall be the only components placed on the underside of the
board.

5.4.4.3. Power supply for the FPGA

The EPF10K30A FPGA has a single +3.3V power supply in this application.  It
is realised similarly to that for the microprocessor: as a local power
mini-plane in the form of a solid rectangle contained inside the rectangle of
the TQFP pads on the component layer.  All FPGA power pins have traces going
inward from the pads to the power mini-plane.  No distinction needs to be
made between VCCint and VCCio power pins.

4 bypass capacitors are used.  All 4 caps are placed on the component layer
around the corners of the TQFP and connect with fat traces to the corners of
the power rectangle.  There is one larger 1206 cap (C37) and 3 smaller 0805
caps (C38, C39, C40).  The power input to the entire arrangement (net
+3.3V_FPGA) is a trace from 3.3V regulator U21 to C37.

5.4.4.4. Bypass caps for 3.3V linear voltage regulators

ADP3303 linear voltage regulators (U17 and U21) require their own bypass
capacitors on both input and output.  1206-sized MLCCs are used in this design.
These capacitors should be considered part of the regulator and placed as close
as possible to the ADP3303 chip.

5.4.4.5. Power supplies for EIA-423 transceiver U13

SN75LBC784 is powered by 12V.  +12V and -12V are brought to U13 from DC power
input connector J4.  Power traces begin on the bottom layer (L4), go through
middle layer L3 and emerge on the top layer (L1) right next to U13, where a
single bypass capacitor to ground is placed for each supply.

SN75LBC784 does not draw power from the +5V supply; the latter is connected only
to serve as an internal voltage reference.  In order to make this voltage
reference very clean and stable, a special filter is implemented as shown on
page 5 of the schematic drawing.  This filter shall be laid out next to the
SN75LBC784 chip itself.

5.4.4.6. Power supply and bypass caps for all other components

All other components which draw power take +5VDD via a single power pin.  A
single 0805 bypass capacitor is provided for each such component and shall be
placed next to it on the component side of the PCB.  +5VDD shall be routed from
a via from the power layer first to the capacitor, then to the chip.

5.4.5. Layout of the analog signal section

All components and nets which are to be laid out in this section of the PCB
appear on page 6 of the schematic drawing.  In this instance the schematic
drawing of the circuit closely matches its intended actual layout.

Due to the hostile relationship between our project and the bitpump chip
vendor, no reference design or other authoritative advice can be obtained from
the latter regarding layout; the only available documentation is the RS8973
datasheet which contains very little specific advice related to layout.  Some
logical inferences have been drawn from comparison with the datasheet for the
newer M28927 chip (which has a little more layout advice) and from independent
reasoning.

The layout of the analog signal path should be as symmetrical as possible with
respect to the positive and negative sides of the differential signals, with all
corresponding traces of equal length.  All traces in the entire analog signal
section should also have equal width.

5.4.5.1. Anti-aliasing filters

The anti-aliasing filters shown in dashed boxes on the schematic drawing should
be placed as close to the RS8973 pins as possible, keeping the trace lengths to
a minimum.

5.4.5.2. Compromise hybrid circuit

The compromise hybrid circuit shown in a dashed box on the schematic drawing
should be laid with the same physical topology as it is drawn on the schematic,
all on the top layer without vias except on nets leaving the dashed block.
All components in that dashed box should be placed as close together as
possible.

5.4.5.3. Voltage reference capacitors and bias resistor

There are 8 pins along the analog edge of the RS8973 package with the
requirement that a passive component (capacitor or resistor) be placed between
each pin and the analog ground.  These components shall be stacked up naturally
in a row alongside the analog edge of U2 with short traces to the respective
pins on one side and vias to the analog ground plane on the other.  The passive
components should be placed as close to U2 as possible and the connecting traces
should be as short as possible.

5.4.6. Microprocessor subsystem

The core microprocessor subsystem consists of the MC68302 (U1), RAM (U7 & U8),
flash memory (U5 & U6) and the read/write strobe decoding logic (U3 & U4).
These components should be placed as close together as possible.
