Arteris Articles

Semiconductor Engineering: Who Owns A Car's Chip Architecture Video

Tech Talk Video: Who Owns a Car's Chip Architecture 

May 5th, 2020 - By Ed Sperling

Kurt Shuler, vice president of marketing at Arteris IP, examines the competitive battle brewing between OEMs and Tier 1s over who owns the architecture of the electronic systems and the underlying chip hardware. This has become a growing point of contention as both struggle for differentiation in a market where increasingly autonomous vehicles will all behave the same way. That, in turn, has significant implications for customization and standards, as well as the hiring of chip expertise inside of these companies as companies race toward fully autonomous driving.

Topics: network-on-chip semiconductor low power ADAS tech talk video on-chip memory data centers automotive chips semiengineering

Semiconductor Engineering: Last-Level Cache Video

Tech Talk Video: Last-Level Cache 

April 6th, 2020 - By Ed Sperling

Kurt Shuler, vice president of marketing at Arteris IP, explains how to reduce latency and improve performance with last-level cache in order to avoid sending large amounts of data to external memory, and how to ensure quality of service on a chip by taking into account contention for resources.

Topics: network-on-chip semiconductor CodaCache tech talk video on-chip memory data centers memory hierarchy semiengineering

FlexNoC Version 3 available now!

We announced FlexNoC Version 3 today!

Our primary engineering goal with this totally new technology release was to increase the productivity of our SoC designer users.

As the size and complexity of our user’s SoC designs increased over the years, it had become increasingly difficult to visualize and optimize a huge design in a single GUI window. In addition, we saw the need to make the FlexNoC user interface adapt to whatever task the user is performing, rather than provide the same access to the many options within FlexNoC.

Under the hood, we increased the performance of all aspects of the product, not just user interface response but also performance modeling and exploration.

Here are the top 3 features in the new FlexNoC Version 3:

  1. Switch-based topology editor – It is now easier to create, characterize and modify large designs while keeping access to the entire SoC topology available within a single view.
  2. Topic- and activity-based user interface – Years of customer feedback and human factors research have resulted in a streamlined interface that makes it easier for SoC architects and designers to perform complex and repetitive tasks.
  3. NoC composition enhancements – Users can more easily break large interconnect designs into smaller modules for implementation by different sub-teams, and can quickly combine separate designs or modules into a single interconnect instance for integration.


Current customers can upgrade from the current version of FlexNoC to FlexNoC Version 3. Just contact your Arteris sales manager.

For prospective customers, please contact me and we'll get you started!

For more details, please read our press announcement below.


Topics: network-on-chip SoC design Arteris FlexNoC

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