Masters Of Abstraction

Good system designers are a unique breed. While it’s easy enough to distinguish the traits that define a good one from a weak one, it’s much harder to determine who possesses those traits before they are put to the test, or whether or how they can be taught.

However, there is definitely a particular perspective that good system designers hold in common. The key is the ability to work with many different levels of abstraction that go into a system, starting at the transistor level.

“Good system designers are masters of abstraction,” said Drew Wingard, CTO of Sonics said. “They are able to identify those parts of the design where they see risk, or new creation required, or things like that. And in those areas, they have the skill to tunnel down through the abstraction layers as deep as necessary to convince themselves that it’s going to work. They don’t actually have to make it. They just have to convince themselves it’s going to work, and then they need the confidence to black box almost everything else—the parts they identify as being safe or stable. There’s a good analogy to that both in the traditional software model of having libraries of things, and being able to adapt functions that you didn’t write because they’re in some software library that you’ve just picked up. You need to tunnel down to the right level of abstraction to convince yourself you have a solution to the problem at hand. That’s something we should do a lot more of than chip design, at the block level, at the SoC level, at various different stages.”

Frank Schirrmeister, senior group director for product management in the System and Verification Group at Cadence, refers to these types of engineers as the “robe and sandals guys.” “These are often the guys you would never expect, and sometimes they are not that easy to deal with because they all have solved the problem you are trying to discuss with them in their Ph.D. thesis already.”

Paul Hollingworth, vice president of marketing at indie Semiconductor, agrees that a good system designer is somebody who combines an unusual combination of capabilities. “They have enough technical depth to understand the implications of the decisions that they are making, but have the breadth to be able to see the requirements of the system in its context. And that’s quite unusual. That’s why you don’t find too many good system architects. We’re taught to specialize very early on these days, so you’ll find many people who will be really really good at one aspect of something but they won’t necessarily see the big picture.”

Good system designers also need a wide range of hardware and software skills, according to Jason Andrews, product manager cycle models at ARM. “The base is a good understanding of computer architecture and software development. Understanding how software interacts with hardware is key. It’s important not only to select the right IP for a design based on reference manuals, but also to understand how to configure it and program it to get the best results. Architects who use ARM Cycle Models often put the models together to investigate system performance only to find that the system is not providing the outcomes provided in the documentation. The resolution is usually some combination of IP configuration and software programming changes.”
 
Specifically, system design extends beyond the hardware/software boundary to include everything from high-level system description down to implementation. Systems designers must have a good understanding of the implementation process and the impact of power, performance, and area (PPA), he said.

The job expands
System design now requires more and more knowledge about security. System designers must understand the details of secure and non-secure modes of operation, how to prioritize interrupts, and to build systems which will not only work reliability, but protect against security flaws and malicious code.
 
Andrews noted that the best system designers also have accumulated a large knowledge base in a specific domain such as mobile design or networking. “This knowledge base gives them experience with workload analysis and a gut feel for where performance stress points are. In most domains, knowledge is learned incrementally over a number of projects and the design process is refined and additional use cases are added to build up a better understanding of trade-offs and performance metrics.”

In his mentor work with high school students designing robotics, Darrell Teegarden, project manager for mechatronics within the SLE systemvision.com team at Mentor Graphics, said these skill sets are hard to nail down. “I’ve seen superstars, and I’ve seen individuals who you would think would be superstars but who aren’t. The thing that makes the difference is this ability to transcend abstraction but still be able to go down to detail. The ones that are the superstars are the ones who can somehow, beyond expectation, be able to do that.”

Whether this is a personality trait or a learned behavior is difficult to say. “You’ll see some kid who is smart beyond belief and they won’t necessarily be able to do this,” Teegarden said. “Then, you’ll see another kid — I have a kid I’ve been mentoring for 4 years — who is maybe a B/B+ student, not a superstar otherwise, not AP classes, not advanced really, and he’s phenomenal at this. The skill is the self-directed learning ability, and it’s a fearlessness, like they don’t realize they shouldn’t be able to do this. And it’s the ones who are like that, they just don’t slow down long enough to think that they shouldn’t be able to figure this out on their own. Part of it is this next generation, the smartphone kids, they instinctively turn to the resources that they have been using for the last few years and just don’t know any different. They don’t really think to look at books. They are very resourceful. It’s that mix of things in the ones able to do this.”
 
Can good system design be taught?
When it comes to the skills needed to be a good system designer, and whether it is possible to teach those skills, Professor Edward Lee from UC Berkeley says no one really knows the answer, but he has observed that there are enormous differences between good designers and weak designers. The productivity difference can be orders of magnitude.

Interestingly, he said he hasn’t been able to detect any other correlations with personality traits. Some of the good designers are nerds, and some of them are outgoing and gregarious. It’s all over the map.

