New Processor Architectures in a Post Moore's Law Era

There’s plenty of healthy debate on how valid Moore’s law remains today. But there’s no denying that the predictable doubling of chip performance every couple of years that has guided the semiconductor industry for so long is slowing down. Eventually, it will simply be physically impossible to develop chips with ever smaller (and greater numbers of) transistors. However, engineering ingenuity is alive and well, and chip designers continue to find ways to push the envelope toward better performance, power, and area (PPA).

Optimizing processor architectures for changing workloads is one outcome of this quest to extract more from Moore’s law. As it becomes futile to generate more performance simply by moving to smaller geometries and cranking up the clock frequency, design engineers are considering different SoC architectures that are more efficiently tailored to their demanding and ever-changing workloads. Algorithms, too, have become more innovative to address the needs of applications like artificial intelligence (AI) and sensor fusion; this impacts SoC architecture decisions as well. In this blog post, we’ll examine how changing processing workloads and increasingly innovative algorithms are driving the need for new processor IP—and how designers of embedded SoCs are addressing the never-ending demand for higher performance while staying within their area and power budgets.

What’s Needed to Support Specialized Processor Architectures?

The specialized processor architectures we’re now seeing present a new set of challenges for programmability and tooling. After all, the complex, multi-processing architectures that are emerging to support these workloads are hardly useful if the chips are difficult to program. This calls attention to the need for a robust set of tools that are aligned to these types of architectures, easing the process for engineers to program and port their applications to the different processors.

A heterogenous processing architecture raises the big question of how all the components should be connected to best support parallel processing. Certain cores may be placed in close proximity and, as a result, could share resources like cache memory. It’s useful, then, to take a data-centric view of the architecture and determine where the data is located, where it’s processed, and where it’s needed. Keeping data local to a processing cluster reduces power consumption and read latency while offloading the network-on-chip. To provide a flexible memory scheme for processing local data, shared SRAMs can be dynamically partitioned between the L2 cluster cache and the cluster shared memory (for use by other processing elements that might share the resource with the multi-core cluster). The designer can decide how these memory resources should be shared across the different processors. High-bandwidth and low-latency interconnects also ensure fast data transfer between the cores.

Another important consideration for the processor architecture involves the power and clock domains. Independent power and clock domains help simplify the physical design, while minimizing power and area. Cores in the cluster can reside in their own power domains, with each core running its own clock.

Inside the Processor Architect’s Toolbox

To facilitate an effective heterogeneous processing architecture, the processor architect has a variety of options in the toolbox.

• Multi-core performance scaling for applications that can be parallelized can result in near-linear speedup; key to making this a reality are a low-latency processor cluster architecture and sufficient communication bandwidth
• Hardware acceleration via a dedicated processor or custom hardware
• Application-specific instruction-set processor (ASIP) plus firmware, which provides the flexibility of the processor plus software option along with the power and area efficiency of hardware accelerators

Our tools include development kits, compilers, debuggers, simulators, open-source software, GNU tools, and documentation that are designed to simplify the development and programming processes. For example, with our APIs, programmers can write, say, a neural network application without worrying about how the workload gets partitioned or processed at the hardware level. The APIs handle this via a layer that determines the most efficient processing element on which to run the software. Another example is the debugging environment, where the user is presented with a concurrent view of different heterogeneous cores for an efficient, synchronized debugging process.

When off-the-shelf processor IP doesn’t quite meet a design’s unique workload requirements or if there’s a need to future-proof processing competencies, a team might opt to design an application-specific processor, or ASIP, which provides software programmability within its application domain. The Synopsys ASIP Designer tool automates the design and implementation of ASIPs, providing rapid exploration of architectural choices, generation of an efficient C/C++ compiler based software development kit that automatically adapts to architectural changes, and automatic generation of power- and area-optimized synthesizable RTL.