Huawei Technologies Research & Development (UK)
Cambridge
I spent my placement in a CPU architecture research team, working on the hardware and software aspects that go into a processor's design. The team's work is quite broad, overall revolving around CPU microarchitectural design to optimise the software that runs on top of it. My work involved largely three projects. In the first, I built and deployed an internal local AI service: a small cluster of high-performance computers linked by very fast networking, running large language models for in-house usage. Colleagues across the team use this service in their daily work for development. In the second project, I worked on simulation which is a large part of the team's work, simulating the hardware designs to see results. Using a detailed software model of the CPU architecture, I extended it with software models of AI accelerator chips, NPUs, ranging from my own custom design to established open source architectures to an company internal chip. This let me measure activities of a chip which has both a CPU and NPU and their interactions with each other and how it affects peripherals and performance. In my third project, I analysed the microarchitectural activity of the CPU when running a machine learning software stack involving the NPU models I built. I measured what the processor was actually doing at the lower level in simulation, using an industrial analysis method to find where the real bottleneck sits and propose hardware solutions.
I worked mostly independently on research-style projects, with my manager providing direction and review. My contributions fall across the three projects. For the AI service, I set up the cluster from scratch. This involved configuring the high speed network links between the machines, diagnosing and fixing performance faults in that networking, distributing large software images and model files across nodes, and solving many miscellaneous bugs as the models I deployed were all brand new publications and the software support was very flimsy. For the simulation work, I extended a full system simulator with accelerator models and ran a complete image recognition neural network across a simulated CPU and NPU working together. I then used the platform to study how the two compete for shared memory, which is a known bottleneck in chips. I later built a more realistic model based on a commercially deployed accelerator, reflecting how such hardware behaves faithfully rather than a simplified abstract model. For the analysis project, I instrumented the simulator to measure the CPU behaviour running the fully implemented software stack within the simulator and applied a standard industry analysis method to identify the bottleneck, then tested hardware changes against it. Findings were later presented and reports were submitted to stakeholders who raised the problem. Alongside the technical work I presented regularly in weekly team meetings and at a larger internal workshop.
Most of my work was in C++ and Python. A lot of that involved working inside a large existing codebase, where the harder part was understanding how someone else's system fits together before changing anything, but I also had to build things from scratch, including my own accelerator models and the software that drives them. Alongside this I worked in Linux at the system and networking level, set up high speed networking between machines and diagnosed faults in it, and used containers to deploy software across multiple machines and split one large job across several computers that have to cooperate. On the theory side, I read heavily into computer architecture over the placement, covering processor pipelines, memory hierarchies, and how AI accelerators are designed and organised internally, often working directly from formal hardware specifications. I also learned a lot about hardware simulation, both using a large simulator and extending it with new models of my own, and about performance measurement and benchmarking, particularly the structured industry methods for identifying where a bottleneck actually is rather than guessing at it.
Communication was the main area of development. I presented work regularly in weekly team meetings and at a larger internal workshop, which required condensing several months of technical work into a form that colleagues outside the immediate project could follow. Being able to explain findings clearly proved to be as important as producing them, particularly when reporting results to stakeholders who had raised the original problem. The team operates with a fairly flat structure and people are largely trusted to manage their own pace, so the work required a high degree of self direction. Projects were exploratory and often loosely defined at the outset, which meant a significant part of the role was background research, evaluating possible directions, and justifying a chosen approach before committing to it. Managing that ambiguity, and scoping large open ended problems into stages that could actually be delivered, was a substantial part of what I learned. I also developed the habit of documenting work as it progressed, both so that the systems I built remain usable after I leave and so that results could be written up for people not involved day to day.