One thing that is very consistent across the spectrum of good system designers is that when they design something, the design artifact itself — whether that’s a program or a hardware design — forms a narrative that you can read, Lee said. “It’s in part an ability to express oneself clearly in the language of whatever is being designed. A program written by a good designer is usually very readable. You can read it like a text, whereas a program written by a weak designer doesn’t have that consistency. For example, it might break things down into functions where no one can really explain what the function does, and the programmer doesn’t explain it, and it’s just some ad hoc piece of functionality that there wasn’t really any logic to putting it into a module. At the same time, with a good designer, the functions can be described in a single, clearly understood sentence. They don’t always put that sentence in the code, so they don’t necessarily document what they are doing. But when you puzzle through what they’ve done, you can see that there is a single sentence explanation for what this chunk of modularity does. In some sense, that’s what I mean by forming a narrative. The pieces all have a role that can be explained, whereas a weak designer will often stumble upon a design through an iterative trial-and-error approach. They try something, it doesn’t work. They try something else, it doesn’t work. By the time they get something working, they don’t really know why it works, they just stop there and leave it done. A good designer will always be able to explain to you why it works.”

And while there is a definite skill set needed to address next generation challenges in system design, he doesn’t believe the current educational system is particularly well structured to create good designers.

“One of the challenges there is that it seems to be much more difficult to teach good design in a traditional classroom-like setting. In some ways you can leverage technology to help some. For example, with software design, there are static analysis tools that will analyze the [cyclomatic] complexity of a piece of code. These are quantitative measures that are indicators sometimes of better or poorer designs. They’re not very good indicators, but they are better than nothing. The challenge is that to really analyze a design artifact created by a student, first of all, it requires someone who is a really good designer to look at it, and that isn’t going to happen. You have a big programming class, you have teaching assistants who are probably not good designers themselves, and they’re just going to evaluate the code using their own check box list that really is not that much better than what the automated tools are doing. They also might be applying their own biases that are not really substantive. Good design can be taught, but the only way that I know to do it is more like an apprenticeship style,” Lee continued.

To this end, he pointed to a postdoc who worked in his group that he considered a brilliant designer and a brilliant teacher of design. This postdoc used a technique that Lee considered extremely effective, which was a structured way of doing design reviews around code that people in the group were producing, and the goal of which were for everyone to learn to read designs critically.

“Learning to read designs that way is a tremendously effective way to learn how to create good designs,” Lee said. “It’s that process of reading something that someone else has created and trying to figure out what about it is good, what about it is bad, what could be improved, where are the potential defects that might be lurking in the background. Just asking yourself those questions about someone else’s design can be very helpful in constructing your own, better designs.”

Another technique Lee’s postdoc emphasized was to always couple pieces of the design (the modules, the procedures, the objects, and so on) with short textual descriptions of their function in the overall system, he recalled. “The very process of constructing that textual description is actually in some ways a process of critical analysis of your design, because if you can’t describe in a sentence what a function does, it’s probably not a well-conceived function. You’ve done something wrong in your factoring of your design into modules because if you can’t explain what the role of this module is in the system. A lot of time in these design reviews, he had a very nice way of structuring this so that the author of the code was always present, but the author was never required to defend his design, and in fact was explicitly forbidden in these design reviews. Moreover, the author could completely ignore any feedback that they got, so they essentially had complete power. Their role in the design review was simply to explain things that weren’t already evident in the design artifact. And I saw so many times the authors of the code come to the realization that they had factored this thing all wrong because they couldn’t explain the role of the components. in some way, he was able to get them to think about these things in those terms and it was effective. But it’s a process that does not scale.”

Mentor Graphics’ Teegarden suggested project-based learning may be the way forward by putting students in the right context for them to learn or discover the necessary multidisciplinary skills they need.

Kurt Shuler, vice president of marketing at Arteris, agrees that good system design skills can be taught. But he said that particularly at large companies, engineers tend to work in narrow areas. “There are some people or some group of people (usually a pretty small group) who are thinking about the whole system, but the bench engineers are working on a very narrow component of something. They are dealing with a particular driver, or ‘I just worry about the HDMI RTL.’ They deal with one very narrow part and that’s their whole life.”

He questions what would happen if engineers didn’t specialize as much, had more of a say in what the system is, and whether design really does work better with a top-down approach, which is what most companies have today.

At the same time, ARM’s Andrews suggested that engineers who have worked in specific disciplines such as RTL design or software will need to branch out and gain experience in other domains. “This can be a difficult task because it often requires a step backward in order to go forward. It’s difficult to find people with skills broad enough for system design because many engineers have only worked in embedded software, RTL design, FPGA design, or board design and can’t easily make the jump to understand the wider hardware/software relationship.”

The good news for the current slate of engineers is that there will always be a need for all types of people on a design team: those who think high level, as well as those who dig down into the details. “The difference between success and failure on a project is whether there is a person or two who can lead at the high abstraction level, and can help divvy out and direct so that individuals can just focus on a single task,” Teegarden said.