Projects
Projects run two to four weeks part-time and end in a review call with an experienced engineer. The review is the credential — not a certificate of attendance.
Every project states its context, its brief, the milestones you are expected to hit, what you hand over, and how it is reviewed. Scoring is 0–3 across five criteria — correctness against the brief, evidence quality, design trade-offs stated, reproducibility and written communication — and a project passes at 70% with no zero on any criterion.
CAP-01 · Packet Path Report
1 week
An engineer must explain a latency symptom to a non-network team.
Choose one request path on a Linux host. Trace it end to end with eBPF and counters. Quantify each stage. Identify the one stage you would change first.
Milestones: (1) Topology and tooling set up; (2) trace collected; (3) stages quantified; (4) report.
You leave withTrace data, scripts, a 4-page report with one diagram.
Review: Can the reviewer reproduce the trace from the report?
CAP-02 · Programmable Load Balancer on DPDK
3 weeks
A service needs a layer-4 balancer that can change its algorithm at runtime.
Build a DPDK balancer with consistent hashing, health checks, and runtime reconfiguration. Target rate and packet sizes are set by the reviewer.
Milestones: (1) forwarding path; (2) hashing and health checks; (3) live reconfiguration with no flow reset for unchanged backends; (4) benchmark and report.
You leave withSource, test suite, benchmark report with variance.
Review: Reconfiguration test under load: no unintended flow resets.
CAP-03 · MPI Application Benchmark and Tuning
3 weeks
A research team's MPI job runs slower on the RoCEv2 fabric than on the old InfiniBand cluster.
Benchmark the application's communication, find the dominant pattern, tune transport and collective choices, and report the gain with its uncertainty.
Milestones: (1) baseline with OSU and the application; (2) pattern analysis; (3) tuning experiments; (4) report.
You leave withBenchmark scripts, before-and-after table, a recommendation with risks.
Review: Are the claimed gains statistically supported?
CAP-04 · Multi-Cluster Mesh with Policy
3 weeks
Two clusters must share three services. Only named flows may cross, all encrypted, all observable.
Build the mesh, the policy, and the SLA dashboard. Show a denied flow and an allowed flow.
Milestones: (1) two clusters and the mesh; (2) policy with default-deny; (3) cross-cluster with mTLS; (4) dashboard and failure test.
You leave withManifests, test suite, dashboard, runbook.
Review: Failure test: a broken route is found from the dashboard within the stated window.
CAP-05 · Security Gateway Design with Compliance Map
2 weeks
A regulated customer needs an access gateway for internal APIs.
Write the design: policy decision and enforcement points, data path, performance budget, and a control-to-regulation map for two clauses.
Milestones: (1) architecture; (2) policy tests; (3) performance budget with measurements; (4) compliance map.
You leave withDesign document, policy test suite, compliance map.
Review: Can the reviewer trace each control to a test and a clause?
CAP-06 · Telemetry-Driven Test Pipeline
2 weeks
A team's network changes ship without automated performance checks.
Build a pipeline: traffic test, metrics collection, regression detection, and a promotion gate.
Milestones: (1) traffic test scripted; (2) metrics stored; (3) regression detector; (4) gate and report.
You leave withPipeline code, a seeded-regression demo, report template.
Review: Seeded regression blocked; clean run promoted.
CAP-07 · Offload Plan with Measured Gains
3 weeks
Management asks whether a virtual switch should move to a SmartNIC or DPU.
Baseline the host, measure the offload on the same workload, decide, and state the workload where offload loses.
Milestones: (1) baseline; (2) offload measured; (3) decision and failure cases; (4) plan for rollout.
You leave withMeasurement data, decision record, rollout plan.
Review: Is the decision justified by the numbers, including the losing case?
CAP-08 · Mini User-Plane Function
4 weeks
A private 5G network needs a user plane for one site.
Implement tunnel forwarding, charging records, and one slice with a latency budget.
Milestones: (1) forwarding; (2) charging; (3) slice; (4) failure recovery.
You leave withSource, tests, latency results, failure report.
Review: Slice latency under load; session recovery time.
CAP-09 · Converged Network Architecture Review
2 weeks
A hyperconverged rack is being designed for storage and compute.
Write the design: topology, oversubscription, lossless classes, high availability, and failure cases. Defend it in a review.
Milestones: (1) requirements; (2) topology and sizing; (3) failure analysis; (4) review.
You leave withDesign document with a failure table.
Review: Defended against two alternatives.
CAP-10 · Congestion-Control Experiment
2 weeks
A video service stalls on mobile links.
Compare two congestion-control approaches on a defined profile with statistics. Recommend one, with its risks.
Milestones: (1) profile; (2) experiment design; (3) runs and analysis; (4) recommendation.
You leave withScripts, data, chart, recommendation.
Review: Is the difference statistically stated, and is the profile realistic?
CAP-11 · Self-Checking FIFO with Clock-Domain Crossing
2 weeks
A block must pass data between two clocks at unknown ratios.
Implement the FIFO with Gray-coded pointers. Verify with a self-checking testbench across three clock ratios.
Milestones: (1) RTL; (2) testbench with reference model; (3) randomized and corner-case tests; (4) synthesis check.
You leave withRTL, testbench, coverage report, synthesis report.
Review: No lost or duplicated data at any ratio; no unintended latches.
CAP-12 · CRC-Checked Packet Ingress Block
2 weeks
A NIC team needs line-rate CRC checking on ingress.
Implement parallel CRC, prove equivalence with serial, add statistics, and integrate with captured traffic.
Milestones: (1) CRC equivalence; (2) ingress with backpressure; (3) statistics; (4) integration.
You leave withRTL, testbench, integration report.
Review: Integration results match the RTL on captured frames.
CAP-13 · DDoS Scrubber with Metrics
3 weeks
An edge service needs volumetric attack filtering with visibility.
Build an XDP scrubber with rate limits, counters exported to user space, and a dashboard.
Milestones: (1) drop path; (2) rate limits; (3) metrics; (4) attack simulation.
You leave withSource, attack simulation, dashboard.
Review: Legitimate traffic loss under attack is within the stated limit.
CAP-14 · RDMA Key-Value Store
3 weeks
A cache needs remote reads without server CPU in the path.
Build a client and server with RDMA reads for gets, and atomics for a shared counter.
Milestones: (1) connection setup; (2) reads and writes; (3) atomics; (4) benchmark.
You leave withSource, benchmark, failure handling notes.
Review: Correct under concurrent writers; benchmark with variance.
CAP-15 · RDMA vs TCP Storage Benchmark
2 weeks
A storage team asks whether RDMA is worth the operational cost.
Benchmark small-block latency, large-block throughput, and CPU per gigabyte, with and without RDMA. Recommend.
Milestones: (1) environment; (2) benchmarks; (3) CPU analysis; (4) recommendation.
You leave withData, charts, recommendation with operational cost.
Review: Operational cost is addressed, not only performance.
CAP-16 · GPU Communication Optimization Study
3 weeks
A training job spends too long in all-reduce.
Profile the communication, change one thing at a time, and measure each change.
Milestones: (1) profile; (2) changes with measurements; (3) combined result; (4) report.
You leave withProfiles, before-and-after tables, report.
Review: Each change is attributed correctly.
CAP-17 · SR-IOV Deployment Runbook
2 weeks
A cloud team needs SR-IOV on a new platform, and the runbook must be followable by an engineer who did not build it.
Write and test the runbook: create virtual functions, assign them, verify, and roll back.
Milestones: (1) lab build; (2) runbook draft; (3) cold test by a second engineer; (4) final.
You leave withRunbook, verification script, cold-test report.
Review: The cold test passes without help.
CAP-18 · 8-Bit ALU with Self-Checking Testbench
1 week
First RTL project for the digital track, reviewed to professional standard.
Implement the ALU with a defined operation set, flags, and a reference-model testbench.
Milestones: (1) RTL; (2) testbench; (3) synthesis check.
You leave withRTL, testbench, synthesis report.
Review: Testbench catches a seeded bug.
CAP-19 · Synthesis Cleanup
1 week
A module failed review for latches and simulation mismatch.
Fix the module, prove it with a testbench, and list the five fixes with their rules.
Milestones: (1) defect list; (2) testbench; (3) fixes; (4) report.
You leave withFixed RTL, testbench, change list.
Review: Each fix tied to a rule.
CAP-20 · Application Project: Traffic Light or Frequency Meter
2 weeks
A complete small controller for review.
Design, implement, and test a controller with timing requirements and a demo.
Milestones: (1) specification; (2) RTL; (3) testbench; (4) demo.
You leave withSpecification, RTL, testbench, demo recording.
Review: Timing requirements met in simulation.
CAP-21 · FSM Controller with a Data Path
2 weeks
A serial sensor sends 16-bit words. The count of ones must be computed in hardware, and a controller must sequence the count.
Build an FSM controller that drives a 16-bit ones counter. It starts on a request, samples the word, raises a one-cycle done pulse, and ignores new requests while busy. Choose the state encoding for a stated clock target, and justify Moore or Mealy for each output.
Milestones: (1) specification and state diagram; (2) RTL in three blocks with no latch warnings; (3) testbench with a reference model and one seeded bug; (4) encoding comparison with flip-flop and frequency data.
You leave withRTL, testbench, state diagram, encoding comparison table, one-page design note.
Review: The seeded bug is caught; each output's Moore or Mealy choice is justified; no unintended latches.
CAP-22 · Timing and Area Closure for an 8-bit ALU
2 weeks
An eight-bit ALU with eleven operations misses its clock target in review, and its area budget is tight.
Implement the ALU with one shared adder and a multiplexer tree, with registered inputs and outputs. Compute the register-to-register budget, find the critical path in the timing report, and close the target by reducing logic depth or adding one pipeline stage. Report the area before and after.
Milestones: (1) datapath and test vectors for all eleven operations; (2) timing budget predicted from the report; (3) closure, one change at a time, each measured; (4) area and latency report.
You leave withRTL, testbench with vectors, timing table, area table, change list with the rule behind each change.
Review: The predicted frequency is within 10% of the reported one; every change is tied to a measured effect.