Skip navigation

Wired Ethernet

1 Post authored by: ScottD

     At Intel, being a network software engineer in the wired LAN Access Division does not mean that you just write device drivers for our networking silicon. Being a network software engineer at Intel means that you also become what I like to call a "part time electrical engineer".


     When a new silicon project starts up, a small team of network software engineers is assigned to the project.   Each team member gets their network software (device drivers, diagnostic software, etc) ready to be executed on the new silicon by updating their code to meet the new chip specification.   Soon afterwards, the team gets some FPGA (Field Programmable Gate Array) PCIe boards, programmed with RTL (Resistor–Transistor Logic) from our silicon design team.  The FPGA’s job is to execute the RTL code on the PCIe bus to simulate the how the MAC (Media-Access-Control) silicon should operate in the real chip (albeit much slower than the real silicon, since it's a simulation). 


     The software engineering team then executes their network software on the FPGA looking for bugs by running specific tests and performing silicon validation on the FPGA.  Once this is done, our design team fixes fixes and debugs the issues we found in the FPGA and then completes the design.  At this point, a few last minute RTL fixes could come our way that we need to help validate on the FPGA.  The silicon is now ready for the fabrication and is now "taped out" and heads to the Fab to become a "real" piece of silicon.


     Once the silicon is out of the Fab, the software engineering team starts up a new silicon validation effort on the A0 silicon.  This time we not only look for obvious issues in the silicon by monitoring what our software is doing to the actual MAC silicon itself (what I like to call "bit-level debugging"),  but we also execute all sorts crazy tests on the silicon, all in an attempt to make the MAC silicon fail.   We also look for regression bugs that might have crept in from the previous MAC chip silicon generation in to the current chip we are working on. 


     If there are new silicon features on the MAC, the network software engineering team writes special code and devotes extra tests/time in testing the new features to make sure they are working properly and do not actually make the silicon do something it should not.  If issues are found and it is deemed that the MAC silicon cannot ship, the silicon issues are addressed by our designers and a new stepping of the chip is created and the whole SV process is started again. 


     In short, being a network software engineer at Intel means that we not only write the software that makes our silicon connect you to the world, but we also validate the silicon and features that help make that network connection faster and more efficient.  Thus your neighborhood-friendly network software engineer does not just write software, but also validates the silicon is working as it supposed to.

Filter Blog

By date: By tag: