Reading Real Core Specs

Every processor comes with a datasheet or a marketing page full of numbers: pipeline stages, issue width, cache sizes, DMIPS per megahertz, CoreMark scores. By now you know what each of those means. This article puts that knowledge to work. It goes through what a core description tells you, what it leaves out, how to compare two real cores, and how to spot numbers that sound better than they are. It finishes with a method for choosing a core for a product.

13 min read | Intermediate

What You'll Learn

• Read the main fields in a processor core's description
• Interpret DMIPS, CoreMark and SPEC figures per megahertz
• Identify what a spec sheet leaves out
• Compare cores for a real product using PPA and software needs

What a Core Description Contains

A company selling a processor core, or a chip containing one, usually publishes something like this. The following is an invented example, with typical values for a mid-range application core:

The value of having read this tutorial is that you can now read each line as a design choice. Nine stages means a mispredict costs about eight cycles, so the predictor matters, as Why Branches Hurt explains. Dual-issue in-order means an IPC peak of 2, with a real figure around 1. The cache associativity and size follow the VIPT rule: 32 KB with 4-way would need more than one page per way at 4 KB, so this core must do something about aliases, or use a physical index with an extra cycle.

Three Real Cores

Here are rounded public figures for three well-known Arm cores, to show the range. Exact numbers vary by source, compiler and configuration:

The pattern matches this tutorial. Going from a single-issue to a dual-issue design with a much larger memory system doubles the work per cycle, at many times the area. Arm publishes the first two; for the A53 it gives no official figure, and 2.3 is a commonly quoted estimate. These figures are in DMIPS, which, as Workloads and Benchmarks warns, is a dated measure. Its value here is only for rough comparison between cores from the same vendor.

Reading Performance Numbers

Performance numbers come in a few forms.

Per-MHz figures, such as CoreMark/MHz, separate the microarchitecture from the clock. To compare cores, multiply by a real frequency. A core with 5 CoreMark/MHz at 1 GHz gives 5,000 CoreMark, and a core with 3.5 CoreMark/MHz at 2 GHz gives 7,000.

Dhrystone and CoreMark fit in small caches, so they say little about memory. A design with a poor memory system can still get a great score, and on real software it will fall far short.

SPEC CPU scores reflect real programs and depend heavily on the memory system, the compiler and the options. Compare them only if you know these. A score "per GHz" sounds neat, but it is not a constant, because memory latency in cycles rises with frequency: a core at twice the clock doesn't get twice the score.

Multi-core scores need care too. Eight small cores can beat four large ones on a throughput test, while they feel slower on a task that runs on one thread. Check both the single-thread and multi-thread results.

What Spec Sheets Leave Out

Some of the most important facts are rarely on the first page. A careful reader asks about these:

• Conditions of the area figure. Does it include caches? Is it in the fastest library or the densest? Is it after layout, or just synthesis? An area of "0.1 mm²" with no caches and no floating point is not the same as a usable core.
• Conditions of the frequency. Is it the typical corner at high voltage, or the worst case at the lowest? A processor's guaranteed sign-off frequency can be far below its best-case number.
• Conditions of the power. µW/MHz is usually dynamic power on a simple benchmark at typical voltage. It leaves out leakage, the cost of memories, and any peak.
• Memory latency. Rarely stated, and it often decides real performance. Ask for a load-to-use time at each cache level, and the DRAM latency for your system.
• Non-performance factors. Debug support, trace, the toolchain, safety documents, the license terms, and what software already exists.

What Vendors Say About Microarchitecture

For large cores, detailed diagrams appear in conference talks and technical guides, and independent reviewers measure things such as the size of the reorder buffer, by clever timing tests. A typical description of a large core lists the front-end width, decoder count, ROB size, physical register count, load and store queue sizes, execution ports and cache latencies. All these were covered in Out-of-Order Execution and Register Renaming, so you can read such a description and see where a core has spent its area.

Look at the balance. A wide decoder with a small window suggests the design is limited in the back end. A huge window with a small L2 suggests it will often sit waiting for memory. Well-designed cores have structures that are balanced, so that no single one holds back the rest.

Reading a Large-Core Description

Large out-of-order cores are usually described by the sizes of their internal structures. Here is an invented example with typical values for a recent high-end design:

A quick check is to multiply the fetch width by the time of a long miss. At 6 instructions per cycle and a 300-cycle DRAM access, a core would need a window of 1,800 entries to stay busy for the whole miss, so even a 400-entry window will fill up and stall. That simple sum explains why real workloads rarely reach the peak IPC, and why the memory system matters so much for a large core.

Why Process Numbers Do Not Compare

A process name such as "5 nm" no longer measures anything on the chip. It began as the length of a transistor's gate, but today it is little more than a generation label, and two foundries' "5 nm" processes can differ a lot. Compare real figures instead, such as logic density or the area of a standard SRAM cell. Performance per watt also depends on the library chosen: high-performance cells, tuned for speed, leak far more than low-power ones. A vendor quoting a frequency from one library and a power from another is describing a chip that doesn't exist.

A Method for Choosing a Core

When a project needs a processor, work through these steps:

1. List the workloads. What runs on it, how much, and how fast does it need to be? Is there an OS? Is any of it real-time?
2. Translate into requirements. Required performance on those workloads, with a margin, and limits on area and power, as From Use Cases to Requirements explains.
3. Decide the must-haves. Instruction set, 32 or 64 bits, MMU or not, floating point or vector, safety features, security features.
4. Shortlist by rough performance, and check the area and power in your process, not somebody else's.
5. Measure. Run your code on a real board, a fast model, or a vendor's evaluation.
6. Check the rest: the toolchain, the debug tools, the cost, and the roadmap.

Example

Suppose a product runs a control loop every 100 µs that needs 8,000 cycles on a typical 32-bit core, plus a small network stack, at 100 MHz, with a tight area budget and no Linux. These numbers are assumptions for this example. A small in-order core with a TCM and a simple cache does the job: 8,000 cycles is 80 µs of the 100 µs, which is tight, so it needs either a faster clock or a core a little better per cycle. A hardware multiplier may help, as might a small branch predictor. A large out-of-order core would be wasted here, because its timing varies and its area and power are too high.

Where to Find the Details

A marketing page is only the start. Most processors have three deeper documents. A technical reference manual describes the core's registers, its configuration options and sometimes its pipeline. A software optimization guide, published for many large cores, gives instruction latencies, the number of execution units, and the penalties to avoid, which is often the best public description of the microarchitecture. And an errata list records known bugs, which tells you how mature the design is. For a new product, reading the errata is often more useful than reading the brochure.

If those documents are not available, that is useful information too, because support for the core may also be thin.

One errata item about an interrupt or cache bug can rule a core out on its own, if your product leans on that feature.

Common Mistakes