Qualcomm · Summer 2026 · Internship · Wireless R&D
Modem Data Infrastructure
Roughly 70 end-to-end data-path cases automated, and driver work no longer blocked on board availability.
Written at the level of public, upstream Linux interfaces. Qualcomm's internal architecture, implementation, customers and metrics are deliberately left out, and nothing here goes beyond what my résumé states.
~70
end-to-end cases automated
no silicon
needed to exercise the driver
1 file
declares every test topology
Background
Context
Qualcomm's modem software teams own the path a packet takes between the modem and the Linux host. Three pieces of that path are public and upstream, and they are the ones I worked against: RMNET, the network-interface layer on the host; IPA, the IP accelerator that moves and transforms packets; and QMI, the control protocol used to talk to the modem. All three have open-source kernel implementations, which is the level this page stays at.
Over summer 2026 I was the only intern on the team, responsible for the developer tooling around that path.
Constraint
The hard part
Driver work was gated on physical hardware. If the board you needed was not free, you waited.
A large share of end-to-end checking was done by hand, which made it slow and hard to reproduce exactly.
Carrier customers needed to configure tunnelling without programming the accelerator directly, which otherwise assumed deep familiarity with it.
Ownership
What I was responsible for
I owned the developer tooling for this path across RMNET, IPA and QMI. There was no other intern on it and no hand-off document, so reading my way into a large codebase was part of the job.
Concretely I built three things: a C SDK and CLI, a hardware emulation layer, and a Python test orchestrator. I also set how the team handled AI-assisted development.
System
Architecture and flow
The shape of the idea matters more than the wiring. Driver code normally talks to real hardware. If you can stand something else in at that boundary, the same unmodified driver code can run on an ordinary machine, and the parts that usually break still get exercised.
The same driver code, two backings
on hardware
boundary
scarce, shared, slow to get
in emulation
boundary
any laptop, seconds per run
The same driver code, two backings. Swapping what sits below the boundary is what removes the hardware dependency.
Decisions
Key technical decisions
1
Put an SDK in front of the hardware.
Customers should be able to express what they want, a tunnel of a given type, rather than how the accelerator achieves it. The C SDK owns that translation and the CLI on top lets people drive the same paths without linking against anything. The interface is the deliverable: it stays stable while everything underneath is free to change.
2
Emulate at the narrowest boundary.
Standing in for hardware is only useful if the code above it is untouched. Choosing the narrowest seam between driver and hardware kept the emulation small and kept the code under test real. Emulating higher up would have been easier to write and would have exercised far less of what actually fails.
3
Make the topology data, not code.
The orchestrator reads a declarative topology file rather than a script per machine. Each setup is described once and the same suite runs against any of them, so extending coverage means adding an entry, not writing another script.
4
Treat AI output as a draft, not a result.
I wrote the repository's conventions and verification criteria down, then used AI to parallelise implementation across the tooling while checking its output independently against those criteria. The point was the gate, not the speed: generated diffs fail in ways that look plausible, so they need reading before review, not after.
Failure
Reliability and failure handling
- Initialization regressions surface in emulation, in seconds, on a laptop, before anyone spends time on hardware.
- Every orchestrated case runs the same way from the same declared topology, so a result is reproducible rather than dependent on who ran it.
- The verification step on AI-assisted work is a pre-review gate, not a replacement for review.
Outcome
Measured outcome
~70
end-to-end cases automated
no silicon
needed to exercise the driver
1 file
declares every test topology
- Driver work no longer waits on board availability.
- Tunnel configuration moved from direct accelerator programming to a stable SDK and CLI.
- Checking that had been manual became a suite anyone could re-run.
Learned
What I took from it
The most useful decision was which boundary to emulate. Picking the narrowest seam between the code and its dependency meant the stand-in was small and the code under test stayed real. I now look for that seam first in anything I have to test without its dependencies.
I also learned that tooling gets adopted when it encodes how a team already works, in the files they already read, rather than asking them to change habits for it.