This paradox goes back to the time of my arguments with Mindspeed about which chip I should use in my SDSL designs: the old RS8973 or the new M28945.
The old bitpump is very open and hackable, but only supports SDSL/2B1Q, can never support SHDSL, and while it can probably be made to support IDSL with an external home-grown FPGA framer and completely rewritten startup code, it would be a major pain. The new chipset provides turnkey support for G.shdsl, SDSL/2B1Q and IDSL, but at the price of being a closed black box.
Are there any practical reasons (aside from sentimental concerns) why
we can't use a closed black box
chipset like M289xx?
As it turns out, the answer is yes, but only for SDSL/2B1Q.
For SHDSL and IDSL we can probably do fine with a black box chip, but the
problem with SDSL/2B1Q is that there is a zoo of wildly different
flavors.
Support for all those flavors can be achieved in two ways:
We can use the old, primitive but completely open and hackable RS8973 bitpump, which would allow us to do all the work ourselves.
Based on the available evidence, the M28945 kitchen sink can support that whole zoo of flavors as well, but here is the gotcha: because the insides are completely closed, this functionality can't be developed on a self-support basis in the bazaar model like it was possible with the RS8973. Instead this functionality can only be developed with extensive personal hand-holding support from Mindspeed, the keepers of the secret sauce. Of course the chances of an open source group like ours getting that kind of support are less than a snowball's chance on Venus.
The flavors of SDSL/2B1Q which one can support with an M289xx chip without having a cozy relationship with Mindspeed appear to be limited to the basic Flavor A and Flavor B without any framing or funky pre-activation sequence. The more complex flavors (which in fact seem to be dominant in the real world) can only be realistically supported with the RS8973 bitpump which we can hack ourselves without needing some gods to descend from the heavens for us and give us support.
We thus find ourselves in the situation where we need RS8973 for good SDSL/2B1Q support, but need M28945 for SHDSL and IDSL, and only two very basic (and rarely used in the real world) flavors of SDSL are supported by both.
But the difference between the two chips doesn't end here: they are vastly different in how one would actually use each chip in question.
The RS8973 bitpump requires an external microprocessor to babysit it continuously at a fairly low level, especially during the startup process (when the SDSL connection is being established). This arrangement works well for DSU-type products like our OSDCU, but presents a problem for those who prefer a low cost, fully integrated soapbox-sized router solution of the kind everyone is used to these days.
In order to have low cost, a DSL router product would need to be implemented on a single board, use a single microprocessor and have a simple hardware design. Attempting such a design with an RS8973 bitpump would involve connecting it directly to the router's main (and only) processor, and indeed some existing SDSL routers like EN 5851 do just that.
But perhaps the EN 5851's simple hardware design is part of the reason why it's such a horrible router in terms of software. It would not work well with a high-quality, open source modular network operating system like BSD or Linux. Having the router's main processor babysit the SDSL bitpump chip continuously at the low level it requires would be very burdensome to such an OS, and is totally counter to the principles on which these fine operating systems are based. (Obviously EN have managed it with their highly ad hoc RTOS, but then their implementation of the standard Internet protocols is a piece of shit.)
The only way in which an SDSL router can use the RS8973 bitpump and still be a high quality router would be for the SDSL subsystem with the 8973 to be a separate module. It would need to be either an external DSU or perhaps a plug-in network interface card for a high-end modular router; in the latter case the SDSL card would need to have its own microprocessor controlling the bitpump, independent of the router's main processor running the network stack. This solution is perfectly fine technically, but the problem is COST.
Also supporting the common SDSL/2B1Q flavors which use framing or ATM requires a framer external to the bitpump chip, which is usually home-grown and implemented in an FPGA. That framer also takes processor cycles to manage and oversee! If the SDSL subsystem is implemented as a self-contained module, the same microprocessor can normally manage both the bitpump and the framer and the resulting hardware design is still simple and neat, but again it needs to be a self-contained system. Burdening framer management on top of bitpump management on the router's main processor gives no end of trouble.
Now contrast this situation with that which exists for the M289xx chipset. That chipset's host control port takes commands at a much higher level, and its PCM (sync serial) and UTOPIA interfaces can be connected directly to a router processor like MPC8xx. The latter can then run BSD or Linux, do its standard Layer 2 and Layer 3 functions independent of the physical layer, and the supervisory control of the M289xx can be provided by a user mode daemon — the control commands are sufficiently high-level and the command traffic across the control interface sufficiently small. In other words, this chipset is fit perfectly for direct integration into a router. (There are also other hardware engineering factors like M289xx wanting exactly the same power supply voltages as MPC8xx processors, how convenient.)
And thus we come to the paradox of modularity and openness. If you are in the market for a good SDSL router, we have two options. We can either make you a very nice one that's very modular and totally open source, but it'll be expensive because of the overhead costs of modularity: multiple boards to design, build and bring up, multiple processor subsystems, main CPU more powerful and more expensive than would be necessary in a non-modular product, a bigger power supply, extra buffers and voltage level shifters, mechanical design issues, etc. Or we can make a one-piece, low cost, soapbox-sized router that has (say) an MPC850SR and an M28945 slapped on the same board. It'll be quite inexpensive, but it'll suffer from the limitations caused by the closed nature of the M289xx chipset, namely, some major and important flavors of SDSL/2B1Q won't be supported not because the chip hardware is not capable of supporting them, but because it's a closed black box which we can't hack.
The technical, political and economic realities combine to not allow us to have it both ways: it can be either modular, flexible and capable, or low cost.