When the 2B1Q bitpump chip is used in a standards-based application like HDSL or perhaps ISDN, it simply transmits and receives quats from and to an external framer chip. It is then up to that framer chip to decide what to do with them, and the framer handles them in accord with whichever standard it implements.
However, the bitpump chip was also designed to support raw
usage
without a framer, what we call SDSL Flavor B.
When used in this mode, the bitpump implements internally two functions which
are normally the responsibility of the framer: scrambling and conversion of
the quat stream to a bit stream for direct user consumption.
Conversion of the quat stream to a bit stream requires one to make a
decision as to which bit should go first: sign or magnitude.
The bitpump hardware supports both ways, thereby putting the onus on
the inventor of the SDSL flavor.
As far as the existing SDSL flavors go, there are most certainly flavors
out there which do it both ways, but let's start with a more basic
philosophical question: which way is more natural
and which is the
weird one
?
At least to the hacker/philosopher who is writing these web pages putting the sign bit first seems more natural. Sign bit first is also the order used by the ISDN and HDSL standards when stuffing payload bits into 2B1Q quats, so their philosophers apparently have felt the same way.
The HDSL standards have obviously had a very strong influence on the development of Brooktree's chipset and the SDSL pseudostandard that has resulted from it, and if the word of the HDSL standards is that the sign bit goes first, that should have settled the question once and for all, shouldn't it have? But unfortunately someone has muddied the waters.
The bitpump chip supports 4 different formats for presenting the quat stream on the digital interface:
The mode to be used is selected by two bits in one of the registers. Like for all other register bit settings, the C source code for the bitpump control software package assigns a symbolic constant to each possible setting.
The problem is that for some reason whoever wrote that code has called the
serial, magnitude bit first mode _SERIAL and the serial, sign bit
first mode _SERIAL_SWAP.
The code even sets _SERIAL as the default until overridden
by a _BtControl() API call.
(Actually it's even more confusing than that: in the complete and unmodified
code package as supplied by Brooktree and its successors, the bitpump library
initially sets _SERIAL as the default, but then the supplied
reference application code always switches to _SERIAL_SWAP,
making it a kind of higher level default
.)
We don't know who has made this decision, when or why.
Perhaps we'll never know.
But the result is that many users of the chip must have gotten a mistaken
impression that putting the magnitude bit first is the normal
or
natural
way.
Others knew better from the ISDN/HDSL standards or from their own gut
feeling, and thus both ways are now about equally likely to be found on
an SDSL line in the field.
As we have just discovered experimentally, Copper Mountain SDSL puts the magnitude bit first.
If the bitpump is to serve as a complete and self-sufficient transceiver for user data without a framer, it needs to do one more thing besides converting the quat stream to a bit stream. The bit stream needs to be scrambled, and as we've described, the bitpump implements an internal LFSR scrambler similar to the one in the HDSL standards.
Given that the scrambler has to process one bit at a time and the order in which the bits are processed very much matters, the question which an astute reader ought to ask at this point is how does this scrambler interact with the user's choice of quat orientation. Are the bits scrambled in the same order in which they are presented to the user or not? And what happens if one enables the internal scrambler when the channel unit interface is configured for parallel mode?
The official chip documentation is silent on this topic, but we have performed some experiments and determined that the internal scrambler and descrambler always process the sign bit first, then the magnitude bit. This is so regardless of which mode is selected for the channel unit interface: parallel master, parallel slave, serial sign bit first or serial magnitude bit first.
Thus if you use the sign bit first quat orientation, you see the bits in the same order as the scrambler does. If you use the magnitude bit first orientation, your bit stream is first swapped around, then scrambled, then packed into quats for transmission; the process is reversed on the receiving end. So much for the assertion that sign bit first is swapped.