10 Reasons to Customize A Processor Core

10 Reasons to Customize a Processor Core

There are plenty of really good, proven processor cores on the market today. But if you have more than simple control tasks, perhaps you've considered using a processor that you can customize. We'll give you 10 good reasons why you should consider customizing your core in your next SOC design.

Customizable processor cores first hit the market in the late 1990s, and since then many improvements have been made in the way these processors can be customized. Much of the process now is highly automated to speed up the process and guarantee that the processor core can't be broken during the customization process.

But before we tell you how easy it now is to customize a processor, and how good the results can be, let's first look at the top 10 reasons to customize a processor core.

Reason #1 - Lower Power

Some people think that all RISC processors deliver about the same performance per clock cycle. This assumption is wrong for processor cores that have been customized for a specific application. By customizing the processor, designers can get a significant performance improvement for each clock cycle.

A designer can add custom instructions to a processor's ISA, which will increase the processor core's size, which in turn increases the processor core's average power dissipation per clock cycle. However, is the new instructions dramatically cut the total clock cycles required to perform a given workload, then the total energy consumed (power-per-cycle multiplied by total cycle time) can be substantially limited.

Example: A 20% increase in power dissipated per clock cycle, offset by a 3x speed up in task execution, actually reduces energy consumption by 60%. This reduction in required task-execution cycles allows the system either to spend much more time in a low-power sleep state or to reduce processor's clock frequency and core operating voltage, leading to further reductions in both dynamic and leakage power.

Reason #2 - Avoid RTL Verification Hell

What's the alternative to building the acceleration right into the processor? With standard RISC processors, the answer is to build your own RTL blocks for the acceleration. And we all know what that means - months of lengthy complex verification cycles. In most RTL blocks, the FSM (finite state machine) contains nothing but control details. And most of the design and verification risk is in the FSM, due to its complexity.