Some “demos” at industry events are slideware. A polished animation loops on a screen while a presenter narrates what the technology would do under real conditions. For 5G edge compute, where the whole pitch rests on latency, throughput, and power efficiency under load, that gap between claim and screen is exactly where buyers stop believing you.
Operators and infrastructure vendors evaluating edge platforms have learned to ignore the animation. What moves a conversation is a measured result, produced live, on real hardware, in front of people who can change the parameters mid-demo. And building a system that can do that is a hard engineering problem in itself, separate from the silicon on stage.
A recent project shows both the difficulty and the payoff.
The challenge: 30 days, no demo stack
A U.S. semiconductor startup was building a chiplet-based edge compute platform: ARM CPU chiplets paired with a dedicated processing unit, aimed at the AI and 5G workloads operators are pushing toward the network edge. The pitch was cloud-grade performance at a fraction of the power draw of conventional server hardware.
The problem was the calendar. With about 30 days before a major Mobile World Congress demonstration, the company had its 5G L1 datapath and silicon concept in hand. It had no software to run a demo, coordinate hosts, or show anything to an audience. Its own engineers were buried in the computational core. So the startup brought in an external engineering team to own the entire demo stack and build it from zero.
Why the architecture mattered
You can’t assemble a credible edge demo from loosely coupled scripts. To make an energy-efficiency comparison believable on stage, the system had to do four things at once and do them reliably: drive the datapath with deterministic real-time control, process packets with minimal overhead, coordinate two different host architectures, and show consolidated results clearly enough for a live audience to follow.
Each of those pulled toward a specific technology choice. And every choice had to integrate cleanly with the client’s existing physical-layer processing. That integration boundary, not the dashboard, was where the real risk sat.
Technical implementation
The team built the platform as three layers running over the client’s computational core.
At the base was a Control Unit written in C++ on top of DPDK. This is the kind of low-overhead packet-processing layer Promwad covers in its SPDK & DPDK solutions, where telecom, edge, and 5G workloads need user-space performance instead of the overhead of the standard Linux networking path.
Bypassing the Linux kernel to run packet processing in user space is a well-worn technique in telecom and edge computing, and it fit a workload running tight, repeating cycles. Every 500 µs, the Control Unit pushed a fresh batch of parameters into the client’s 5G L1 datapath and pulled metrics back, with every message serialized to the 5G FAPI standard (SCF 222.10.00). Multiple instances ran in parallel across both ARM and x86 hosts. This layer decided whether the demo held up under live load.
Above it sat a Python/FastAPI backend. It connected to the Control Units over gRPC, coordinated execution across both platforms, routed presenter commands, consolidated metrics from both architectures into a single feed, and streamed everything to the browser over WebSocket.
The top layer was the TypeScript dashboard the audience actually saw: real-time charts comparing ARM and x86 energy efficiency side by side, plus controls letting the presenter adjust workload parameters during the demo. The same demo scenario ran across both ARM and x86 hosts, so the efficiency comparison was visible in real time instead of asserted after the fact.
The delivery approach
A 30-day deadline with two engineering teams building adjacent components leaves no room to work in sequence. What made it work was discipline at the interface.
The FAPI boundary between the demo stack and the client’s datapath got locked before either team wrote production code. With that contract fixed, both sides built in parallel. The external team developed the Control Unit, backend, and baseline dashboard against stubs, validating a stable build on both ARM and x86. As the client’s components matured, the stubs came out and the real datapath went in, first on one architecture, then the other. Only after end-to-end integration did the work shift to locking the on-stage scenario, tuning the visualization for a live audience, and rehearsing on the target hardware.
Coordination stayed light but rigorous: regular working calls with the client’s engineers, each closed out with written follow-ups. When two teams race the same deadline against a shared interface, that’s the only mode that holds.
The result
The live demo ran at the event as planned. The demo made the ARM-vs-x86 efficiency comparison visible under representative workload conditions, with the audience watching the metrics update as parameters changed. The startup walked away with a measured result instead of a promise.
The platform didn’t retire after the show either. It became a reusable demonstration foundation the company still uses as it prepares its next funding round and moves toward dedicated silicon. The work produced a durable asset, not a single-use stage prop. You can read the full breakdown in the 5G edge demo platform case study from Promwad, the engineering team that built the stack.
The broader lesson
If you’re building proof-of-concept platforms in 5G edge infrastructure, the demo is a full-stack engineering problem. A convincing result depends on connecting four things that usually belong to different people: the silicon, the datapath software, the orchestration layer, and the visualization. A weak link in any one of them sinks the credibility of the whole thing.
For semiconductor startups especially, the demo layer can carry as much strategic weight as the core technology. The silicon is the bet. The demo is what lets investors and customers watch the bet pay off in real time, which is what turns interest into commitment. That work deserves the same engineering seriousness as the chip.
Picture Courtesy: Pixabay.com
