Measured in 37 full-system SimBricks runs

The faster accelerator lost.

Design A needs 25% less time per request than Design B. Put both into a complete system and A loses: once the one-way PCIe latency passes about 0.7 µs, B answers first. At 2.5 µs, the far end of the range we measured, A is 36% slower end to end.

Same matrix multiply block, two host interfaces. Measured with SimBricks, which runs a design inside a complete simulated system (hosts, NICs, a switch, PCIe) with the real, unmodified software stack on top, before the hardware exists.

Watch the 60-second walkthrough Explore the measured runs

Want this answer for your own design? Book 20 minutes with us

Median end-to-end latency per request, over 60 requests per run. Same two designs, same workload. Only the one-way PCIe latency changes, on every link, the NICs' included; the NIC side costs both designs the same.

25%less time aloneBenchmarked alone, A needs 1,920 µs per request and B needs 2,560 µs.

36%slower in the systemAt 2.5 µs one way, the far end of the measured range, A takes 4,286 µs end to end and B takes 3,145 µs.

~0.7µswhere the ranking flipsBetween the measured points at 0.5 and 1.0 µs one way. At 1.0 µs, A is already 6% slower; across the range, B's latency moves 2% and A's 45%.

The accelerator is a stand-in: one matrix multiply block with two different host interfaces. Everything around it is simulated at full-system level, and the software is real and unmodified.

The walkthrough

Which design wins, where it flips, and why

One minute, narrated. It starts muted: turn the sound on in the player. Subtitles are burned in.

Alone

A is the faster block

A needs 12,000 cycles per tile, B needs 16,000. Benchmarked alone, A wins at every setting we measured.

In the system

The number belongs to the whole path

Every request crosses the client's software, a NIC, a switch, the server's software and driver, and the PCIe link, in both directions. SimBricks runs all of it as one system on one clock.

Why it flips

A's interface waits on the link

A's driver runs each of the 64 tile steps across the link: DMA, a doorbell, and register polls that each wait a full round trip. That costs about ten link latencies per step. B takes the whole request from a descriptor ring and pays about seven per request. The slower the link, the more A's per-step traffic costs.

The measured runs

Move the two knobs the decision turns on

Every setting on the sliders was actually run. The verdict, the cards, the timeline, the map and the chart all read from the same 37 runs.

Design A, wide array

DMA, every step polled over MMIO

Component benchmark

Effective service time

Time spent computing

End to end, median

Design B, deep pipeline

descriptor ring, DMA overlaps compute

Component benchmark

Effective service time

Time spent computing

End to end, median

Deep visibility

One request, traced end to end

Every event on one clock. Click a design card above to follow its request instead.

Built from the simulators' own logs, joined per request on one synchronized clock: the hosts' PCIe events, the accelerator's trace and the switch's packet trace. The same data exports to Jaeger or Grafana over OpenTelemetry. Logging never changes the simulated system, but it does slow the simulator and produces large logs.

The map

Where each design wins

Which design wins depends on two things: how fast the array computes, and how far away it sits on the interconnect. Click a cell to load it above.

Each cell is a pair of measured runs. A's lead shrinks as the link gets slower; B hardly changes across a fivefold range. Alone, A is the faster block in every cell.

Design space

Does the decision hold across the plausible range, or flip inside it?

The component ranking never changes. The system ranking flips at about 0.7 µs one way, and the gap keeps growing with the link latency.

More from the same runs: the software baseline, and load

Is an accelerator worth it, and does its interface matter?

The same request with no accelerator at all, and with Design A's compute unit behind a simple register copy interface, next to the two designs.

More clients reward the queue

With several requests in flight, the server hands Design B the next request before the last one is done.

Data: 37 SimBricks runs, September 2026. Full-system Linux hosts in gem5, Intel i40e NIC models, a SimBricks switch, and the accelerator models on the PCIe bus, every link synchronized.

Your design next

Get this analysis for your own design

Send us one model of your block and one workload you care about. We build the SimBricks virtual prototype around it and hand back the same answer for your design, while both hardware and software can still change.

Your design as a behavioral model now, or as RTL later, with the rest of the system unchanged
Your real, unmodified software stack on top
Which option wins, where the ranking flips, and the trace that shows why

Book 20 minutes with us Or write to us directly: info@simbricks.io We do the integration work. Your team reviews the result.

Questions

What is measured, and what is not

Do you have further questions?
Contact us at info@simbricks.io

Each request multiplies two 512 x 512 matrices. The accelerator works through it as 64 products of 128 x 128 tiles: 16 output tiles, each summed over 4 steps.. One-way PCIe latency, on every link, runs from 0.5 to 2.5 µs and compute speed from 0.25x to 2x. Numbers are medians. With one request in flight, the p99 stays within about 2% of the median at most settings; at the slower compute speeds it reaches up to 16% above it. Background load is not measured yet, and the runs with two accelerators per server are not shown here.

Design A's driver runs each of the request's 64 tile steps across the interconnect: it moves the operands by DMA, rings a doorbell and polls a status register, and every poll stalls the CPU core for a full round trip. In the measured runs that is about ten link latencies per step, some 650 per request. Design B fetches the whole request from a descriptor ring and pays about seven link latencies per request. The NICs sit on PCIe links too and cost both designs the same.

No. It goes in as a behavioral model early and as RTL later, without changing the rest of the configuration.

SimBricks itself is open source, on GitHub, and our platform runs it from a browser UI or an SDK, on-prem or in the cloud. The setup behind this page (the accelerator models, the system configuration, the sweeps and the trace analysis) is available on request: write to info@simbricks.io for early access, or let us run it with you on your design.