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 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. (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 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. 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, this design has been changed with ECO 1 to use the MC68302's previously-unused BRG1 output instead; see the ECO document for the details. If we ever make another revision of the OSDCU PCB, this ECO will be incorporated. 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, and TCLK2 is driven with the same clock as selected for the DCE port Rx clock line. 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. If this problem occurs in the real world, perhaps we could add a jumper to the next PCB revision that would switch RCLK2 between CCITT_113 and CCITT_114. Aside from the case of the DTE generating its own Tx clock, in the current design (PCB rev 0 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, it two different clocks are desired, one of them has to be BCLK. One possible design change considered for the next revision of the PCB would be to change TCLK2 from an input to an output, and instead of connecting it to the CCITT_115 output from the respective MUX, make it an input to that MUX, such that the BRG1 output would be used only by the CCITT_114 MUX. If such a change is made, it will no longer be possible to use BCLK for the OSDCU->DTE clock in the L2 converter mode, but instead it will become possible to use two different software-controlled clocks for the two directions. 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 if necessary for functions like buffer access arbitration. 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 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. 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 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. The most immediate plan for the FPGA is to implement a Nokia frame transmitter with internal buffers which are filled from the M68K bus and serialized out onto SDSL_TDAT. Doing so is hoped to enable the Layer 2 converter from Nokia SDSL/ATM to HDLC to perform better than it can using the MC68302 alone. 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, or if the M68K core needs to fill buffers for the FPGA to transmit from), 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 planned for the next spin of the PCB is to connect one of the two dedicated clock pins to BCLK and to connect 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. 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. However, the Nokia frame transmitter (a fairly representative logic function for this FPGA) has already been implemented to the point where it compiles successfully into an RBF, and there was no need for HCLK, just BCLK. Therefore, we feel confident enough to continue omitting this signal on the next PCB revision. CCITT_113 will be connected to a regular I/O pin on the FPGA in the next PCB revision. 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 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.