Journey

As an engineering grad, who wouldn’t be thrilled to land a job at Procsys - one of India’s first embedded systems companies that just celebrated 50 years in the game link. However, my confidence quickly turned to panic as I entered a team of seasoned FPGA and hardware experts who spoke different language altogether.

Being from a CSE background, I suddenly felt as if I had landed on a different planet. I was assigned to a team working on Nios II, a soft core processor within Altera FPGAs. What!! Soft-core Processors? I couldn’t make heads or tails of it. The task assigned was to write a firmware that was supposed to run with Nios-II processor, which itself is a soft-core processor. Buidling and testing my C code would require to build complete hardware design. What!! Even simple C programs took eons to compile. I often found myself pondering with a puzzled look - who would spend hours compiling just a few lines of code?. Does the code get walkie-talkied to the moon and back before building?. Debugging here was out of the question; compiling felt more like wrestling with limited memory. It felt akin to playing Tetris on the lowest difficulty level. ‘It’ll fit, it’ll fit!’ I kept reassuring myself, ‘All is well.’ If I breathe in, will I have room left for declaring variables? I often wondered how many times if this was some parallel universe where CSE was taught all wrong! Recalling my UG days with enough memory to write bloated programs felt like a distant dream, as luxurious as dwelling in Mysore Palace or Abu Dhabi Palace.

Later, I transitioned to different job which involved developing firmware around Arm Cortex-M and application processors and microcontrollers. Initially, it involved developing an embedded Linux application for a ICS (Industry Control Systems) product. With time, As you feel like you have domain-specific expertise in embedded software design, there comes aha! production-level time-bound critical bugs. Time is ticking, seconds matter as the customer waits for the fix, one such thing that gave addreline rush is to figureout some code misfuction in firmware due to bad blocks in flash memory. Further, experiencing bugs related to relialibility was something unique. it can work perfectly when someone wrote it but as soon as they depart company bugs may arrive from same part of code. Oh bugs! Do you reproduce via mitosis when employee leaves the company?

As I delve deeper in the work, it was IOCTLs and linux driver share. Not to forget about cross-compilations. Please guys “you should work together harmoniously!” Cross compiling is just like another compiling process However, the catch was, when it finally finished compiling, I often found myself forgetting what I was even coding in the first place. levelling up next was building embedded linux using old-friend LTIB and newer one Yocto. The struggle of transitioning from simple LTIB to Yocto was real, reminiscent of “bitbaking” for building Linux but also causing some “headscratching” for developers. At one point, I was assigned to implement three-point/five-point touch calibration, only made me stuck and realize that I’m using linear system of equations in a actual product. all that matrix math would actually be useful someday? Boom! .

Next, my fascination started with device identification specifically with intrinsic device identification. It tingled with that research itch. Pursuing a PhD was the next logical step. After all, getting a PhD did bring about many changes in me, But mainly now I tend to hear differently when people mention “PUF”.

Hope you enjoyed!!