In part one of this series, we talked about the role of the hardware designer, specifically comparing the ideal version of the hardware designer with the real-world version. From the emails I received, this is a bittersweet reality for many readers of this blog.
Today, 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.
What are these companies doing differently?
In short, these companies allow (and expect!) their designers to perform high quality design work, as compared to spending their time coding up one RTL implementation that may or may not be the most efficient implementation.
Their hardware designers create designs at a higher level of abstraction, using languages such as SystemC and C++, then use an automated high-level synthesis (HLS) tool to translate, or more correctly synthesize, this to RTL for implementation on an ASIC or FPGA. The RTL can be pushed through the rest of the IC tool chain automatically.
This allows the designers to focus on functionality and high-level architecture in their high-level design. From that design, the HLS tool creates one or more RTL implementations optimized toward the constraints specified by the designer.
Their designers make quantitative trade-offs, evaluating multiple implementations to find the one that best meets the requirements of the current project. Better still, the same high-level design, commonly termed “behavioral IP,” can be used for other projects even if the design constraints are vastly different.
But instead of getting on my soapbox to espouse the values of HLS, let’s focus on the more important question…
What drove these companies to use an HLS-based flow?
Of course, the motivations are slightly different for each company, but there are some common themes.
A) In order to move up the value chain, large SoC companies are providing more tailored and differentiated offerings than ever before. In the traditional hardware design flow, this means design teams find themselves buried in a never ending stream of “exactly same as last one, but…” requirements. They have found that HLS provides a much more efficient way to produce so-called “derivative designs,” because design code of behavioral IP does not have to be rewritten from scratch for each derivative, even if the functionality changes significantly.
B) Smaller companies, or small teams within larger companies, have found that HLS provides a way for the small teams to be much more efficient and more competitive. The hardware design teams are often more streamlined (code word for “smaller”) than those creating SoC’s, but the tasks to be completed remain the same. In some cases, such as “large A, small D” mixed signal, the digital team may be only one or two engineers.
C) Verification, whether done by a huge multi-national team or one person in the cube next door, needs to start earlier in the process to be effective. With the HLS flow, accurate hardware models are available much sooner, since the RTL is synthesized by a tool, not written by hand.
You’ll notice that in each of these, there is a need for the design teams to be more efficient. That’s where things get better for the hardware designer.
Making hardware design great again… or “How does this affect me?”
Let’s revisit the five design steps again, from the point of view of a designer working using HLS.
1) Get some technical requirements from our management, or from those weird marketing folks
Sadly, this is unchanged. You still get requirements, and they still may conflict. However, what does change is that later, when your boss hands you a requirements change, you don’t have to try to figure out how to implement the change in the sea of RTL you’ve already written. You simply specify the change, which might just be a change to the constraints, and the HLS tool will figure out how to create the RTL.
2) Take the time to fully understand the requirements, getting clarifications, as required
Again, HLS doesn’t fundamentally change the fact that you’ll never be given the time you’d like to have to fully vet the specification. However, it does provide one major advantage. Often, you can use a high-level model (SystemC, C, C++) to work through the requirements, knowing that the work to create that model is in fact on the direct path to silicon.
3) Consider alternative options to implement the hardware
As I mentioned in part one of this series, this is the true engineering work, and this is where HLS can really begin to make hardware design great again. Because you are working at a higher level of abstraction, you can generate multiple implementations, so you can quantitatively evaluate multiple implementation options.
In the admittedly extreme example below, a total of over 80 implementations were generated and quantified in terms of power, performance, and area (PPA) from a single high-level SystemC model. With this type of quantitative analysis in hand, you can choose the best option for this specific design target.
4) Mock-up or prototype the best options to ensure their viability
Depending on your HLS flow, this one may have come for free with #3. Assuming your HLS flow is tightly integrated with the silicon implementation flow, you can be assured that the option(s) you selected previously will be viable in silicon.
5) Select the best one, and implement it “for real” use state of the art tools
After the above steps, you already have an implementation that can be committed to hardware. That also means you already have an implementation for the verification team to begin work. So now, instead of writing thousands of lines of RTL code, you can focus on tuning the high-level model which is typically at least an order of magnitude less code. So this phase because more about optimization, again a true engineering task, than tedious coding of Verilog RTL.
By working at a higher level of abstraction, primarily considering design decisions instead of implementation details, hardware design becomes more effective, more interesting, and more fun.
And who doesn’t want to have more fun at work, right?
In part three of this series, I’ll share some feedback from designers who are having fun with HLS. If you have some experiences of your own to share, let me know. I love hearing from you, so keep those emails and comments coming.
