The SDSL/2B1Q bitpump chip requires fairly extensive babysitting by an external microprocessor in order to perform its intended function of bidirectional 2B1Q transmission on a metallic pair. This babysitting is performed by a fairly complex software package developed by the makers of the chip.
Using this software package is absolutely necessary. Its documentation says:
The ZipWire software implements all necessary bit pump control and monitoring operations, including activation process, performance monitoring, and test modes. This software package is an integral part of the bit pump and must be used without any significant changes to guarantee correct operation and optimal bit pump performance.
Although I don't see why we should abstain from hacking the code to make some further improvements and functionality extensions now that we have the source (see below), trying to reimplement the necessary functionality from the datasheet alone without the original code would have been hopeless.
It took us a battle to obtain the BT software package in source form. The enemy was Mindspeed, a shithead company in Newport Beach, California, the current owner of the bitpump chip. The complete details of Mindspeed's reprehensible actions and practices and of our battle and victory are described on this page.
The Will of the People has prevailed and the IFCTF has liberated the BT source code. Mindspeed's original version (8051 processor, DOS development environment) can be found here on our FTP site, but also read below about our port for the 68302 processor and UNIX development environment.
From reading the PDFs we've grabbed from Mindspeed's website,
it appears that the code has evolved as follows: first there was a version
for the Bt8960 chip (the names of compiled image files had 8960
in
them), then a version for Bt8970 (8970
in the image file names), but
when RS8973 came around, the software package had acquired a new name
ZipWire
and was made to support all bitpump chips from 8960 through
8973 inclusive.
It appears that there was no version that supported only RS8973 and no others.
The ZipWire version is the one we have.
Specifically, the version we have is
which stands
for BP44CU62bitpump version 4.4, channel unit version 6.2.
It seems to be the last version released; the newest file date in the ZIP
is 2001.
The ZipWire package contains more than just the bitpump control code. It also contains code for controlling other Brooktree/Rockwell/Conexant components that would be used in a complete HDSL terminal unit implementation. These are the HDSL channel unit and the chip that provides the T1/E1 side interface. However, the code is structured in a neat way that allows it to support both HDSL systems with all those components as well as applications like SDSL that use only the bitpump from BT.
The bitpump portion of the BT software is essentially a library with a few
externally callable functions that tie it into whatever software architecture
is desired at the higher level.
As explained in the
ZipWire
Software User Guide,
after calling a few initialisation functions on power-up, one merely has to
call _BtMain() repeatedly; all work is done by that function and
other functions that it calls, and is controlled by internally maintained
state machines.
One tells it what to do by calling _BitpumpControl() or the
_BtControl() wrapper function, and finds out what it's doing by
calling _BitpumpStatus() or _BtStatus().
Besides this bitpump library, the BT software package consists of similar
library-like code
for other components (HDSL channel unit and T1/E1 framer) and a sample
implementation of the top level code, including the main()
function.
When the entire software package is compiled without modification
(for the 80C32 microcontroller used on their evaluation board)
and linked together,
it produces a functional self-sufficient firmware image that can control a
complete HDSL terminal unit.
The same image can also control a lone bitpump without a channel unit,
even if
support for the latter was compiled in — the presence or absence of each
chip is determined at run time.
It also reads some bits from the microcontroller's GPIO port (DIP switches on
the evaluation board) that tell it whether to bring the system up autonomously
with some standard HDSL settings or to wait for control commands given over the
microcontroller's serial port (which are short binary packets that directly
correspond to _BtControl() and _BtStatus() API
calls).
This functional flexibility within a single compiled firmware image probably
provided the justification for
Mindspeed miscreants
to withhold the source code and give unprivileged customers only compiled
images for the microcontroller.
We have ported the ZipWire bitpump control library to the MC68302
integrated multiprotocol processor (IMP) family (M68000 core) and to our
UNIX-based development environment for it, which consists of GCC and Binutils
configured to cross-compile for the m68k-elf embedded target.
Its new name in accord with UNIX library naming conventions is
libzw.
This code powered our Hack-o-Rocket project;
it was originally intended for the OSDCU, but we then
developed SDCORE as its successor.
The port went very smoothly and has been exercised quite extensively —
apart from being very Spartan at the higher levels, our Hack-o-Rocket using
this code was rock solid.
The library is linked into the
SDEBUG utility
and into the SDSL versions of the
HoR IP router.
Both HTU-C and HTU-R modes work fine and
all test modes also work including ERLE.
When running on the Hack-o-Rocket hardware platform, we have to use the ICD2053 clock synthesiser to produce whatever symbol rates we need with the Bt8970 bitpump. We've originally copied CM's ICD2053 programming logic (for CM SDSL data rates only obviously), but we have since done the math and added the code to generate all known SDSL data rates except 2320 kbps.
libzw lives in the
Hack-o-Rocket source tree.
Our successor to libzw is
SDCORE on the OSDCU.
The major addition is pre-activation support,
developed by us.