Ok, I admit it… that title is a blatant attempt to grab your attention. But it should also make you think. As a hardware designer, is your job great? Is it what you thought you’d be doing when you decided to become a designer? Is it, dare I say, fun?
Or, like I hear so many times especially from those designing embedded integrated circuits, are you too bogged down in the muck of cranking out hardware implementations to do any real design work? That is, you are so focused on getting an implementation out the door, that you don’t have time to analyze and find the best implementation for your project’s specific goals.
As I recently asserted in a New Electronics article, in 2017, more and more designers will be returning to doing real hardware design work…figuring out the best way to get some functionality onto hardware. The result—better hardware and happier designers.
Which begs the obvious question is…why now? Why 2017?
(Spoiler alert: Better hardware and happier designers results when, like so many engineers, you design at a higher level of abstraction, and then synthesize to RTL implementations via high-level synthesis. But before we get to how that improves your job or why this change is happening, let’s start by taking a step back and considering the role of the hardware designer.)
The role of the hardware designer
Actually, let’s take two steps back to what we thought we were getting into when we selected hardware design as our career path.
Whether your career started with wire wrapping and protoboards, or hardware description languages such as Verilog, VHDL, or more recently SystemC and C++, it seems we all had a fairly similar (and naïve) vision of our role as we started our careers.
That's pretty straightforward...you get some clear requirements, understand them, and then begin the design work of evaluating and fleshing out one or more options before committing one to full implementation.
Can you remember those days? (Did "those days" ever exist for you?)
I remember being told that was the process as I was getting my schooling. In fact, I was luckier than most in that my first project as a real engineer did follow that paradigm pretty closely. But just the first one…
The role of the hardware designer (real-world version)
Then reality sets in…there are schedules, cost targets, and competing priorities. The next project is lined up right behind this one. You never quite have to time to do it right, and you surely don’t have time to do it over.
So what do these five steps really look like?
1) Get some technical requirements from our management, or from those weird marketing folks
You will definitely get requirements…often from both sources, and often contradictory. You think, “Did anyone even read this thing?”
2) Take the time to fully understand the requirements, getting clarifications, as required
By now you know any task that starts with “Take the time to fully…” actually means, “As soon as possible…” And when it comes to understanding the requirements, you are no longer surprised when your questions are answered with the reminder that you are the expert, so just figure it out.
3) Consider alternative options to implement the hardware
This is true engineering work, so it has to happen, at least to some extent. Whiteboards become your best friends at this point, unless you are under 30 years old in which case you can fully think in PowerPoint or Google Docs. You work with your team to flesh out at least one viable option that you are fairly sure will meet the requirements after you expertly refined them. You turn that into your engineering spec (or proceed directly from the whiteboard).
4) Mock-up or prototype the best options to ensure their viability
Prototype? Good luck. The schedule doesn’t allow for that. At best, you’ll think you have the option to prototype and that will get rolled out as v1 of the hardware. So let’s just say step 4 is no longer part of the process.
5) Select the best one, and implement it “for real” use state of the art tools
Having skipped #4, you are going straight from whiteboard analysis to an implementation. As a digital IC designer you jump straight into your favorite editor and start pounding away. Months and thousands of lines of code later, you have a veritable mountain of Verilog “always” blocks implementing exactly what you intended…you hope. Actually, that is verified by another team. And hopefully there aren’t any issues, because this pile of RTL code is pretty hard to change.
Speaking of change, your manager just knocked on your door. “No big deal, but marketing says we need to make a minor tweak to the requirements.” Spoiler alert: when was the last time marketing ever removed a requirement?
By the time you finally finish the project, you are already behind on the next one. One good thing…this next project seems quite similar to the previous project, just with a little new functionality and some different performance targets. Sadly, it doesn’t take much change to necessitate a complete re-implementation, so it’s time to open up the editor again and start over.
You think, “Is this really what my life has become?”
In part two of this series, we will revisit the life of a hardware designer whose company, like most of the leading semiconductor companies, is using a hardware design paradigm that puts more focus on the real design engineering work by doing that design work at a higher level of abstraction.
Related Resources: