Last Thursday, EETimes hosted a virtual System on Chip event focused on IP integration in SoCs. Even with IP re-use comprising a large percentage of new SoCs, new IP must also be developed in order to differentiate on the hardware side. With RTL containing so much application-specific implementation detail, more companies are looking to move to high-level synthesis based on SystemC, which allows for separation of pure functionality from implementation details.
Five panelists took part in a discussion led by Clive "Max" Maxfield, president of Maxfield High-Tech Consulting, focusing on the topic of "Applying High-Level Synthesis in an SoC Flow." The panelists were:
- Jeff Bier, Founder and President, BDTI
- Philippe Coussy, Associate professor, Lab-STICC, Université de Bretagne-Sud, France
- George Harper, Vice President of Marketing, Bluespec, Inc.
- Michael (Mac) McNamara, Vice President & General Manager, System Level Design, Cadence
- Chris Rowen, Ph.D., Founder and Chief Technology Officer, Tensilica, Inc.
The discussion centered around 6 key questions. Here is a sampling of the discussion, which opened with some interesting comments:
Chris: You could
build a chip entirely of off-the-shelf IP but differentiation would have to
come only via software, which isn’t enough if say you’re pushing the power
envelope. 80% of the design is re-use, but that other 20% is exploding in
complexity.
Mac: HLS is not
about improving design efficiency, it’s about improving verification efficiency
George: I agree with Mac about verification efficiency. There’s
lots of IP that is developed that’s not shipped in silicon. HLS helps
facilitate getting more of this into emulation and prototyping to speed up
verification
Mac: Yes, in fact Hitachi did
a paper last year where they synthesized the testbench and RTL onto a Palladium box and
achieved a 10,000x speedup.
Can HLS tools now
synthesize both control and datapath?
Mac: Before we
got into the market, we asked customers why they hadn’t adopted HLS yet. One of
the big issues was that HLS only supported datapath, meaning you still had to
hand-code and verify RTL for control. This was one of the first things we
worked on when we developed C-to-Silicon. We like to say “we’re not the first ones to do HLS,
but we’re the first ones to do it right.”
George: I think
all HLS tools can synthesize control, it’s just a question of how high-level
the abstraction of it is. SystemC is too low-level, which is why we came up with the system-centric Bluespec language.
Chris: The higher
the level of control, the more unstable the specification is going to be.
Because so many of the interactions are impossible to anticipate, they are
impossible to verify. These are things you’d rather have be programmable rather than
baked into the silicon.
High speed models
cannot be synthesized, so how do we bridge the modeling and implementation
worlds?
Mac: HLS is
getting more sophisticated, but they still can’t take a pure algorithm into
something that knows how to move around the data. This is why hardware
architects still need to get involved to refine the model to something that
will meet the performance, power, and area goals. From there the HLS tool can schedule the
clock edges and allocate the resources. The bridging will still require humans,
we just want to remove the low-level leg work.
Phillipe: Perhaps it’s necessary to define a new
language that can both describe high-speed models as well as being
synthesizable
Mac: In 1985 we
created new languages -- VHDL and Verilog -- because the silicon compilers couldn’t support C/C++. Now
the technology has moved on and the tools can support it. We now can support
the language that all these existing models and algorithms out there are
already described in. Isn’t it better to use the language they’re familiar with and
just extend it with some specific nouns and verbs to help describe hardware? I
am on the IEEE SystemC synthesizable subset committee, and we have a draft of the
subset out. Right now it’s a lowest common denominator of what all the vendors
support.
Jeff: We took our
pure C algorithm and used AutoPilot to generate RTL. It wasn’t high QoR RTL because we synthesized it as-is without targeting it for hardware, but it proves that more than just a subset of C is supported.
George: C is
certainly very popular and prevalent, and we know how to augment it with
RTL-like concurrency via SystemC, but it doesn’t deliver a high-enough level.
Bluespec is such a language.
The C++ language is being
extended to handle concurrency. Will this make SystemC unnecessary?
Phillipe:
Concurrency is the main weakness of C++, but the concurrency model in SystemC
may not be at a sufficiently high level.
George:
Concurrency extensions existed well before SystemC. SystemC adds datatypes and
clocked hardware.
Mac: The
concurrency extensions will be useful for multi-threaded applications, and I
suspect that SystemC will take advantage of these in the future, but these were
not put in specifically for hardware.
Challenges of parallel
programming – what are the differences in programming for hardware?
Chris: In the
theoretical world they’re connected, but in the real world they’re different.
The typical software engineer learns sequential programming from the start and then has to learn
parallel techniques. The typical hardware designer emerges from the womb
thinking in parallel terms. The key question is what do you do when you
consider the whole body of software that describes a system? How do you
describe the interface between the mostly sequential software piece that runs
on processors, and the mostly parallel part that runs primarily in the hardware
world?
Jeff: Programming
processors has gotten more complex in the last few years because of multi-core.
While in some cases designing hardware has gotten easier due to HLS.
Will HLS enable
software engineers to develop hardware?
Chris: I think
that you’ll see some blurring of the lines. We’ve seen that in the evolution of
who uses our processor generators. There are a class of customers that have the
software architects configure the processors. But a hardware engineer understands
that if you do a multiply operation 64 times, you might get 64 multipliers in
the hardware. Whereas the software engineer wouldn’t worry about that. So the
software engineers have the algorithm knowledge and can contribute to the innovation
and differentiation of the platform, but we need to sensitize the software community to the fact that hardware has a cost.
Jeff: We feel
that a “hardware-aware software engineer” can use a high-level synthesis tool.
They’re software engineers but understand pipelining and concurrency, so they know
that if they inadvertently overconstrain a design they can recognize it and
make adjustments. We’ve seen these folks generate RTL, but then integration of that
RTL is a whole different story.
Why is it taking HLS
so long to see mainstream adoption? Is HLS ready for prime time?
Phillipe: One
solution will come from education. It’s a new way of thinking.
Mac: Software is getting
harder, and hardware is getting softer – you can code this and re-target it.
But I go back to the “80% of IP is re-use” – where did that come from? At some
point we’ll want that part to be more easily re-targeted and HLS will enable
that. In the past, the control logic problem, and the lack of an ECO flow,
prevented folks from using HLS. Customers are using this in production in
Japan, USA, and Europe, but this is maturing. We’re in the inflection point
now.
Conclusion
It is pretty clear that we are at an inflection point now, with more and more teams moving to a high-level design, verification, and synthesis model. In the future we will still need hardware expertise in developing this IP, but hardware and software teams will work more closely together. And a language like SystemC offers a common ground for this coming together.
Jack Erickson