Nvidia deep dives Vera CPU for AI data centers — SPEC CPU 2026 benchmarks revealed, Olympus architecture specifics, and more
Setting the stage for a Vera / Venice showdown.
Vera is Nvidia’s first CPU with a core design created in-house, which is the Olympus core. It’s built on Arm v9.2-A, but the design was created by Nvidia, unlike Grace, which leveraged a stock Arm design. Each Vera CPU has 88 Olympus cores on a monolithic die, breaking from the chiplet-based designs available from Nvidia’s x86 competitors.
Nvidia says Vera comes with a 1.5x increase in instructions per cycle (IPC) throughput compared to Grace, and 50% higher performance compared to x86 competitors (it seems that number is per-thread performance with a fully-loaded socket). Nvidia has a single 88-core design with Vera that supports spatial multithreading for 176 threads.
Cores / Threads |
88 / 176 |
L2 cache |
2 MB per core |
L3 cache |
164 MB per CPU |
Memory |
Up to 1.5 TB SOCAMM2 LPPDDR5X |
Memory speed |
Up to 9600 MT/s |
Memory bandwidth |
Up to 1.2 TB/s (aggregate), 14 GB/s (per core) |
PCIe |
88 PCIe 6.4 lanes (CPU only), 96 PCIe 6.4 lanes (Vera Rubin), bifurcation down to x2, CXL 3.1 |
Configurable TDP |
250W - 450W |
The CPU has a configurable TDP range of 250W to 450W. It uses a SOCAMM2 LPDDR5X memory system with capacity of up to 1.5 TB and speeds up to 9600 MT/s, and comes with 164 MB of L3 cache and 2 MB of L2 per core. Vera includes significantly less L3 than Intel’s highest-specced Xeon 6 and AMD’s Zen 5 chips. It actually has more L2 than L3 overall. This, presumably, is due to Nvidia’s fabric, which distributes the L3 in a mesh across the monolithic die.
Below, you can see a layout of the Olympus microarchitecture. Nvidia has disclosed some of the highlights of the architecture previously, such as the 10-wide instruction decode and neural branch predictor, but we now have a full view of the architecture courtesy of Nvidia’s Vera white paper.
The front end starts with Nvidia’s neural branch predictor that can run two branches per cycle “with zero penalties,” according to Nvidia. Research on neural branch prediction dates back to the late 90s, but Nvidia says it has a “novel” neural branch predictor, perhaps building on previous research such as BranchNet.
The BPU feeds into the Instruction Fetch Unit, which holds 64 KB of L1 instruction cache, and loads into a decode queue that supports 48 instructions (we’ll go into the memory/cache layout later). At the last stage of the front end is that 10-wide decode, feeding more instructions into the execution engine per cycle than the 8-wide decode in AMD’s Zen 5 microarchitecture.
Past the front end, the mid-core rename / allocation engine is built to keep instructions moving while waiting on dependencies. In addition to renaming and allocation, instructions work through value prediction, which can speculatively execute the instruction, and memory renaming, where the instruction can move forward while a load is happening if the data relationship can be determined.
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
Inside the execution engine, Nvidia includes eight simple Arithmetic Logic Units (ALUs), two complex ALUs, and four branch units for resolution. For SIMD instructions, the execution engine includes a vector cluster for Arm’s Scalable Vector Extension (SVE), including six vector units that support 128-bit SVE instructions at FP8 precision, along with two crypto-enabled vector units that can handle AES, SHA, and SM3, among other prominent algorithms. Keeping data moving through the engine are four load units and two store units.
The cores support spatial multithreading, giving a Vera CPU with 88 cores access to 176 threads. Traditional SMT time-slices execution, giving both threads access to all of the core resources and sharing them as instructions execute in parallel. With spatial multithreading, each thread of an Olympus core has access to dedicated resources, allowing one of the threads to execute with high-throughput while the other thread handles simple tasks, or to operate as two independent execution environments.
The execution resources are partitioned, explaining the wide decode front end. It’s not clear, however, if the SMT implementation can also opportunistically grab resources, particularly in the scenario Nvidia describes where one of the threads is maximizing throughput while the other handles smaller tasks.
There’s a lot going on in Vera between the 10-wide decode, neural branch predictor, and spatial multithreading, but perhaps the most significant architectural design point is Nvidia’s second-generation Scalable Coherency Fabric (SCF). It underpins Nvidia’s approach of using a monolithic die as opposed to a chiplet-based design, distributing last level cache in a mesh across the die and avoiding the cross-CCD latency penalty with localized L3.
The mesh distributes data through a series of Coherency Switch Nodes (CSNs) that serve as routing points between cores and the 164 MB of distributed L3. These routing points further connect the cores and L3 to the memory system, I/O, and NVLink C2C for cache-coherent communication between chips. Nvidia’s benchmarks comparing Vera to AMD’s Epyc 9755 show that AMD can achieve slightly lower core-to-core latencies within a cluster, but Vera maintains significantly better core-to-core latency across the die, as expected.
Nvidia says SCF inside Vera has 3.4 TB/s of bandwidth, enabling faster core-to-core communication, especially when traversing the die. However, Vera also supports Memory System Resource Partitioning and Monitoring (MPAM), allowing portions of L3 to be partitioned in multi-tenant environments.
Vera uses SOCAMM2 LPDDR5X, which is a relatively new advancement that Nvidia’s competitors haven’t had the chance to benefit from. With the use of SOCAMM2, LPDDR5X provides similar modularity and capacity as traditional RDIMMs, but at significantly lower power draw.
The memory can run at up to 9600 MT/s, with aggregate bandwidth of 1.2 TB/s and per-core bandwidth of 14 GB/s, doubling the bandwidth of Grace. The Vera board supports eight SOCAMM2, offering capacity ranging from 256 GB to 1.5 TB. Nvidia claims a “fully populated” memory subsystem consumes between 30W and 40W depending on capacity.
For I/O, Vera supports PCIe 6.4 with 88 lanes per CPU and bifurcation support down to x2. It also supports CXL 3.1.
Unlike Grace, Vera includes Arm’s Confidential Computing Architecture (CCA) and Realm Management Extension (RME), including Device Assignment and Coherent Device Assignment, offering a boon to multi-tenant environments where VM isolation is key. Nvidia also implements TDISP for coherent devices, allowing for encrypted communication between GPUs and PCIe devices.
Current page: Nvidia Vera CPU architecture -— A closer look at the Olympus core
Prev Page Nvidia Vera CPU Next Page Vera Rubin NVL72, Bluefield, and NVLink
Jake Roach is the Senior CPU Analyst at Tom’s Hardware, writing reviews, news, and features about the latest consumer and workstation processors.
-
usertests Throwing some shade at AMD. I see "Chiplet tax" on one of the slides.Reply
But their comparisons (obviously) are to Turin rather than newly announced Venice. -
bit_user Reply
Only if you're talking about server CPUs. Before that, they made at least two generations of cores for tablet/embedded SoCs (i.e. Denver and Carmel). See: https://en.wikipedia.org/wiki/Project_DenverThe article said:Vera is Nvidia’s first CPU with a core design created in-house, which is the Olympus core.
Ah, but you missed an interesting detail. The way you reach 1.2 TB/s with 9600 MT/s memory is by scaling the memory datapath up to 1024 bits, which is the equivalent of 16x DDR5 DIMMs! Because SOCAMM2 each have a 128-bit data width, you only need 8 of them. I was staring at a photo of the Vera board and wondering how they possibly reached 1.2 TB/s, and that's when it clicked that they actually packed a 128-bit datapath in those little memory modules!The article said:It uses a SOCAMM2 LPDDR5X memory system with capacity of up to 1.5 TB and speeds up to 9600 MT/s
Looking at the block diagram of the core, I'm struck by a few things.
The L1i cache is the same size as Intel's Lion Cove, but surprisingly only 4-way. Intel used 8-way associativity for their I-cache for almost the past 20 years!
At 64 entries, its iTLB is also much smaller than Golden Cove (the last Intel core I could find data for), which has 256 entries.
However, it regains some ground by being fully-associative, whereas the iTLBs of Intel CPUs usually have only 8-way associativity.
The dTLB is more comparable to the size recent Intel CPUs use (112 vs. 128 entries in Lion Cove), but also fully-associative whereas Intel typically uses only 4-way associativity.
At 96k, the L1d is running 2x of Intel's. As with the L1i, its associativity is less (6-way instead of 12-way for Intel).
Its L2 cache is comparable to Raptor Cove's in size, but it's only 8-way associative whereas Raptor had 16-way associativity.
Its STLB is similar in size to the latest Intel core I have data on (3k vs. Golden Cove's 2k).
AMD said it used a neural network-based branch predictor in the original Zen cores. Jim Keller briefly discuss it, in an interview. They apparently had an open contest for people to submit branch predictor algorithms and the neural one simply beat all of the others. If you search the patent database, you might be able to find some on it. That's probably the best chance of finding out how it actually works.The article said:Research on neural branch prediction dates back to the late 90s
The decoder in Zen 5 is hard-partitioned between threads, limiting each to only 4 instructions per cycle. Even if there's only one thread running on the core (or if you disable SMT in BIOS), it still uses only a single 4-wide decoder.The article said:At the last stage of the front end is that 10-wide decode, feeding more instructions into the execution engine per cycle than the 8-wide decode in AMD’s Zen 5 microarchitecture.
But. We should consider that x86 instructions can encompass more functionality than an ARM64 instruction. So, maybe a typical ARM instruction stream needs like 5 instructions to do the same work as 4 x86 instructions. Just spitballing, here. It's not a huge difference, since most instructions are fairly simple and operating register-to-register, whereas x86 instructions get a lot of their density advantage by combining memory loads/stores with some arithmetic or logical operation, and supporting more sophisticated address arithmetic.
Looking only at decode-width is a little misleading, because CPUs like Zen 5 have much wider dispatch (8-way) from their micro-op cache. Since these are now micro-ops, they're more equivalent to ARM64 instructions, in terms of how much work each represents.
BTW, there are two other obvious points of comparison:
The Neoverse V2 cores, used in Nvidia's prior Grace CPUs, have a 6-wide decoder* (source: https://chipsandcheese.com/p/hot-chips-2023-arms-neoverse-v2 )
The Cortex-X925 cores, used in Nvidia's RTX Spark, have a 10-wide decoder (source: https://chipsandcheese.com/p/arms-cortex-x925-reaching-desktop )
* Note that Neoverse V2 still has a mOP cache with 8-wide dispatch. So, as with x86 P-cores, the decoder width is a little bit deceptive.
You skipped a pretty big detail: no mOP cache!The article said:Past the front end, the mid-core rename / allocation engine is built to keep instructions moving while waiting on dependencies.
Modern x86 P-cores and some 64-bit ARM cores had micro-op caches to avoid having to re-decode the same instructions. Once ARM dropped 32-bit compatibility, they started getting rid of those. Also, Intel either doesn't have them in their E-cores, or perhaps what they did was to put some of that into the I-cache.
So, it's interesting (but not all that surprising) that Nvidia followed ARM's approach of just skipping the mOP cache, entirely.
It's darkly ironic that SVE's main selling point was to allow CPUs to scale all the way up to 2048 bits per vector, but all mainstream implementations (except for AWS Graviton 3) are just 128-bit.The article said:For SIMD instructions, the execution engine includes a vector cluster for Arm’s Scalable Vector Extension (SVE), including six vector units that support 128-bit SVE instructions
Not really. The way AMD describes SMT in Zen 5 is that certain competitively-shared resources have watermarks that limit how much a single thread is able to use, so that it doesn't starve out the other thread. However, when there's only one thread running on a core, more of those constraints go away and only the statically-partitioned resources (e.g. the decoder) remain exclusive.The article said:Traditional SMT time-slices execution, giving both threads access to all of the core resources and sharing them as instructions execute in parallel.
My read on "Spatial Multithreading" is that it's Nvidia's marking machine trying to spin a weakness to make it sound more like a strength. This being Nvidia's first SMT implementation (AFAIK), it won't have the same sophistication as where Intel and AMD have gotten, over a couple decades of experience implementing and refining theirs.
First, Intel has traditionally done the same thing. However, I need to catch up on what they've said about Sierra Forest.The article said:Nvidia’s second-generation Scalable Coherency Fabric (SCF). It underpins Nvidia’s approach of using a monolithic die as opposed to a chiplet-based design, distributing last level cache in a mesh across the die and avoiding the cross-CCD latency penalty with localized L3.
Second, people tend to overestimate the impact of the cross-CCD thing. Unlike Intel CPUs, one AMD CCD won't write data to another's L3 slice. Each is private to that CCD, except for coherency. That said, when you've got multiple threads that are either exchanging or both modifying the same data, and they happen to be scheduled on different CCDs, that is when you feel the impact of the die-to-die communication.
Anyway, AMD's approach has clearly scaled better. I think that's why Sierra Forest looks like it moved in the direction of doing the same thing with segmenting its L3 cache.
I don't know what happened here, but the slide with the annotated die photo shows it supporting PCIe 6 with only 16 lanes.The article said:For I/O, Vera supports PCIe 6.4 with 88 lanes per CPU and bifurcation support down to x2.
P.S. As for the benchmarks, the initial Phoronix review was interesting, but now I'm just waiting for some independent analysis. From a CPU microarchitecture standpoint, what I really want to know is the single-threaded performance across the whole SPEC suite, and how the sub-scores compare with other CPUs. MT scaling is mildly interesting, but it really stacked that deck in its favor by having relatively few cores and huge amounts of memory bandwidth. So, I expect it scales well, but not well enough to outright beat Intel or AMD on anything that's not fundamentally bottlenecked by memory bandwidth. -
bit_user Reply
Announced? Venice is launching in about a week! That's probably why Nvidia is making a bunch of noise about this now!usertests said:But their comparisons (obviously) are to Turin rather than newly announced Venice. -
Stomx I like NVIDIAs marketing department scaling results per core. This is the height of aerobatics. Interesting how all would compare per core with the AMD 64core Turin 9575F, their king of single core benchmarks ? And how per core comparison will look for just the 64 core Venice? Huang will leave full of tears on leather jacketReply -
bit_user Reply
Good question. Where Vera has a big lead over AMD's Turin is that it has basically 2x the memory bandwidth. Also, ARM uses memory bandwidth a little more efficiently, due to its relaxed memory consistency model.Stomx said:I like NVIDIAs marketing department scaling results per core. The height of aerobatics. Interesting how all would compare per core with the AMD 64core Turin 9575F, their king of single core benchmarks ?
Where AMD would win biggest is going to be on AVX-512 stuff that's not memory-bound.
Otherwise, it looks to me like Vera might have a slight edge over Zen 5. I mean it's a 10-way dispatch core vs. an 8-way one. Even Zen 6 will remain 8-way, if the rumors are correct. Not to say dispatch width is everything, since Intel's cores are also wider, but it's at least a good starting point. I think Zen 5 does have 3 integer multiply ports vs. Vera's 2.
Yeah. With Venice, AMD is going to leap-frog Nvidia's memory bandwidth by approximately 33%, according to what they've said. That's to be accomplished using 16 DIMMs (matching the same data width as Vera of 1024 bits) using MRDDR5-12800. So, on low core-count models, they'd stomp Nvidia on per-core memory bandwidth.Stomx said:And how per core comparison will look for just the 64 core Venice? Huang will leave full of tears on leather jacket -
palladin9479 Performance isn't really important, it's only real job is to manage the workloads for the GPU like devices connected to it. It only needs to be fast enough to not make the GPUs wait around.Reply -
bit_user Reply
I think that explains why it doesn't have a lot of cores, but it doesn't explain why Nvidia went to the trouble of designing their own cores instead of just licensing the next Neoverse V-series core, like they did in their Grace CPU and like Amazon did since Graviton 3.palladin9479 said:Performance isn't really important, it's only real job is to manage the workloads for the GPU like devices connected to it. It only needs to be fast enough to not make the GPUs wait around.
Arm's Neoverse V3 seems to be derived from their Cortex-X4, which is also a 10-way core (source: https://www.androidauthority.com/arm-cortex-x4-explained-3328008/ ), though it has only 4x SVE2 pipes. However, I think the X4 and V3 are probably more efficiency-focused and don't clock very high. Graviton 5 uses Neoverse-V3 at 3.3 GHz, for instance.
So, it seems like the main things it seems Nvidia got by making its own core was the ability to achieve higher single-thread perf by hitting higher clock speeds and the ability to add SMT for better utilization.