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

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

NOTE: This document assumes that the reader has read the IFCTF Open SDSL
Connectivity Project web pages at:

http://ifctfvax.Harhan.ORG/OpenSDSL/

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 production mode.

2. Design overview

The device will consist of the following principal components:

* RS8973 bitpump and copper loop interface
* MC68302 microprocessor with RAM and ROM
* 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 original intent was to run the MC68302 system clock at 25 MHz and to use a
25 MHz processor part.  Unfortunately, the RoHS abomination got in the way.
Digi-Key had 25 MHz MC68302 parts available only lead-free.  A few pieces of
the leaded 16.67 MHz MC68302CFC16C were available and we have grabbed them
before they were gone, but the leaded 25 MHz MC68302FC25C was listed as
available only with a cost-prohibitive minimum order quantity.

The first prototype will be populated with MC68302CFC16C and will run at
16.67 MHz (see section 2.8).

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.

(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.

(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.

(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 data and clock signals 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.  Consider
an SDSL Flavor A application in which the FPGA implements an ATM TC-PHY and
presents ATM cells to the MC68302 via data buffers constructed on the M68000
bus, and code running on the MC68302 mediates Layer 2 conversion between native
ATM on the SDSL side and an FUNI presented on the DCE port.  HDLC framing
overhead (bit stuffing) depends on the data and can range from 0 to 20%,
whereas the ATM framing overhead (cell headers) is about 10% independent of the
data.  It thus depends on the data which is more bit-efficient.  If the
artificial synchronous serial interface constructed for the FUNI runs at the
same bit rate as the SDSL link, the Layer 2 conversion may incur an overrun in
either direction depending on the data.

One possible solution is to operate the FUNI link at a bit rate deliberately
higher than that of the SDSL link.  In this case overrun in the ATM to FUNI
direction is not possible, and in the other direction the DCE can flow-control
the DTE via the CTS line.  The OSDCU hardware design supports this option by
allowing a clock of twice the SDSL bit rate to be MUXed to the DCE port.  This
clock is generated by dividing the bitpump's HCLK output (16x the symbol rate =
8x the bit rate) by 4.  Because this clock is used for a software data link
that's essentially independent of the SDSL bit stream, this clock does not need
to have any particular phase relationship to BCLK or QCLK.

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)
  + 2x bit rate clock
  + 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, and TCLK2 is
driven with the same clock as selected for the DCE port Rx clock line.

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
since we know now that CMCP can be disabled per-port on the DSLAM and since the
Rhythms Enterprise DSL network is gone, leaving only small independent operators
with CM DSLAMs, our intended management packet injection capability is no
longer needed.

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 will be 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
and the MC68302 system clock signal is not connected to any other devices.

2.3.1. RAM

The system RAM will be 1 MB of SRAM, 16-bit wide to match the M68000 data bus.
70 ns or faster SRAM parts will enable reliable operation with 0 wait states
with a 25 MHz MC68302 system clock.

This RAM will be implemented with two HM628512BLFP-7 (512K x 8) SRAM chips
covering the two halves of the 16-bit data bus.

2.3.2. Flash memory

There will be 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
will be 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, 70 ns or faster parts will enable reliable 0 wait state
operation with a 25 MHz MC68302 system clock.

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'll
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 will also be 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 would be 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.  We shall initially populate the component values listed
in the RS8973 datasheet for the all-rate compromise and experiment from there.

2.4.2. Line transformer

This is a very application-specific transformer made by Midcom (and apparently
one or two other transformer vendors as well, though only Midcom transformers
have been found in existing SDSL products that were available for reverse
engineering) 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 value of this capacitor
will be 1 uF per RS8973 datasheet section 4.2 and the voltage rating will be
250 V matching that found in existing SDSL products.  This capacitor will be
a large through-hole component like that found in the existing SDSL products.

2.4.4. Surge protection

As this design is for a hacker's gadget, one is tempted to omit the surge
protection altogether.  However, it is prudent to include at least a modicum of
surge protection similar to that found in standard SDSL products, or at least
to provide footprints for the surge protection components.

While the RS8973 documentation does not offer any specific advice on the surge
protection design, examination of several existing SDSL products, the reference
schematics given by Mindspeed for their G.shdsl solution and rational analysis
of the problem at hand (what kind of surges can be expected and how can one
protect from them) have led to the following design.

The primary line side surge protection component will be a SIDACtor, ideally of
the Pxxx3ACMC type.  It is not exactly clear which specific type and part would
work best, and there may also be a problem with the availability of parts in
prototype quantities, so a TO-220 footprint has been provided matching the whole
3-terminal SIDACtor family while the exact part is left unspecified for now.
The footprint may also be left unpopulated.

The third pin on the 3-terminal SIDACtor devices is the Earth ground connection.
It may or may not be connected.  Common SDSL CPE products do not use surge
protection that employs an Earth ground connection, as apparently DSL users
cannot be expected to provide this connection.  However, a 3-terminal SIDACtor
with an Earth ground connection can effectively deflect both common mode and
differential mode surges.  In our design the SIDACtor's Earth ground pin is
connected to a terminal post on the back of the board.  Advanced users who
desire the greatest protection can connect it to Earth ground, however, if this
pin is left unconnected, the resulting surge protection is no worse than that
in the competing SDSL products.  The limitation of this arrangement is that if
a common mode surge occurs, there is no path to deflect it to ground and the
potential exists for the surge to reach the circuit by breaking down the
dielectric in the line transformer or the PCB material.

NOTE: The ground connection discussed above is Earth ground, NOT circuit
ground!  One of the key requirements of a good design is to isolate all internal
circuits (and that includes the circuit ground and power supply) from the phone
line, and it's one of the main functions of the line transformer.  Connecting
the circuit ground to the line through the SIDACtor would defeat the purpose.
Connect the Earth ground only if you know what you are doing.

An additional line side surge protection measure will consist of PTC resistors
inserted into both legs of the loop after the SIDACtor (toward the jack).  They
will limit the current of surges shunted by the SIDACtor.  These
current-limiting PTC resistors need to be inserted into both legs of the loop
because we are using a 3-terminal SIDACtor with an Earth ground connection.
(Some competing SDSL products use a single PTC resistor on one of the legs, but
they use a 2-terminal TVS and provide no other path for the current.)

Note that the PTC resistors serve ONLY to limit the current of surges shunted
by the SIDACtor.  If the SIDACtor is not populated, the PTC resistors have no
useful function and only worsen the transmission line.  Therefore, if the
SIDACtor is not populated, the PTC resistors should not be populated either and
wire jumpers should be put in their place.

2.4.5. Circuit side clamping diodes

Because common mode and differential mode DC surges cannot pass through the
line transformer, most surge protection is needed only on the line side.
However, it is possible for the transmission line to be shorted with AC power
wires, creating a differential mode AC surge that will pass through the line
transformer.  For this reason an additional surge protection measure is built
on the circuit side of the transformer.  It consists of 4 ordinary diodes
(packaged as 3-pin double diodes) that clamp each leg of the secondary winding
to between GND and +5 V.

The clamping diodes are independent of the line side surge protection and will
normally be populated.

2.5. FPGA

The FPGA will be Altera EPF10K30ATC144 (TQFP-144 package, grade dependent on
part availability and pricing).  It is a population option because it's an
expensive part.  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.

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 will be able to act as an addressable slave on the M68K bus.  The
following two primary uses are envisioned for this capability:

* The bit stream processing logic implemented in the FPGA may need some software
  monitoring and control registers.
* If the SDSL payload needs to be presented to the MC68302 after bit stream
  processing by the FPGA (e.g., the FPGA implements an ATM TC-PHY and code
  running on the MC68302 needs to get to the cell payload), one will most
  likely need to use the EPF10K30A's embedded array blocks to implement on-chip
  buffers and make them accessible via the M68K bus.

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
- CCITT_113

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.

The design arrived at for the first spin of the PCB is to connect one of the two
dedicated clock pins to BCLK and to connect the other to CCITT_113.  As the
primary purpose of the FPGA is bit stream processing, it is expected that BCLK
will probably be the only clock needed by most functions implemented in the
FPGA.  Although we could connect MC68302_SYSCLK as well in order to support a
synchronous interface to the M68K bus, the registers and buffers interfaced to
the bus are expected to be simple enough that an asynchronous interface like
that used by system SRAM would be more straightforward.  We are thus
sufficiently confident that we can omit the connection of MC68302_SYSCLK, at
least on the first spin of the PCB.

Another clock that may be potentially useful is HCLK, which runs at 8 times the
BCLK frequency and can thus be used to provide up to 8 internal intermediate
state transitions per each bit processed.  Once again however, although the
capability might be useful in theory, this use has been deemed sufficiently
unlikely to omit the signal on the first spin of the PCB.

CCITT_113 on the other hand may be useful when implementing a framed flavor
like HB or IDSL with clock gating.  The FPGA will in this case generate the
CCITT_114 and CCITT_115 signals for the synchronous serial DCE port.  The Rx
direction is straightforward (the FPGA generates both DCE_RxD and CCITT_115
clocking it), but in the Tx direction there is a choice: the FPGA may either
sample DCE_TxD at fixed times coordinated with the generated CCITT_114 signal,
or it may use CCITT_113 for greater robustness.

A reasonable implementation using CCITT_113 would be to collect DCE_TxD in a
shift register clocked by CCITT_113, and then transfer to a register in the
BCLK clock domain during the overhead portion of the Tx frame away from the bit
slots in which CCITT_114 is gated on.  In this implementation the shift register
clocked by CCITT_113 would be the only synchronous logic not in the BCLK clock
domain, and it thus makes sense to think of a "CCITT_113 clock domain".
Connecting CCITT_113 to the remaining dedicated clock pin thus fits the bill
perfectly.

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.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 will be 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 will be used on all lines that are compatible
with EIA-422, EIA-423 and EIA-232.  The mechanical interface will be 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 will be driven with single-ended EIA-423 drivers.  The EIA-530
pinout and cabling standard provides wire pairs for these signals and allows
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 will be 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 TBD.  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
DB60 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 DB60 or DD50 directly to
our EIA-530 port.

For more information see the DCE Port Interconnect Application Note.

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 will be 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 will drive RxD, RxAM, and
the DCE-source Rx and Tx clocks.

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

2.7. Asynchronous console port

The console port will be standard asynchronous at 9600 baud.  The UART function
will be provided by the MC68302's SCC3.  The mechanical and electrical
interface will be 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.  Data leads only will be used.
The outgoing DTR will be always on and the incoming DTR will be ignored.
SCC3 has CTS and CD inputs and an RTS output, however they will be unused.

The console port's line transceiver will be 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 will use 1 driver and 1 receiver, and the other 3 drivers will be
used by the synchronous serial DCE port's modem control signals.

The outgoing DTR will be 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 will
be 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 will be used.

For the MC68302 system clock crystal the original intent was to use a generic
off the shelf part, but GED has graciously offered to characterize our circuit
when it's built and give us a spec for the ideal crystal it should use.  For
the first prototype GED has given us a few of their off the shelf crystals
near 16.67 MHz.

Note: since the load capacitance will not be perfectly matched between the
circuit and the crystal on the first prototype, the frequency will likely be a
little off and should not be relied upon for critical timing.  Also because
some units will be built with 16.67 MHz MC68302 system clock while others will
have 25 MHz clock (see section 2.1.1), it is preferable to use the extra clock
on TIN1 for general-purpose software timers measuring longer intervals where
high resolution is not necessary.

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, amber, 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 seems
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 be a
great twist and would give us an enclosure for free, there are also benefits to
having a form factor chosen by us rather than someone else.  The physical design
thus arrived at is to build our device on a simple rectangular PCB which can be
used bare on a lab bench; once the board works and once some end user-useful
functionality of SDSL connectivity is achieved, an enclosure can be built later.

Despite not copying FP/EN's full mechanical form factor, we have still adopted
one aspect from their design: the power supply.  Our board will take 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.  During development and
experimentation in the lab one can use a bench power supply or the AOF25 may be
placed loosely next to our board; when an enclosure is later built, it will need
to house both our board and the AOF25 and to provide an IEC 320 AC mains entry.

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 will
have a 6-pin power input connector like that used in EN routers.  12V will be
used for the SN75LBC784 and the rest of the board will run 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)
will be getting the MC68302 to execute some instructions from flash, to blink
some LEDs and to talk on the console port.  This part is 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
probably won'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 is to place debug
headers around the MC68302 on those M68K bus nets which are deemed sufficiently
critical and not 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 will hopefully allow us 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 - amber
<9:8>	-	Reserved
<7:6>	R/W	DCE-source Tx clock select:
		00 - BCLK
		01 - Inverted BCLK (180 phase shift)
		10 - 2x bit rate clock
		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 will 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.
