63 / 84
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.
Chip Design
Special Edition
New-Tech Magazine Europe l 63