The XSB-2000 made by XAVI in Taiwan (also rebranded as Lucent DSLPipe and as Larscom CupreDSU) is a true bit-transparent V.35 DSU for SDSL/2B1Q Flavor B.

The product in question has been discontinued a very long time ago and is very hard to come by. 5 years have elapsed between the moment we have first heard of the Larscom version and the moment we have finally obtained a few of these units. However, the good news is that a member of our project has scored a whopping 10 of these units from the Weird Stuff Warehouse and would most likely be willing to disburse them to SDSL users in need of such devices. (Please post on our mailing list if you need one.) In addition MegaPath has a stash of the Lucent version which is convertible to the Copper Mountain flavor with a single jumper change as explained below.

The two stashes (ours and MegaPath's) won't last forever, but we have our own hardware design which performs exactly the same function and which we can manufacture in any required quantity.

Inside the box

The XSB-2000 has a rather peculiar internal architecture. To start with, it has two processors: an ARM-based network processor (KS32C5000) and an 8051 variant. Each runs its own firmware. The 8051 controls the RS8973 SDSL bitpump while the ARM just sits there and does nothing.

That's right, the much fancier and presumably much more expensive processor out of the duo really sits there and does nothing! It might play some role in unhalting the 8051 or giving it some go-ahead command on power-up, but afterward it does absolutely nothing except monitor the 8051's status and make some of it visible to the user via the craft serial port. The user can interact with the ARM firmware via the just-mentioned craft serial port (runs at 57600 baud, rather inconvenient for non-PC users), but the functions available therein include absolutely nothing useful. In particular one cannot configure any aspects of the SDSL flavor or even the STU-C vs. STU-R role or the data rate via the craft serial port: instead all of those functions (which the 8051 is in charge of) are configured via jumpers and DIP switches as explained below.

The KS32C5000 processor features 2 HDLC interfaces and even a 10/100 Mbps Ethernet interface on chip, but none of that fancy functionality is used in the DSU product. None of that stuff is needed for a bit-transparent DSU, instead all that's needed is to connect the bitpump's RDAT output and TDAT input to the V.35 transceiver, and that is exactly what the XSB-2000 does.

Or at least that's the configuration found in the final product that has been shipped to customers; the hardware design is actually capable of a little more than that. The PCB has a footprint for a 3-pin jumper labeled JP6; the silk screen markings call its two possible positions BYPASS and THRU. However, on both Larscom-branded and Lucent-branded units which have passed through my hands JP6 was not populated as a user-configurable jumper, instead there was a permanent soldered jumper in the bypass position.

Tracing out the PCB has confirmed that JP6 indeed switches the data path. In the bypass setting which is in effect on standard shipped units the V.35 transceiver is connected directly to the bitpump's RDAT and TDAT pins (well, going through an XOR gate to handle possible data inversion, see below); if JP6 is moved to the thru setting, the bit stream going to SDSL TDAT will be sourced from one HDLC core in the ARM chip and the bit stream going to the V.35 port will be sourced from the other HDLC core. (However, the clock put out on the V.35 port remains BCLK passed through an XOR gate in both configurations. The same clock is put out on CCITT circuits 114 and 115 — two separate V.35 drivers are used, but their inputs are connected to the same net.)

The arrangement whereby the bit stream may either be passed through unaltered or handled by two HDLC cores is virtually identical to what we have on our own OSDCU, even though the two designs are totally independent. (We have designed the OSDCU having given up on the idea of obtaining what we thought was Larscom's DSU design, and our first OSDCU board was already built and working when a bunch of XSB-2000 units suddenly landed in our lap.)

I have replaced the soldered jumper at JP6 with a user-changeable one on one of the XSB-2000 units we've got (the Larscom version), but I have only performed very very limited testing with that jimper moved to the thru position. (This very limited testing consisted merely of powering the unit up and observing that the status display shown on the craft serial port looked completely unchanged.) I have every reason to believe however that since these units left the factory with a non-user-changeable soldered jumper in the bypass position, it is extremely unlikely that their ARM firmware would do anything useful in the thru configuration. It also needs to be noted that according to the documentation we've been able to find, the HDLC cores in this ARM chip are really just HDLC, not flexible like Motorola/Freescale SCCs, hence it is very unlikely that an XSB-2000 could be hacked into a Layer 2 converter from SDSL/ATM to HDLC. Instead one should use our OSDCU for that function.

SDSL flavor support

The SDSL transceiver used in the XSB-2000 is RS8973. It seems that the product was designed with the 2.3 Mbps-capable RS8973 from the get-go like our OSDCU, i.e., there are no indications of them having started out with Bt8970 with an external clock synthesiser. The RS8973 bitpump is controlled by an 8051 variant (obviously taken from the chip vendor's reference design) and this 8051 is also responsible for SDSL flavor control.

Although the only SDSL flavor that can be usefully supported by a bit-transparent V.35 DSU like XSB-2000 is B, there still are a number of possible options within Flavor B, and this DSU is able to function as either STU-C or STU-R. The 8051 microcontroller which effectively manages the DSU functionality of the XSB-2000 takes 6 control inputs:

2 jumpers (JP3 and JP4) select the subflavor of Flavor B to be implemented;
A block of 4 DIP switches on the rear panel select STU-C vs. STU-R operation and the data rate.

JP3 and JP4 select the flavor as follows:

JP3   JP4   Flavor            STU role [*]
OFF   OFF   Vanilla           STU-R only
OFF   ON    Copper Mountain   Controlled by DIP switch 4
ON    OFF   Vanilla           STU-C only
ON    ON    Vanilla           Controlled by DIP switch 4

[*] We recommend always setting JP4 ON.  When JP4 is ON, JP3
    selects between vanilla and CM flavors and DIP switch 4
    controls the STU role: up is STU-R and down is STU-C.
    If JP4 is OFF, DIP switch 4 is ignored, the STU role is
    selected by JP3, CM flavor is unavailable.

The only supported flavors are Copper Mountain and vanilla Flavor B. In the CM STU-R mode the DSU autodetects the data rate indicated by the DSLAM just like CM's own CPE; in the CM STU-C mode the DIP switches select one of 7 CM data rates and the DSU emulates a CM DSLAM by transmitting CM's pulse train.

The alternative vanilla flavor offered by XSB-2000 has the following characteristics:

The quat orientation is sign bit first.
The set of possible data rates is the RS8973 preferred set: 144, 272, 400, 528, 784, 1168, 1552 and 2320 kbps.
No pre-activation, the data rate must be configured with DIP switches on both ends.

XSB-2000 does not seem to have ever implemented Conexant/Mindspeed's AutoBaud.

DIP switches 1 through 3 on the rear panel select the data rate as follows:

Switch 1   Switch 2   Switch 3   Vanilla flavor   CM flavor
                                 STU-C or STU-R   STU-C [*]
Down       Down       Down       144 kbps         160 kbps
Down       Down       Up         272 kbps         208 kbps
Down       Up         Down       400 kbps         320 kbps
Down       Up         Up         528 kbps         416 kbps
Up         Down       Down       784 kbps         invalid [+]
Up         Down       Up         1168 kbps        784 kbps
Up         Up         Down       1552 kbps        1040 kbps
Up         Up         Up         2320 kbps        1568 kbps

[*] In CM STU-R (CPE) mode the data rate is autodetected and the
    DIP switches are ignored.

[+] The firmware acts funny when this invalid setting is selected,
    but we haven't investigated it in depth.

Because XSB-2000 is a totally bit-transparent DSU and the bit clock output from the bitpump is put out on the V.35 port, the attached router can see clock frequency changes as the DSU auto-switches data rates in the CM STU-R mode. When the link is down and the activation state machine is waiting for the CM speed code signal, the bitpump clock has been observed to run at 768 kbps in the XSB-2000 implementation. (In CM's own CPE implementation which we have reproduced in our SDCORE it runs at 160 kbps instead.) Because XSB-2000 does not actually support 768 kbps as an operational data rate in any configuration, if you observe it running at this clock rate (either by observing the clock frequency put out on CCITT circuits 114 and 115 or by looking at the status screen via the craft serial port), you know that it's configured as a CM STU-R and it's waiting for the speed code signal.

Other noteworthy aspects of how this DSU implements the Copper Mountain flavor are:

The 2320 kbps data rate is not supported in the CM mode, only in the vanilla mode which is not CM-compatible (uses the opposite quat orientation). CM pre-activation does have a code defined for 2320 kbps, but since both CE200 DSLAM line cards and standard CM CPE for SDSL use Bt8970 bitpumps, we suppose the XSB-2000 designers had every right not to count 2320 kbps as a valid CM data rate.
Being totally bit-transparent, the XSB-2000 DSU does not implement CMCP. Nonetheless, Larscom's version of this DSU was officially blessed by CM as a valid CPE choice.

Data inversion

The data path between the bitpump's RDAT and TDAT pins and the V.35 transceiver passes through XOR gates whose other input is controlled by jumper JP5. When JP5 is ON, the bits pass through unaltered; when JP5 is OFF, each bit is inverted.

Data inversion must be disabled (JP5 installed) for both Copper Mountain and IFCTF flavors.

Lucent and Larscom versions

In the Lucent version which we have received from MegaPath for examination the jumpers were factory-configured as follows: JP3 and JP4 ON, JP5 OFF. (We thus infer that Ascend/Lucent's variant of Flavor B used data inversion, but was vanilla otherwise.) The manual included in the box does not explain the function of any jumpers and does not tell the user to change them for any configuration (contains no instructions for opening the plastic enclosure at all), but does explicitly acknowledge the support for both STU-C and STU-R roles and tells the user how to set the DIP switches on the rear panel.

Larscom's version was marketed as a CM CPE device and factory-configured with JP3 OFF, JP4 and JP5 ON. The main part of the manual tells the user to leave the DIP switches (and of course the insides too) alone, but there is also an appendix which tells the user how to use a couple of such units over a dry pair. That appendix tells the user to open the plastic enclosure (gives the instructions) and move a jumper from JP5 to JP3, thereby creating a configuration identical to the Lucent version.

Neither version has ever blessed the user to configure the unit as a CM-flavored STU-C, nor have they thought that a non-constrained dry pair user might want to use the cleanest possible vanilla Flavor B with no data inversion.

Firmware

The firmware accessible via the craft serial port in Larscom's version is slightly inferior compared to the one in the Lucent version. Although neither version allows any useful configuration changes, the status screen in the Lucent version is a little richer and reports the flavor configuration settings established by the internal jumpers. Larscom's version OTOH provides no reliable way to check the flavor configuration settings without opening the plastic enclosure.

The difference is definitely in the ARM firmware. Although we haven't verified it for sure because it would be a pita (the firmware flash chips are soldered without sockets despite being PLCCs), we have every reason to suspect that the 8051 firmware (the one that does all the real work and is responsible for the repertoire of supported flavors) is most likely identical between the two versions.

V.35 port

The hand-off port is poorly designed on this DSU. The physical connector on the unit is a DB25F and it has an EIA-530-like pinout, but it is not a compliant EIA-530 interface. Instead the documentation calls it V.35 and the user is supposed to use a pigtail cable shipped with the unit that converts it to a real V.35 connector.

Examination of the guts has revealed that the port's electrical specifications really are V.35, not EIA. The V.35 transceiver for the data and clock lines is an LTC1346ACSW, and the modem control signals are handled with a Sipex SP232, a MAX232-like EIA-232 transceiver.

Although the differential data and clock signals would be totally interoperable in practice between the LTC1346 and an EIA-530 interface, if one tried to connect the port to a router using an EIA-530 cable, modem control signals would not be correctly received in either direction:

Although unnecessary, an EIA-530 DTE has the right to drive DTR and RTS with a differential EIA-422 driver like 26LS31, and it appears that for example the 5-in-1 ports on Cisco 2500 series routers do just that. The SP232 receiver in the XSB-2000 won't receive such signals correctly.
An EIA-530 DTE will use a differential receiver like 26LS32 to receive DSR, CD and CTS. Although it would have been trivial to ground the B wire pin for each of those signals on the DB25F connector, the XSB-2000 doesn't do that, hence the DTE won't receive these signals correctly either.

Thus one cannot use a single cable to connect the XSB-2000 to a router; instead one must use two cables: a V.35 cable from the router and the pigtail that comes with the XSB-2000. The V.35 interface exists only as a mated pair of connectors between the two cables laying on the floor between the two devices.

Of course another solution would be to make a custom cable that presents itself as a V.35 cable to the Cisco/whatever end, but has a DB25M instead of the standard V.35 connector on the other end.