CommSemi Nightmares — 802.3 L3+ chips are just “a backplane device”

( this is kinda long and muddled … c’est la vie .. it is sunny out .. gotta go )

I’ve been having an e-mail discussion with a friend, from Ottawa, on what I’d call my CommSemi nightmare. That nightmare is — telecom silicon/hardware devices are becoming more “horizontal” such that a system vendor can almost capture all of their Intellectual Property (IP) in the software layers above the silicon.

The Punchline

On a chip guy humour point we got to the following punchline.
Today’s backplane device is an high-end 802.3 L3+ chipset. (Talk about putting something fairly complex in its place ❗ )

Here is the full story

The good news is that system vendors will use more and more “standard” devices as “standard” device vendors ( like CommSemi’s) compete less and less with them on “hardware” features. The bad news is that these “standard” devices will deliver very few features that are in the system vendors datasheet and of value to service providers. These “system” features are now predominantly in firmware and above. The domain of the CommSemi is tending to firmware because competing on hardware positions them to compete with “device” vendors like Intel.

Here is my version of a generic telecom hardware system today with Pros/Cons

  • Advanced 802.3 Switch at the core — key is that it is developed for Enterprise & “Taiwan” to get volumes up. The system guy “hijacks” all the pre/post-pend tags for his own ends. ( think BRCM, MRVL, Swithcore, etc )
  • optional standard CPU chips for slow path feature cards — key is that target market for these devices is not telecom .. it’s enterprise/consumer. ( think BRCM, CAVM, MSDP, INTC, etc )
  • optional Network Processors (NPs) with 802.3 PHYs built in — for advanced fast-path feature cards ( Many telecom boxes will have this on every card) ( think AMCC, Ez-Chip, Intel, etc )
  • optional multiport – 802.3 PHYs — 8+ port chips. (think Ample, PMCS, etc)
    • telecom specific PHYs are now secondary and don’t need to be elegant. reverse of before where 802.3 was “bolted on” and telecom specific was elegant. ( ie UTOPIA/SPI)


  • This chipset is applicable to a huge portion of telecom market today because speeds have not really changed in the past 5 years. (silicon has had a chance to catch up)
    • This is a fantastic platform to write software on.
    • looking at Big Band (BBND) and others … software dev is around $200M for IPTV router
    • ( they spent/were_financed around $300M prior to going public… very close to **** estimates when they started)
  • This chipset does not compete with its customer.
    • This chipset allows the “box” vendor to own all his “differentiation” if they want to.
  • The core of this solution is not developed for “telecom”
    • Result — it is dramatically “cheaper” for system vendor than telecom specific devices because of “margin” issues.
    • margin issues are 2-fold — wall st expectations of a particular company selling consumer/enterprise products and lower volumes in telecom specific markets.
  • The chips developed specifically for telecom have not done well in marketplace yet 😦
    • NP and multi-port 802.3 PHY.

My friends response (paraphrased)

This is very similar to the mid-90’s prior to the bandwidth explosion. The system’s then were Physical Layer devices ( PHYs), an i960, a backplane device and an ASIC that captured the fast path. The ASIC started off being a DMA engine that coughed up headers to the CPU. As the teams knowledge grew they put more fast path smarts into the device.


4 thoughts on “CommSemi Nightmares — 802.3 L3+ chips are just “a backplane device””

  1. Excellent post… you describe the innards of the majority of equipment built 3-5 years from now.

    The NPU guys still think NPU’s get deployed everywhere… reality is they get put off to the side for one handed functionality.

    High end telecom equipment will have one on each card, but how many units is that when compared with the total number of Chassis?

    Yet another example of the triumph of Ethernet.

Comments are closed.