For infrastructure administrators supporting semiconductor engineering, the useful question is not simply whether a processor is faster. It is whether an entire farm can complete more validated work under realistic load. Microsoft’s report provides some evidence on that front, alongside several important qualifications.
What Microsoft tested
Microsoft evaluated workloads from its own silicon-development environment, including digital simulation, analog simulation, physical verification, and static timing analysis. Crucially, the Arm-enabled tools already running on Cobalt 100 operated without modification in the Cobalt 200 evaluation. That establishes continuity for those existing tool configurations, not universal compatibility for every EDA installation.
The reported results break down as follows:
| Tool | Evaluated task | Cobalt 200 result |
|---|---|---|
| Cadence Xcelium | RTL digital simulation | 4.15× Cobalt 100’s peak throughput per logical core |
| Synopsys VCS | RTL digital simulation | 2.58× Cobalt 100’s peak throughput per logical core |
| Cadence Spectre | Analog simulation | 38% higher throughput per logical core than Cobalt 100 |
| Siemens Calibre DRC | Physical design-rule checking | Approximately 23% lower elapsed time than Cobalt 100 |
| Synopsys PrimeTime | Static timing analysis | 2.03× Cobalt 100’s peak throughput per logical core, rounded to 2× in the report’s text |
Microsoft’s charts and methodology notes support these figures for the particular internal test cases. Xcelium and VCS each delivered more than 40% higher per-logical-core throughput than every other tested configuration; Spectre, Calibre, and PrimeTime also exceeded the selected x86 Azure systems on their respective measurements.
The takeaway: Cobalt 200’s improvement was broad across the evaluated tools, but decidedly uneven. A 4.15× simulation result should not become the assumed acceleration for an entire chip-design pipeline.
Throughput and runtime are different promises
The distinction between completing one job sooner and completing more jobs per hour matters throughout this report.
For Xcelium, VCS, Spectre, and PrimeTime, Microsoft measured concurrent work and normalized throughput per logical core. Spectre used 16 threads per job, while PrimeTime used 16 cores per job. Each platform’s highest measured throughput supplied the relevant peak comparison.
Calibre was different: its internal IP-macro design-rule-checking case ran with 16 cores on a quiet VM. Its result therefore measures elapsed job time, rather than the same heavily loaded throughput scenario used elsewhere.
That makes the Calibre result no less useful—just useful for a different planning question. A signoff engineer waiting for one critical check may care most about elapsed time; a verification-farm operator may prioritize completed regression jobs overnight.
Likewise, 1.30× performance and roughly 23% less elapsed time are consistent descriptions, not conflicting claims. At exactly 1.30× speed, a hypothetical 100-minute job would take approximately 77 minutes. That is an illustrative calculation, not an additional Microsoft measurement.
Why the core-count comparison needs care
The evaluated configurations included Cobalt 100 with 96 cores, Cobalt 200 with 128 cores, hx176rs with 176 cores, and e160adsv7 with 160 logical cores. Logical cores corresponded to physical cores in the first three configurations; the last used hyperthreading. Normalizing by logical core accounts for different advertised core counts, but does not make a hardware thread architecturally equivalent to a full physical core.
Consequently, these charts should not be read as whole-VM rankings, pricing comparisons, or evidence that Cobalt 200 beats every x86 alternative. Microsoft limits the findings to the evaluated workloads, software versions, configurations, concurrency levels, and conditions. The post also does not provide the complete tool versions, design inputs, and run-level data needed for independent reproduction.
For procurement, the sensible next measurement is therefore cost per successfully completed workload, alongside completion deadlines—not an isolated per-core multiplier.
The platform story extends beyond the CPU
Microsoft’s separate June 2, 2026 preview announcement adds useful architectural context: Cobalt 200 uses a chiplet design, provides 3 MB of dedicated L2 cache per core and 192 MB of system-level L3 cache, and supports VM sizes up to 128 vCPUs. That announcement positions the platform for Linux-based cloud workloads; these EDA results should not be mistaken for a Windows-on-Arm application compatibility announcement.
Storage deserves equal attention. Microsoft Learn’s Azure NetApp Files guidance classifies EDA among metadata-rich, high-file-count workloads. It explains that operations other than straightforward reads and writes can represent most I/O activity, making operations per second an important sizing consideration. A storage specification expressed only in gigabytes per second can therefore miss a consequential part of the workload.
That is a practical addition to the CPU benchmarks: test the shared filesystem under the same concurrency as the compute farm. Faster processors are less persuasive when they merely reach the storage queue sooner.
How to evaluate the findings responsibly
Based on the report’s boundaries and Microsoft’s storage guidance, an evaluation should:
- Confirm the exact supported tool configuration. Treat the unchanged Cobalt 100-enabled tools as evidence for those configurations, not every plug-in or dependency.
- Separate latency from throughput. Record both individual job duration and completed jobs per hour.
- Increase concurrency deliberately. Look for the point where additional jobs stop improving useful throughput.
- Measure storage operations as well as bandwidth. Include representative design databases and output activity.
- Validate correctness and economics. Compare accepted results and total execution cost, rather than rewarding a fast but incomplete run.
These are evaluation recommendations synthesized from the published limitations, not a Microsoft-prescribed migration procedure.
Microsoft says it is expanding workload coverage, validating at greater scale, and tuning with EDA partners as Cobalt 200 enters general availability. It also presents proximity to Azure AI services as an opportunity for future assisted design workflows—not a benefit measured by these benchmarks.
The strongest conclusion is narrower and more useful than a sweeping architecture victory: Microsoft has demonstrated substantial improvements across several established EDA tools using existing Arm-enabled configurations. Cobalt helping design the next Cobalt is an appealing loop. Whether it improves another engineering team’s schedule will depend on that team’s tools, designs, concurrency, and storage—not just the tallest bar in Microsoft’s chart.