Work: Intel Corporation
A sample dependency graph generated for fake FUBs A through E.
As a summer internship following my sophomore year at college (summer 2010), I worked at Intel Corporation for 14 weeks. As the first large sized company (over 80,000 employees) which I've worked for, Intel gave me a whole new feel for the corporate workplace. When I began my internship in the middle of May, my mentor was away so I began working on a few simple coding assignments in Perl and Java as a refresher to get back up to speed. After I finished the assessments and familiarized myself with some of the Intel software and documentation, which was not even two weeks into my internship, I was working on my real project for the summer: a wrapper utility to provide automated FUB validation.
Before I go into the details of the design or functionality of my project, here is a little bit of background information. Everything in a chip falls somewhere in the structural heirarchy; a full chip contains sections, a section contains FUBs (functional unit blocks), etc. Before a full chip can get printed in silicon (but after it's been designed), many characteristics need to be checked. For instance, the power, timing, noise, and electric properties of each block need to be checked to ensure that, even though the chip works fine on a computer, the circuit will work when fabricated into real hardware. As you would imagine, Intel has already created, tested, and optimized tools to perform each of these validation checks. My job, however, was to efficiently automate the process.
Based on the physical layout of the chip itself, certiain FUBs depend on other FUBs; sometimes one FUB needs to be successfully validated strictly before another FUB starts its validation. Given a database which contained this dependency information, my first job was to come up with a perl utility which generated the optimal scheduling pattern, submitted the validation jobs, and provided intuitive, periodic status updates. To come up with the most efficient job submission algorithm, I looked at the bottom-up depth of each of the nodes instead of the traditional top-down approach. Next, I developed a GUI program using javax.swing compatible with the existing GUI flow manager which Intel was using to perform all of the same functions without having to resort to the command-line. Lastly, I deveoped an extensive regression testing system with about 80% code coverage.
All in all, I authored 3595 lines of perl and 6104 lines of Java while working for Intel during the Summer of 2010. More than that, I learned a tremendous amount about work in a large organization, work practices at Intel, and other life skills which I can't express in "lines of code."
