Although the final PCB layout may have been done by Netopia, the basic design of the module is clearly CM's and bears a striking resemblance to CM's own CopperRocket hardware design. The bitpump is an 8970 with an ICD2053 PLL clock synthesiser, matching CM's CopperRocket design down to the use of a dedicated small 7805 regulator for the ICD2053, the copper loop interface and surge protection design is identical to the CopperRocket, the same MC68LC302 microprocessor is used, and the clock source for both the CPU and the bitpump is exactly the same 4.096 MHz can oscillator as on the CopperRocket. The main visible difference is that the LC302 runs in the 8-bit data bus mode and a lower speed grade part is used, so the firmware must be setting the internal clock multiplier to a lower speed.
The firmware resides in a single 29F040 which is fortunately socketed just like on CM's own hardware, and is clearly CM's. The firmware images on the CopperRocket and on the Netopia wanlet look like two versions compiled from the same source with different options. The Netopia CM wanlet firmware uses exactly the same dual image architecture as that on the CopperRocket, and firmware updates can be done either from the UMB3 side or from the DSLAM side (I've done it myself both ways).
It's interesting to ponder how this beastie works. It obviously doesn't have an Ethernet port and doesn't do any routing or bridging like the CopperRocket, those functions are relegated to the Netopia motherboard. It seems that the interface between the motherboard and the wanlets is some kind of sync serial; does this mean that the SDSL module is essentially a DSU? Not so fast — it definitely looks like the module implements CMCP, and that's an in-band protocol.
How does it work then? Does it maintain a separate sync serial interface to the motherboard as a software data link and forward packets back and forth between the internal interface and the physical one? Or does it feed the Rx bit stream to both the motherboard and the local LC302, process CMCP packets on the latter, and then implement some kind of mixer on the Tx bit stream to inject outgoing CMCP packets into the bit stream which otherwise comes unchanged from the motherboard? There are two GAL16V8 PLDs on the board, perhaps they have something to do with this.
The CM SDSL module is found in the R7100-C SDSL router and the D7100-C
pseudo-DSU
.
(The previous questions of how it handles the bit stream obviously become
even more interesting for the latter.)
There also were R7171 and D7171 models, each featuring two of these wanlets
to support CM IMUX —
see this page.
There was also an M7100 SDSL modem
as Netopia had called it, but
that one in fact has nothing to do with Netopia at all — it's actually
CM's CopperRocket painted differently!
It certainly looks like CM had a very warm relationship with Netopia and relegated a big chunk of their CPE business to them.
This module supports only CM SDSL and has no possibility
of working with any non-CM flavors.
In the normal CPE configuration it listens for the
CM pulse train to select the data rate
like standard CM CPE — heck, why say like
, it is
standard CM CPE.
The module also supports HTU-C mode operation (DSLAM emulation) in a fully legitimate and documented manner — the option appears in Netopia's configuration menus. When the HTU-C mode is selected, an additional selection appears for the data rate.
The selection of normal CPE versus CO mode operation and the selection of the data rate in the CO mode are the only two configurable options presented in Netopia's menus for this WAN module.