New-Tech Europe | March 2017 | Digital Edition

Chip Design Special Edition

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.

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

New-Tech Magazine Europe l 63