NoC-Based SoC Design. A Sondrel Perspective

Why are NoCs important in modern SoCs and what are best design practices for using NoC? As always, a great place to start is the perspective of an SoC design organization which depends on pumping out high performance designs. Sondrel is a turnkey ASIC service provider, covering the spectrum from system design to silicon supply. Clearly doing well since they have created designs now in production in hundreds of products in mobile, security, AR/VR and other applications. Drawing on this experience they recently released a white paper detailing their rationale for depending on Arteris FlexNoC interconnect and their approach to NoC floorplan and performance optimization.

Why choose a NoC and why FlexNoC?

Interestingly, for Sondrel “Why a NoC?” isn’t even a question that needs to be asked. I would guess that they have already had more than enough experience with the congestion, timing closure and other problems that come with crossbar-based networks in large SoCs.

Why FlexNoC versus an existing in-house network generator? Sondrel cite packetization and serialization in the transport layer, providing them the ability to precisely control where they can reduce wiring and area without compromising performance. They also cite the ability to create a physically aware design even at a very early stage and control over managing power within the network. Perhaps an in-house network could be adapted to provide similar capabilities? In my view, not really. The basic architecture of a NoC is fundamentally different from a crossbar or anything derived from a crossbar. Adapting would be more like redesigning from scratch. I would guess that Sondrel would not consider this a realistic option.

Where does NoC design start?

I’ve always wondered about where NoC design starts. Do you go for design for traffic optimization first, then floorplan, or the other way round? According to Sondrel either approach can take a while to converge. They start instead with architectural performance exploration. This is used to decide on an appropriate size for the interconnects and memory subsystem by modelling the memory traffic patterns that are generated by all the subsystems as if they were running on the real system (to a reasonable approximation). Here I believe they start with spreadsheet estimation, then move to SystemC modeling with channels for connectivity.

Once this step has converged, then they start running real trials on NoC RTL. This is generated to match the goals of the performance exploration. This they do using a proprietary testbench called Performance Verification Environment. The RTL connects to transactors modeling processors and subsystems defined in Python. In this flow Python generates memory-mapped bus traffic is generated and drives it through the NoC. Allowing the NoC architect to quickly see what is going on in the design and how changes will improve the data traffic flow.

In this flow, the NoC definition starts from an already converged architectural performance goal. From Sondrel’s perspective it is then much easier to fine tune the NoC for performance and floorplan deltas. Avoiding major oscillations in the plan. It is also easier to adjust the NoC architecture as needed in response to spec updates. Just as important, providing feedback to their customers on likely impact of those changes on key performance metrics.

You can learn more about Sondrel HERE.

Also read:

Closing the Communication Chasms in the SoC Design and Manufacturing Supply Chain

SoC Application Usecase Capture For System Architecture Exploration

Sondrel explains the 10 steps to model and design a complex SoC