Is Your Interconnect Strategy Scalable?

“Strategy” is a word sometimes used loosely to lend an aura of visionary thinking, but in this context, it has a very concrete meaning. Without a strategy, you may be stuck with decisions you made on a first-generation design when implementing follow-on designs. Or face major rework to correct for issues you hadn’t foreseen. Making optimum architecture decisions for the series at the outset is key. Will it support replicating a major subsystem allowing more channels in premium versions, for more sensors or more video streams? Can the memory subsystem scale to support increased demand? Careful planning and modeling, checking target bandwidths and latencies is a necessary starting point. However architectural feasibility alone may not be sufficient to ensure scalability for one critical component – the interconnect between the function blocks in the design.

Strategies and risks for interconnect

The startup strategy. Starting with no design infrastructure, part of your funding must be committed to design tools and essential IP. Some CPU cores come with low-cost access to an interconnect generator based on a crossbar technology. Or perhaps you decide to build your own generator – how hard can that be?

This strategy may work well on the first-generation design. Crossbar-based interconnect is well-established for entry-level designs but exhibits a glaring scalability weakness as systems become more complex. Area consumed by interconnect grows rapidly as the number of initiators and targets grows, creating more challenges for bandwidth, latencies and layout congestion. Problems become acute in follow-on designs as target and initiator counts increase to merge multiple market demands into a common product. Designs must also be as robust as possible to IP changes. A home-grown bus fabric may have worked well with the IP portfolio for the launch design, but what if one IP fails to measure up in the next product? A workaround may be possible but would kill your margins. A better IP is available but only with an interface you don’t yet support. Designing and fully verifying a new protocol will take more time than you have in the critical path to product release.

If you are going to use a crossbar interconnect in your first-pass design, set clear expectations that this will be a proof-of-concept build. It is already widely accepted that scalable interconnect must be based on NoC technology; to transition to a scalable market product, it is almost certain you will have to redesign around that technology. Commercial NoC IP generators already support the full range of AMBA and other protocol standards, limiting risk if needing to change IP. Then again, you could just start with a NoC, avoiding later risks.

The “What we have works and change adds risk” strategy.

Risk in change is an understandable concern but must be balanced against other risks. If it was tough to close timing on your last design and your next design will be more complex, you may be able to battle through and make it work, but at what cost? Pride in surviving the challenge will dissipate quickly if PPA is compromised.

This is not a hypothetical concern. One large company planned to reduce total system cost by designing out a chip they were buying externally. They already had all the tooling and expertise needed to make this happen. The plan seemed like such a no-brainer that they built this expectation into forward projections to analysts – improved margins at more competitive pricing. But they couldn’t close timing at target PPA on their in-house replacement. To continue to deliver the larger system, they were forced to extend their contract with the existing external supplier. Missing projections and getting a black eye. For the next generation, they switched to a commercial NoC solution and were able to complete the design-out successfully.

The “Our interconnect is differentiating” strategy.

There are a few system architectures for which interconnect architecture must be quite special, commonly for mesh networks or more exotic topologies like a torus. Applications demanding such topologies are typically high-premium multi-core server systems, GPUs and AI training systems. Even here, commercial NoC generators have caught up, to the point that market-leading AI systems companies now routinely use these NoCs. Suggesting that fundamentally, differentiation even in these high-end designs is not in the NoC. Just as for other IP, the trend is to commercial solutions for all the usual reasons: Maybe initially comparable to the in-house option but proven across an industry-wide range of SoCs, continually enhanced to remain competitive, with lower total cost of ownership, always-on support and resilient to expert staff turnover.

In a challenging economic climate, it has become even more important for us to pick our strategic battles carefully. People who work on NoC design are often among the best designers in the company. Where is the best place to use those designers? In further securing your lead in truly differentiating features, or in continuing to support NoC technology you can buy off-the-shelf?

If these arguments pique your interest, take a look at Arteris’ FlexNoC and Ncore Cache Coherent interconnect IPs. They boast over 3 billion Arteris-based SoCs shipped to date across a wide range of applications.