How to Future-Proof A Hardware Designer
I’m at DAC this week, where there is a lot of interest and discussion on what’s going on in design and what’s going to happen to designers. One conversation with a university professor gave me a “eureka” moment.
The professor had a student who really loved RTL design. The student asked him where he could get a job doing this, and the professor suggested the student move to India. While this is not entirely true, I believe the sentiment brings home a significant issue hardware designers are facing today. RTL design is becoming, or perhaps has already become, a commodity.
As a hardware engineer in a world where my profession is a commodity, how can I expect to survive? I believe the secret to success—the secret to “future-proofing” your professional capabilities—is to understand that an engineer’s value comes from his ability to solve a problem. If RTL design is becoming less and less of a problem then we have to figure out where the hard part of design is today.
I believe the current challenges in design are in the area of defining the architecture. We need to understand what we are going to build and we need to characterize the performance and prove the efficiency our hardware will achieve before we build it.
By understanding the design at a more abstract level I can make tradeoffs at the system level, define performance characteristics, make tradeoffs between hardware and software and between implementation alternatives, and I can balance the cost, performance and power consumed by my system before implementing my design. The RTL design itself may be a commodity, but defining the hardware that should be built and making the architectural decisions that define what RTL should be built absolutely are not commoditized skills.
In my opinion, RTL hardware designers need to begin this transition to become architectural designers. Someone who does not understand hardware concepts is not going to be effective at making the tradeoffs required to create a successful system design. As a hardware designer, if I expand my capabilities to embrace an understanding of the system level, embrace the concept that hardware design does begin above RTL, then I will be able to leverage my hardware understanding into the future. I will be a valuable contributor to the emerging and challenging portion of the hardware design task by creating unique architectural solutions to meet systems cost, performance and power optimization problems. And I will “future-proof” my value as a hardware designer.
–Jon McDonald

July 31st, 2009 at 12:26 pm
Amen! Word! You’re singing our song!
We have long recommended that “architectural transparency” and “high level architectural synthesis” are the keys to value, i.e., to letting designers focus on what’s important. It’s long been understood in software that “good algorithms trump everything”. The hardware version of this aphorism is that “good architectures trump everything”.
Good performance (area, latency, throughput, power, etc.) is all about good algorithmic cost models, and architectures are precisely the primary determinants of algorithmic cost models. If you can’t flexibly and precisely manipulate and control architectural choices, you’re dead.
[ Which is why I'm so skeptical about C/C++ synthesis, because they provide no transparency or control towards algorithmic cost models, but that's another story. ]
Rishiyur Nikhil, CTO, Bluespec, Inc.
August 3rd, 2009 at 7:44 am
Jon,
At EDA companies we knew that there was only 1 system architect per 10 or mroe RTL coders, so the challenge in becoming the architect is that there are so few positions available.
August 5th, 2009 at 6:39 am
In preparing for the future we have to be aware that the future will not be the same as the present. From a current and recent past perspective I agree that there may be 10X more RTL coders than architects. The challenge in this changing landscape is to understand were the value in design is being derived and as an engineer to focus my contribution in an area of high value. With ESL capabilities improving in both high level synthesis and architectural specification and analysis the value in design is moving to the architectural level, I believe over time we will see the ratio of engineers focused on architecture to RTL increasing. As Rishiyur states, “good architectures trump everything”, as ESL methodologies and tools become mainstream more resources will be invested in ensuring that we have a good architectures, ultimately requiring more engineers working at this level.