It’s Time To Talk…

It’s bad enough that hardware engineers can’t explain what they do to other people outside of their world, but increasingly they can’t explain it outside of their narrow slice of an SoC. Engineers routinely introduce themselves as scientists, teachers, handymen, consultants, and occasionally even as arms dealers.

The problem is that the tasks they handle are so complex and intertwined  that explaining a particular slice of a complex SoC development takes far too long and other people lose interest. That’s indicative of just how complex the SoC ecosystem has become. At first it was simply design engineers and the verification teams working to build chips. Then it moved to architects and software engineers. And finally, power experts were brought in to somehow establish ties across all of these groups because power was considered important when mobile devices had to be plugged in every couple hours.

Initially, these people didn’t even speak the same language. Communication across disciplines has improved since then, but because of the need to understand what’s going on with manufacturability, testability, reliability, and software bug fixes after products are released in the market, the communications circle has grown even larger. And to make matters worse, the looming push into stacked die, fan-outs and the increase in third-party IP will force business changes that require engineers—or at least engineering managers—to now sit at the same table with the finance people who understand how costs will need to be re-apportioned across companies to break down silos and build up new ones.

There is no lexicon that spans every group. No matter how hard groups try, sometimes the same exact words are translated differently by different disciplines. And the emphasis of each group may be radically different, depending upon what they’re trying to accomplish. In software, the amount of time and coding just to get an application or firmware or operating system function is enormous. Taking advantage of complex power management schemes inside the hardware has always been a secondary consideration—and a major complaint by hardware teams.

A new wrinkle in all of this is the role of the foundries, which in the past fixed a lot of design problems. Increasingly they’re throwing the problems and the risk back to the design teams because it’s too complex for them to solve. That requires more back and forth discussion, which makes it even harder to classify where one job ends and another begins.

So what exactly do you call yourself? EE doesn’t explain enough. Software or hardware engineer doesn’t take into account the interaction. Verification engineering is done at every step of the design to manufacturing flow. Systems engineer is too vague. RTL engineer is too narrow. Global ecosystem contributor is to broad. And computer science engineer doesn’t come close to fitting the bill. How about code warrior?