What Can Go Wrong?

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 approach in the hopes of reducing design costs without affecting time to market.

But are there hidden perils to this 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 caused 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.