Arm
Cambridge
Joined the Solutions Engineering business unit at Arm as an FPGA engineering intern. Worked on integration of an Ethernet-oriented subsystem into an FPGA prototyping platform, for enablement of external software testing and connectivity. Gained experience across the full FPGA prototyping flow, from RTL design and verification through compilation, system integration and finally validation on physical hardware (FPGAs). The project extended from a proof-of-concept to full Ethernet connectivity, through refactorisation of RTL, changes and adaptation to FPGA clocking infrastructure and hardware bring-up. Also contributed to another team, working on improving the CI flow for a different FPGA prototyping team - gaining exposure to a software-oriented part of the team. Overall, the placement provided a broader understanding of the entire system architecture of which the FPGA teams are working on, rather than just working on RTL design and verification in isolation.
Developed custom SystemVerilog RTL to convert between wide XLGMII and narrower XGMII datapaths, with behaviour following industry-standard IEEE semantics. Integrated the RTL to develop a custom IP subsystem, with partner IP from AMD. Developed and maintained verification environments, including testbenches, test sets, as well as using assertions and coverage in VCS. Exercised thorough functional verification on the subsystem. Generalised the RTL and developed scripting to enable regression testing. The feature is now available as an integration, where others can integrate it into their own FPGA prototyping projects - guided by clear written-up documentation. Debugged and refactored the subsystem where necessary to achieve a complete build with external-facing Ethernet connectivity. Through this, familiarity with partitioning designs between FPGAs and investigation with complex clocking and reset issues was crucial to understand. From this, novel changes were made to deal with reset signals propagated between FPGAs - resolving timing violations. For hardware bring-up, validation was done through a Linux software environment, exercising transmit and receive datapaths and monitoring traffic at the subsystem interface.
I used SystemVerilog and principles of RTL design to develop and refactor hardware modules for FPGA prototyping and custom IP development. Furthermore, I had to leverage design principles related to asynchronous logic (FIFOs and data conversion), in particular clock domain crossing, as well as understanding industry-standard data- and control-path logic. In addition, I developed a test environment in which testbenches, assertions and coverage could be used to test and simulate the behaviour of the subsystem I developed. VCS was used to regression test and exercise different data payloads to ensure that the RTL was robust to all proposed usecases. Functional verification discovered RTL bugs, prompting the improvement of the code implementations. The project isn't as trivial as understanding how to write RTL, as considering the implications of applying the subsystem to FPGAs, which have implementation and physical constraints, was important. Within the placement, I gained experience with partitioning designs across multiple FPGAs, optimising logic and congestion for utmost best system performance. Thinking from a system-level perspective to solve problems was something I developed.
I developed my independent problem solving, through investigation of issues in a systematic manner before approaching and communicating ideas with experience engineers, for guidance on issues. My communication skills were used on a day-to-day basis, through scheduled meetings and presentations, in which my work is demonstrated to the entire FPGA team - also showing ownership and initiative. Documentation was practised throughout, keeping clear track of progress through assigned tickets and well-maintained pages documenting my work. The technical level to which my work is explained varied between top-level, simplified explanations (targeting less technical audiences), all the way to deep detail - where code extracts and low-level diagrams are often used. Feedback drove my progress, so getting comfortable asking for feedback was crucial, either verbally or through code reviews - suggestions from senior engineers improved my quality and maintainability of work, and engineering practises. This links heavily to collaboration, where I worked daily with a vast number of different engineers, not just in my team, but with others who are related in the bring-up and usage of my project.