OttoBot: Automation for PVT
Before I arrived at Xilinx, there was a contractor who created an automation script and corresponding driver wrappers in python. This was called Otto, and it was a mess. The driver wrappers were nicely written (using a few open source libraries and only pulling out necessary functionality), but the automation script itself was a wreck. There were static variables all throughout the code; it was 800 lines in a single file; it had to be changed every time a new part was being tested; it was obfuscated, and there was no trace of best practices. So, after reading through and understanding how the automation worked, and learning the ins and outs of running parts through PVT (process voltage temperature), I deleted the script, worked a little on the drivers (which I kept as "Otto"), and started working on OttoBot. OttoBot is an organized, expandable, unit tested system for running TCL tests. It utilizes the driers in Otto to set temperature, set frequency, and communicate with Vivado, and it uses an internally-built module to set the voltage for the characterization board. All the user has to do is set the parameters (like which temperatures, voltages, etc.) in the YAML preference files, and run the master script. This generates a CSV file, and can use OttoMotivE (below) to generate an Excel report with part statuses.
Ethernet MAC + Interlaken COE
About My Team
My team was the COE for Ethernet MAC and Interlaken hard blocks on Xilinx's FPGAs. Here's a terminology update since I didn't know what a COE, Interlaken, or hard block meant when I arrived.
IP (Intellectual Property) := anything for which we don't have a name. Honestly, this is used because saying "the thing" sounds less professional than saying "the IP".
COE (Center of Excellence) := the main point of contact for a certain domain (at Xilinx, that domain is usually some kind of circuitry, some system, or some IP)
Ethernet MAC (Media/Medium Access Control) := MAC is a protocol that is part of the hierarchy used to communicate over a network.
Interlaken := A chip-to-chip protocol that has low latency, is very lightweight, and is more reliable, but less detailed than other protocols (like MAC). This is mainly used to communicate between two chips in a single system over a relatively short medium where identity isn't as important.
Hard Block := Logic that is implemented in circuitry. Because FPGAs are programmable, one can replicate almost any logic in the fabric (the programmable part); however, when Xilinx has many customers that want specific functionality, that functionality is "hardened". Hardening is the process of taking logic that was once implemented with software in the fabric and implementing it in physical circuitry on the FPGA. Hardening soft logic creates "hard blocks" of functionality.
OttoMotivE: Automation for Reporting
Once completing OttoBot, I realized that there was a need to translate, parse, and combine the hundreds of tests that are run into a coherent status sheet for the other engineers on my team. So, I used a combination of VBA Modules (packaged in custom Add-Ins) and a python script to take the CSV file output from Otto, generate a part workbook that houses all test results, and parse these test results for passing modes under the given voltages, temperatures, & frequencies.
Test Block Implementation: RTL
Apologies for the obfuscation in the next paragraph--this test block's workings are Xilinx Internal information. I was given an assignment to connect our hard block to a test block in RTL. This required writing System Verilog (a language that I hadn't seen before), using Vivado (a program I had never used before), and debugging functionality (that I had no experience with). It was probably the most challenging and most fun thing that I did in my internship.
Verification and Characterization (VnC): Performing PVT on Development Part
Part of my team's job is running parts through PVT, which was the goal of the automation that I developed (see OttoBot). To run these parts through PVT, we put the part in a characterization board, connect that board to clock generators, a thermal head, and voltage programmer, and then set the various conditions to run over the parts. It turns out that working in the lab requires quite a bit more debugging than you would expect. Something should take a day? Make that a week, because the clocks are going to break, and then there's going to be some strange error when you try to program the part, and then you'll find out that those tests that you ran were at the default voltage instead of the one you meant to test, and so on and so forth. Things just go wrong, and that's what being an engineer is all about!
I got to hear and ask questions to the CEO, and the Engineering SVP--if the Xilinx I experienced was the one they saw, I would think it's everyone's dream workplace. Needless to say, the job of the CEO/SVP is to sell the company, so of course they see it like that. What I saw was an old company that is doing some cool things, and possibly has some very interesting work in and around the corners. I firmly believe that there is a place within Xilinx that I would fit very well and a team that I would be doing the kind of bleeding-edge, fast-paced, perfection-requiring work that I'm seeking. That wasn't what I did in the summer of 2016, but we'll see what happens in the future. I'm pretty sure I'll be back eventually--thanks, Xilinx. It was good.
I met some great people, gained some invaluable knowledge, and got to work at a cool company doing some pretty cool things. Is it perfect? No of course not, but it's interesting.