The bitpump is the invariant among the different flavors of SDSL/2B1Q, and it's the part that defines the nature of the SDSL/2B1Q signal at the electrical level.
The bitpump is a mixed signal IC developed by Brooktree, then branded Rockwell, then Conexant, now Mindspeed. It belongs to a family of chips originally designed for HDSL, and at the bitpump level the SDSL line is not much different from one of the loops of an HDSL system.
HDSL is a rather obscure telco technology that may not be familiar to
those coming from a mostly Internet background.
It's a transport technology that allows T1 lines to be provisioned without
repeaters every 6000 feet and works by transmitting the DS1 frame payload in a
physically different way.
An HDSL system consists of two metallic loops like a traditional T1 system.
However, whereas in a traditional T1 system each loop carries data in only one
direction, in an HDSL system each loop carries one half of the DS1 payload in
both directions. HDSL thus lowers the
Nyquist frequency
of the signal at the expense of more complex electronics to handle data being
transmitted in both directions on the same pair.
HDSL is little known among those who work mostly at the Internet level because
it's normally completely transparent to the user —
HDSL terminals on both sides provide a standard DS1 interface,
and the customer side HDSL terminal unit is part of the active demark
.
Other versions of HDSL exist in Europe where 2 or 3 loops are used to carry
an E1 instead of a T1.
Unlike SDSL, HDSL is a real standard. It is defined by a formal specification, and compatibility and compliance are determined by adherence to this specification rather than implementation details. An engineer desiring to build an HDSL terminal unit is free to use any vendor's chip or make a discrete implementation.
The Brooktree chips started out as implementations of the HDSL standard. However, since the chipset was divided into a bitpump that handles only one loop of an HDSL system and a separate channel unit IC that performs higher level functions and since the same chips were intended to support both American and European HDSL standards, the chips were designed with a lot of flexibility. In addition to implementing HDSL standards one could use the Brooktree chip to implement a custom HDSL-like system that borrows HDSL's transmission technology but does not strictly follow its standards. SDSL is a case of the latter.
The fundamental technology that HDSL and SDSL are based on is the 2B1Q line
code. 2B1Q stands for 2 binary, 1 quaternary
, which refers to the use of
a transmission line code such that each electrical signal element (symbol)
carries two bits and is thus quaternary. This line code was originally designed
for the North American ISDN BRI U interface, but HDSL has adapted it for use
with much higher data rates.
The electrical signal on an SDSL line, like on each loop in an HDSL system, carries a stream of quaternary symbols or quats in each direction. The four possible symbols on the line are referred to in literature as -3, -1, +1 and +3. In actual implementations like the bitpump we are discussing each symbol is regarded as consisting of a sign bit and a magnitude bit. It is important to realise that the line carries a stream of quats, not bits! The quat boundaries are preserved and the conversion between the quat stream and a bit stream on each end may put either the sign or the magnitude bit first. This consideration is important in handling different SDSL flavors. Read more about it here.
The digital side of the bitpump chip puts out a quat clock and a bit clock, takes in a stream of quats to transmit, and puts out the stream of quats received from the other end. What one does with these quat streams is the subject of the SDSL flavor.
Brooktree's original HDSL transceiver chip was Bt8952. It's so ancient that there is virtually no information about it. It seems that the original Bt8952 chip was purely digital and required an external analog front end. It also appears that Bt8952 was for HDSL only, operated at the HDSL data rate of 784 kbps and probably didn't have any of the SDSL capabilities of the later bitpump chips.
Brooktree had basically created SDSL by coming out with the Bt8960 bitpump
chip.
It was a chip specifically intended not for HDSL, but for implementing
HDSL-like systems and was marketed as a 2B1Q transceiver based on
Brooktree's HDSL technology
rather than an HDSL transceiver
.
The gotcha is that Bt8960 was specified to operate at data rates from 160 to 416
kbps, not the HDSL data rate of 784 kbps.
Bt8960 had introduced features specifically intended to make the bitpump
usable as a self-contained serial data transmission system without an HDSL
channel unit and outside of a complete HDSL system:
blessingto operate unframed as in Flavor B;
The above set of features is basically what defines SDSL/2B1Q and sets it apart from HDSL. The next bitpump chip Bt8970 had retained all of these features and was capable of operating at data rates from 160 to 1552 kbps, hence it could support both HDSL and SDSL. Bt8970 powered the first wave of real-life SDSL deployment.
Conexant's last 2B1Q bitpump chip RS8973 has raised the maximum data rate to 2320 kbps and incorporates a built-in frequency synthesiser that can generate the internal clocks for different data rates using one fixed external frequency source (crystal). The latter feature would be immediately appreciated by anyone designing a multirate SDSL terminal unit. HDSL equipment was traditionally designed for some fixed data rate, and early multirate SDSL products based on Bt8970 had to implement external frequency synthesisers. RS8973 eliminates this external circuitry requirement. However, please read about bitpump performance at different data rates.
We have gathered the datasheets for the bitpump chips on our FTP site:
All of these are mixed signal ICs; the analog side interfaces directly to the metallic loop with only passive components in addition.
As explained above,
SDSL was created by taking the HDSL bitpump from Brooktree/Rockwell/Conexant
and using it in a different application serving a different end purpose
(closed source Internet service instead of DS1 transport).
Unlike HDSL (and T1, ADSL, ISDN and most other communication technologies) it
has no specification defining the SDSL signal format in neutral terms, and now
a specification for the SDSL signal format can only be written as a
back-specification, a definition like the signal of the kind produced by a
Bt8970 or RS8973 IC when programmed in such and such way...
This kind of back-specification is used by companies that make new chips other
than RS8973 which support legacy SDSL in addition to some newer technology like
G.shdsl.
The bitpump chip has one hardware feature which is specifically intended
for applications which do not use an HDSL framer and use the bitpump
raw
. It is the internal bit scrambler and startup sequence source.
With many line codes including 2B1Q good transmission performance requires that the transmitted bit stream resemble a pseudorandom signal, and thus the user's payload data stream is normally scrambled before transmission. The ISDN and HDSL standards which use the 2B1Q line code define a 23-bit LFSR scrambler and a corresponding self-synchronising descrambler. The same scrambler has been kept in G.shdsl.
However, when the low-level symbol stream is framed like it is in ISDN,
HDSL and SHDSL, reliable frame lock at the receiver requires that a periodic
frame sync word be inserted outside the scrambler. This sync word is
not scrambled, it is a fixed sequence of symbols transmitted on the
line as prescribed in the relevant standard, and the scrambler hops over
the sync word retaining its state.
It should be obvious that if a standard like HDSL is implemented with separate low-level transceiver and framer chips, the scrambler has to be located in the framer. And indeed in Brooktree's HDSL solution the 8953 HDSL framer implements the standard scrambler while the bitpump performs no scrambling when operating in the standard HDSL mode.
But what if you are using just the bitpump as in SDSL Flavor B? Just for this purpose there is another instance of the standard HDSL scrambler implemented inside the bitpump. The bitpump's internal scrambler is identical to the standard HDSL one except that it scrambles all bits and has no ability skip over any frame sync word. This scrambler cannot be used in standard HDSL applications because the latter behavior breaks the standard, but it's perfect for not-quite-HDSL applications like SDSL which don't use an HDSL framer.
The internal scrambler is the only feature of the bitpump that must operate on a bit stream; the rest of the transceiver works only with quats. Read here about the interaction between the bitpump's internal scrambler and the quat orientation setting.
Also closely related to the internal scrambler is the internal startup sequence source. In the standard HDSL configuration when the bitpump is connected to an HDSL framer, the latter is responsible not only for producing the Tx quat stream in normal operation, but also for producing the quat streams of the S0 and S1 signals defined in the HDSL startup sequence. In the HDSL standards S1 differs from normal operation in that all payload data bits are replaced with ones prior to scrambling and S0 differs from S1 in that all symbols are forced to +3 or -3, no +1 or -1 transmitted. S0 and S1 are thus called 2-level scrambled ones and 4-level scrambled ones, respectively.
In the standard HDSL configuration both S0 and S1 are generated by the framer and contain the frame sync word periodically interrupting the scrambled ones, but the latter is a rather non-essential feature for a receiver to lock and train on the signal. And once again Brooktree had made a provision for producing the needed startup sequence in the absence of an HDSL framer. The bitpump can use either an external startup sequence source or its internal one. The latter works by operating the abovementioned internal scrambler and feeding it a source of continuous ones (internally, regardless of what is on the external digital interface pins). S0 and S1 signals are thus produced which differ from those prescribed by the HDSL standards only in the absense of the HDSL framing overhead, which is acceptable for most applications.
The functionality of the bitpump chip appears simple at first. One side connects to the metallic pair through some passive components, on the other side you have clocked Rx and Tx quat streams. Plus a microprocessor control port with some control and status registers. Sounds simple, eh?
Not so fast. The difficulty comes with software. Many chip vendors will provide sample source code that demonstrates how to program and use their chip. Very often this code is useless crap and one is better off writing all necessary code himself working from the register descriptions in the datasheet. Not so with the bitpump. The magic software package advertised on the first page of the chip datasheet is really necessary, because some necessary and non-trivial parts of the bitpump functionality are implemented in this control software rather than in the chip itself. The DSP block inside the chip also needs to be loaded with microcode, and the microcode image, albeit very short, is buried in the BT software package (in the form of a C array statically initialised with hex data).
We have more information about the bitpump control software on this page.