Arteris Articles

EE Times article, "Licensing Interconnect IP for Fun & Profit"

Kurt Shuler, VP Marketing at Arteris IP, authored this EE Times article discussing NoC interconnect Build or Buy.

February 25, 2021 - by Kurt Shuler

Why do we buy instead of build? Because the guys at the factory know what they’re doing.

The big question then becomes, which parts do we design in-house, and which do we bring in from outside? That’s a whiteboard architectural discussion, which can be heated and emotional. Engineers want to build stuff — that’s what they do. Managers want to get a working product out the door as economically as possible — that’s what they do. If the engineers want to make, and the managers want to buy, who wins? Who gets to make that call, and how do they justify the decision? 

Topics: SoC economics semiconductor eetimes AI SoCs RTL kurt shuler noc interconnect ML/AI SoC IP R&D costs buy vs build build vs buy

IEEE Electronics 360: How to Efficiently Achieve ASIL-D Compliance Using NoC Technology

Learn from the experts at Arteris IP in this new White Paper:

How to Efficiently Achieve ASIL-D Compliance Using NoC Technology




Topics: SoC economics Synopsys functional safety semiconductor automotive ADAS ISO 26262 compliance artificial intelligence arteris ip latency ASIL D interconnects soc designers aerospace aeronautics LED kurt shuler Z01X Austemper

The Critical Cost of Routing Congestion

By Jonah Probell, Senior Solutions Architect, Arteris

Topics: SoC SoC economics SoC design routing congestion timing closure

Divide & Conquer: Dispersed global design teams need NoC fabric IP

It’s no surprise that most corporate system-on-chip (SoC) design teams are dispersed throughout the world, with different functional teams often located in different countries and continents. For example, we have many customers whose SoC architecture is defined in the United States, but subsystems such as graphics and signal processing are designed elsewhere. Companies choose this "divide and conquer" approach in the hopes of reducing design costs without affecting time to market.

But are there hidden perils to the divide and conquer SoC design approach? And what can be done to avoid these problems?

Dividing SoC design tasks is easy. Reassembly is not.

According to a recent survey of our customers, the management of global design teams doing geographically distributed development is one of the most important issues facing SoC design managers today. After much personal research and interviewing of respondents, I discovered that the act of separating a system-on-chip architecture into different work packages and “parceling out” the implementation of SoC subsystems to different design teams is not the major issue. Rather, the big problems occur once the team attempts to reassemble the various subsystems into a single SoC design.

And the real killer is that most of these problems are not discovered until very late in the design cycle, after SoC reassembly and top-level verification are attempted.

This results in schedule slips.

To understand what is happening, imagine an IP subsystem design team that receives a specification from headquarters for the company’s latest SoC design. The design team implements its particular subsystem to integrate with the rest of the SoC design according to their best understanding of the overall specification.

Of course, the SoC specification is constantly changing and the design team members do not always receive spec updates in a timely manner. Furthermore, there are ambiguities in the SoC specification that must be addressed directly with the SoC architect, or ignored for convenience with assumptions made by the subsystem design team documented in release notes.

As the schedule progresses, the top-level SoC team receives the IP components from the different subsystem IP teams and assembles the subsystems into the final SoC design for verification. But these blocks are not connecting. Transaction protocols, addresses locations and registers are not mapping to what the SoC assembly team is expecting.

What happened?

Changes cause schedule slips

In the software world, we might call this a “change control” problem. As each IP subsystem team progressed with their own designs, they attempted to keep up with changes in the overall SoC specification for on-chip connectivity (transaction protocol definitions, register definitions, and memory map locations, for example). However, as the definition of the overall SoC spec was changing, so was the spec for their own pieces of the design.

The result is that even though all the SoC subsystems passed their own block-level verification test, it is impossible to assemble and verify the SoC design with these blocks. What happens in the real world is that the top-level (SoC-level) verification team members find these connectivity failures and report them to the SoC team and the IP subsystem teams. Then everybody works together to hack the RTL so that everything connects correctly and passes verification. And the SoC schedule slips.

New NoC technology enables easy SoC reassembly

The good news is that this scenario happens less frequently today than it did only a couple of years ago. On-chip NoC interconnect fabric technology makes it easy to separate a complex, multi-hundred IP block SoC into multiple subsystems that can be implemented anywhere in the world. And new technology allows these pieces to be automatically reassembled into a verifiable SoC no matter what changes were independently made to the transaction protocol definitions, registers or address locations of any part of the SoC.

As the most advanced process nodes migrate down to 20nm and 14nm, the “sweet spot” for most systems-on-chip will descend from today’s 65nm down to 40nm and lower. For SoC makers to realize the cost benefits of 40nm processes and smaller, they will have to put the semiconductor IP of what used to be in two or three chips onto a single SoC. And to do this they will most likely have to work through the challenges of having parts of each SoC designed by multiple design teams located throughout the world.

Today’s advanced NoC technology guarantees that these teams will be able to successfully implement a global design methodology and reap all the cost benefits of smaller process nodes.

Topics: SoC economics network-on-chip SoC design NoC composition