Do We Need A “Glue” Engineer?

Design and verification are so complex today and fraught with market risk that it keeps managers awake and sweating at night.

So much of design is carved up in IP blocks and subsystems, each with their own verification issues and methodologies. To manage the complexity the design is partitioned, and so too are the teams. But as software verification becomes more crucial to system-design success, the specialization means there are few if any engineers with a view of the entire design verification challenges.

How do we as an industry address that?

Super Man
The answer, it would seem, would be a “super engineer,” a managing director of sorts who oversees and understands the implications of all aspects of the design and can arbitrate disputes. But that glue engineer—as panelists at the recent DVCon 2014 called him or her—doesn’t really exist today.

At a very simple level, it’s not uncommon for members of a given company’s hardware and software design or verification teams to meet and exchange business cards, quipped Cadence’s group director for product marketing of the System Development Suite Frank Schirrmeister, who spoke on Semiconductor Engineering Editor Ed Sperling’s DVCon panel on March 5.

“Do we need a new generation of engineer? A new person who is deep enough to do both (hardware and software verification) because I don’t see the software guys moving… and I don’t see the hardware guys (moving) because they’re both so busy, they’re focusing on their individual problems.”

Krishna Yarlagadda, president of Imagination Technologies and a veteran of Sparc microprocessor development in the 1980s, knows the problem well. He spoke about it during an interview at Cadence’s CDN Live event a week after DVCon 2014:

“It is a problem, and people are realizing that because they’ve paid a price for it. They are still organizations that are that way (hw/sw chasm). Where is this going? How is it going? I think the people are changing. We’re working with more EDA companies and optimizing technology with foundry partners over time so these problems do not show up. We all have to collaborate in a proper way to make this work.”

Ken Knowlson, principal engineer at Intel, has a ringside view to the challenges:

“What I’d like to think are systems engineers … are more like ‘glue’ engineers. The glue is to know enough about the specific firmware to take it and modify it and work with the design guys. I can get the architects early, but getting people who actually know the code to participate early enough? It’s always going to be a challenge.”

One attempt at glue
But Sandeep Pendharkar, vice president and head of product engineering at Vayavya Labs, who participated on the DVCon verification panel with Knowlson, Schirrmeister and others, suggests progress is being made:

“Some customers take a pragmatic approach. One of the gentlemen with whom I’ve been talking has actually hired three software engineers to be part of the design verification team. All that these software engineers do is they just write device driver code in C. The verification engineers then sit with them to understand it and, if required, create an equivalent System Verilog for that side of things.”

In many ways the onus for managing this problem may fall to EDA vendors, according to Schirrmeister.

That “glue person” needs to “know enough about both sides to be dangerous and to challenge a bluff from the hardware or software side that it’s not their problem. But we as EDA vendors need to provide the environment that you can do that efficiently from both sides,” Schirrmeister added.

There’s a constant tension (and often a skew) between technological innovation and how human engineering teams evolve to leverage and embrace what they’ve invented. That’s part of what makes engineering so fun to follow.

Whether universities are altering curricula sufficiently to nurture a new breed of engineer is unclear. But it’s clear that as we move up the abstraction ladder in design, our engineering vision is going to have move in lock step.