Mindspeed has created a chip family that attempts to support every feature of every flavor of symmetric DSL for every possible application in a single hardware configuration. This includes both old symmetric DSL flavors based on the 2B1Q line code as well as new ones like G.shdsl and HDSL2 based on TC-PAM. This over-generality has led me to refer to the product as a kitchen sink.

The chip family consists of 4 similar but slightly different digital ICs and a common analog front end (AFE). The digital ICs are M28945, M28946, M28947 and M28950; the AFE is M28927. The digital IC does the vast majority of the work, the AFE is just that. M28945 is the most vanilla version of the M289xx digital IC. I'll use the term M289xx to refer generically to any of the 4 digital ICs in the family, working together with the M28927 AFE.

The kitchen sink's extreme over-generality makes it difficult to give an introductory overview of it. Read Mindspeed's documentation and see for yourself how quickly your head will start to spin out of control. Briefly, on one side the M289xx chip connects (through the AFE) to a single-pair symmetric DSL line, and on the other side a bunch of interfaces are made available that make no sense together because the chip attempts to support so many different applications that have nothing to do with each other.

Two of M289xx's digital interfaces, however, are of some interest to someone like us who is interested in SDSL CPE. These are the PCM interface, which in our application becomes a simple sync serial interface, and the ATM UTOPIA interface. By connecting these two interfaces to a router's network processor one is supposed to effortlessly obtain an SDSL terminal unit that supports all flavors of G.shdsl, SDSL and IDSL, with both ATM and bit stream service models — if everything works.

Sounds like magic, doesn't it? Magic turns out to be a very apt comparison, because just like the tricks of a stage magician, the inner workings of the M289xx are completely closed. The chip contains an embedded 8051 core which executes closed source firmware, and all internal hardware that does all the work is accessible only to this 8051 core, not to an external host. In other words, closed source firmware controls mysterious undocumented hardware. The chip's only external control interface is a dual-port RAM mailbox through which an external microprocessor loads Mindspeed's firmware image and then sends commands to it.

Mindspeed provides several different firmware images with different feature sets, which seem to be mostly arbitrary and artificial. Ignoring weird special applications like OPTIS and voice pairgain, Mindspeed's firmware images can be divided into 3 mutually exclusive sets of G.shdsl, SDSL and IDSL.

M289xx's support for G.shdsl appears to be pretty good, which is the major reason why we are looking at this kitchen sink in the first place; for SDSL/2B1Q one would be much better off with an open source solution based on the RS8973 bitpump. The chip implements all aspects of the G.shdsl standard, including the physical layer and the framer, and the payload can be either accessed as a bit stream or fed into a built-in ATM TC-PHY and accessed externally as UTOPIA. However, M289xx's support for SDSL/2B1Q, particularly SDSL flavors, has some warts, and this fact is of concern for those trying to support both G.shdsl and legacy SDSL with one hardware platform.

If M289xx were to truly live up to its promise of supporting both G.shdsl and legacy SDSL with a single hardware configuration, it would have to provide internal support for all SDSL flavors to the point of presenting a router-style HDLC bit stream on the PCM interface or ATM cells on the UTOPIA interface according to the SDSL flavor's service model. That's what it does for G.shdsl, and the whole point is for external surrounding hardware not to change, right? But in reality it comes nowhere near this goal.

The main problem seems to be with M289xx's framer, or rather the artificial limitations imposed on it by the closed source design. Mindspeed's 2B1Q firmware images support no framing, and thus can directly support only the basic unframed flavors A and B. But if the SDSL flavor includes a framer like HDSL or AOC, M289xx only serves as an oversized bitpump — the rest of the work must be done by external circuitry, nullifying the idea of a single hardware configuration independent of the flavor. To add insult to injury, if framing has to be done outside the M289xx chip, the chip's built-in ATM TC-PHY cannot be used either, as it's connected to the disabled internal framer, not the user's external one built to replace it. Thus if the SDSL flavor to be supported uses both framing and ATM (such as Flavor HA or Flavor AOC), the TC-PHY has to be duplicated in external circuitry as well!

The lack of support for HDSL framing is particularly inexplicable because M289xx fully supports G.shdsl framing and the frame formats of G.shdsl and classic HDSL are almost identical. According to Mindspeed's documentation HDSL framing is supported only by one special voice pairgain firmware image which works only on M28950. This smells like an artificially imposed limitation to me, i.e., a rat.

RADSL (ATM over CAP) is another story. There are passing references to it in Mindspeed's documentation, but no clear statement as to its support. When I managed once to speak to a Mindspeed support engineer, he had told me that they planned to support RADSL, but never implemented it because all their other customers didn't care about support for SDSL flavors and only wanted the oversized bitpump mode. Huh?

It is very clear that M289xx's closed nature is what hinders its capabilities: the same Mindspeed support engineer had told me that the framer hardware inside the chip can support just about anything, someone just has to implement the firmware support. Had the chip's internals been open, the necessary firmware would have been implemented eventually in the traditional bazaar model of open source software development.

On the one hand given its repulsive closed nature, I feel like not ever having anything to do with the M289xx chipset, but on the other hand there are a few reasons why we are still looking at it in our Open SDSL Connectivity Project:

See our LNX8945 page for more musings on this topic.

All materials that the IFCTF possesses for this chip are on our FTP site. We have M28945 firmware images and a bunch of PDF documents.