The role of engineers is changing, and they need to be picking up new skills if they are to remain valuable team players. There are several directions they could go in.
Engineering has one constant — you innovate or fall by the wayside. That is true both for the things that are designed and for the engineers who design and build them. Today’s systems are putting new strains on engineers who can no longer be “tall and thin” or “short and fat.” Those descriptions pertain to an engineer who is either highly specialized or one who has much broader experience.
The notions of tall, thin engineers came about in the 1980s. Before then, an engineer, mostly printed circuit board (PCB) designs in those times, would design the logic and lay out the PCB. But as semiconductor design started to take over, the separation of the front end and back end allowed a greater degree of specialization and with it, a deeper level of expertise. This in part was forced upon users because of separate tooling that was becoming highly specialized.
As this notion continued, silos were created within the development teams, and this worked well for a while. Divide and conquer helped solve many problems and enabled academia to make rapid progress in the necessary technology to speed progress. “Academia is not very good at the interdisciplinary stuff,” said Charlie Munger, vice chairman of Berkshire Hathaway, in an interview he gave at CalTech. “Academia rewards a researcher who knows more and more about less and less, and there are real difficulties with that approach.”
The first chinks in this strategy started to become apparent as early as the ’90s, when back-end physical effects started to impact front-end logic synthesis. Today, we are rapidly approaching the point, thanks in part to shift left, where all major aspects of design are ideally done at the same point in time. To expect that to be done by a single person is not possible.
“A new profile of design engineer is needed — a system designer who can take a high-level overview of the system as a whole,” says Anna Fontanelli, founder and CEO for MZ Technologies. “Specialists will still be required to work on their specific area of expertise, but what is needed now is a team of designers to take on the challenge of system design.”
Others agree. “Teams need key architects who have deep experience in all areas,” says Simon Davidmann, CEO of Imperas Software. “We are not generalizing engineers. It’s bringing together more specialists.”
That group of experts, each with a particular focus, then can take their field of expertise through the development flow. Many call these solution experts. Examples include power experts, safety experts, security experts, verification experts.
“Generalists are not effective,” says Michal Siwinski, corporate vice president for market and business development at Cadence. “Specialists have changed from being point tool specialists, to being application or flow specialists. They are still specialists, but they are becoming broad specialists. It’s not somebody who can tell you everything about everything.”
Architects are the ones often thought to be the necessary generalists. “Every individual will have a preference,” says Johannes Stahl, senior director of product marketing at Synopsys. “Some people like to be generalists, and they like to think very broadly. Some people want to be deep. It often comes with seniority. The more senior you are and the longer you have been in the business, you’ll naturally diversify your knowledge base. We still need the combination of the specialists and generalists, but you can’t simultaneously be deep and broad.”
There are competitive advantages to having deep knowledge in a particular area. “Specialists often drive the differentiation that you’re going to deliver in your end product,” says Shekhar Kapoor, director of marketing at Synopsys. “Consider an implementation engineer. They need to know how sign-off technologies work and how to use them in implementation. Their focus is on implementation corners, looking across the scenarios, across the modes of operations, and they can do a much more exhaustive job. But doing this becomes more expensive if left until the implementation stage. So the role has transformed. But you still need a specialist who can do much more fine-grained job of sign-off analysis.”
Increasingly, there are areas of cross-specialization. Verification intersects all flows, and increasingly power and security are becoming cross concerns. Ankur Gupta, senior director for semiconductor product management and applications at Ansys, provides three examples where engineers are being stretched into multiple physics domains:
Intersecting domain specialists
All teams need domain specialists. People who understand what is being created and how it is intended to be used. “Having the ability to develop something custom requires specific domain knowledge,” says Synopsys’ Kapoor. “They can develop customized accelerators targeted towards these domains. You need somebody who can bring that knowledge. And that’s a special aspect of knowledge.”
In some cases, the domain has to be crossed with a specific task. “Consider functional safety in automotive,” says Cadence’s Siwinski. “It’s not about a specific point tool. You still have experts who are safety experts, but they’re doing it across products. That’s the only way to solve the problem.”
RISC-V is creating a new domain crossing that is still evolving. “Every customer has a slightly different way of describing how their pipeline works, and how the interrupts affect retired instructions,” says Davidmann. There is a lot of functionality, which is legal in RISC-V, and what you’re trying to find is the illegal stuff when doing design verification. We can’t just throw a tool over the wall to them because there are no standards for the interfaces that they need. You need information about the detailed events that are going on in the microarchitecture, and abstract that to the point where you can compare that with a configured reference model of the standard. We have to understand and get very entrenched into what our customers are doing.”
Verification is getting entangled into everything. “You begin to see people who are architects of systems, or architects of verification strategies, or architects of defining the optimum packaging,” says Ravi Subramanian, vice president and general manager of the IC Verification Solutions Division of Mentor, a Siemens Business. “You begin to see experts in these areas who come with a cross disciplinary background. They are an expert at the intersection of domains, not necessarily the expert in a particular domain.”
“They have to have an appreciation for their colleague’s roles and responsibilities,” says Pat Sheridan, product marketing senior staff for virtual prototyping at Synopsys. “As they move to new technologies with their products, those relationships need to grow or change. The collaboration needs to grow and change. So, engineers do become more generally knowledgeable about the flow, but I think the focus can still be on their part of the team. What is their responsibility in the team? The more they can do this effectively and efficiently, the faster their projects can go and the less hiccups they are going to have. It’s really a matter of appreciation and teamwork.”
Teamwork appears to be key. “At the very least, specialist designers must take steps to consult experts and not just continue to optimize for traditional and siloed constraints,” says Ansys’ Gupta. “An example of such an advisor is a system power architect who considers the overall power and thermal envelope to which the design must adhere. This is essential for emerging 2.5D/3D-ICs, where on-die power integrity, signal integrity, and thermal effects couple closely with package and board. Another example is a chip security architect who builds a simulation methodology to test for side-channel emissions throughout the design hardening process.”
Power and security are two domains that are becoming closely linked. “People come together to try and work out how to solve or understand the power envelopes early on,” says Davidmann. “Security brings a whole new layer of complexity to this. By using a simulator to do power analysis, they’re trying to measure the power profiles of certain programs. And then they try to foil an attack by changing some aspects so that you can’t monitor the power to find a way to break in using that security vulnerability.”
EDA’s role
The EDA industry plays an interesting role in that they created the tools that originally defined the silos and are now finding ways to break them back down. “Open and extensible tools and platforms are needed to address the complexities of electronic system design,” says Gupta. “This is often counter to the single-vendor, proprietary-system, non-standards-based flows that some EDA vendors have been pursuing. Tools alone are not sufficient, as the complexity and nuance of each customer’s needs are deep and varied.”
The role of application engineers within EDA also has changed. “Application engineers used to be point tool engineers,” says Siwinski. “Now they come in two flavors. Point tool experts are still essential. But most of them are cross trained with all the other tools that somebody would use within verification, or in digital or analog for example. Then there is another layer that is really more solution engineering. They are looking at it much more from a flow perspective. Sometimes, they may be a little bit more vertical-centric, but mostly it is around specific major horizontal flows.”
The impact is significant. “It is absolutely transformational,” says Mentor’s Subramanian. “You need to bring in domain knowledge coupled with knowledge about what’s going on with silicon, or what’s going on in functional safety, or what’s going on for doing power analysis of software workloads. AEs begin to develop a portfolio of knowledge that becomes important to be successful. Continuous education and enhancement and improvement of the skill set to address this new need is happening right now.”
That education can happen at multiple levels. “Designers must start learning from the system or security gurus within their organizations,” says Gupta. “Engineering requires constant education, especially in ever-changing semiconductor and electronics field. As an EDA vendor, we had to cross-train our own engineers from chip and system backgrounds to bust silos. In this COVID-19 world, one silver lining is that we have all developed excellent educational curriculums and spent time to advance our knowledge. Virtual trainings tend to attract hundreds of users, and I am confident in our collective ability to develop the necessary skills.”
It is not only changing the skill sets of the AEs. In many cases, it’s transforming how the companies are structured. “If you look at EDA companies today and compare that to how we will look 5 or 10 years from now, you will see how big a transformation it is,” says Subramanian. “We have to demonstrate the value of the product by making customers successful.”
Conclusion
The role of engineers is changing. While it is generally accepted that they need to stay focused and have defined specialties, there is an increasing need to be aware of the intersection points they have with other specialties. That will become increasingly difficult as the number of intersection points grow. Verification perhaps will have the toughest problem because engineers already had touch points to many other areas, and responsibilities for things like power verification or safety verification have become divided across the specialties.
Related
Engineering Talent Shortage Now Top Risk Factor
New market opportunities and global competitiveness are limited by qualified people.
Jobs Board Semiconductor Industry
Looking for a job? Check out our new engineering jobs board
Test Engineers In Very Short Supply
Why these jobs are so difficult to fill.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
This is a very apt article for everyone in IC design and EDA. I would urge EDA to integrate point tools like synthesis, PnR, STA, IR-drop etc. into a common design environment ; point tools for each function is days-of-the-past, we need a common design enviroment (analogy Android OS) where each design function operates with common database, common engines, common UI, standard reporting. The silos and walls in design teams was partly induced by EDA tools.