I was not expecting the last panel on the last day of the Design Automation Conference to be well
attended, but it was - along with animated discussions and a long line of
audience members waiting to ask questions. It turns out that a lot of people
were interested in the panel's title: "What input language is best for
high-level synthesis?"
The panel comes at a time when most high-level synthesis
(HLS) providers, like Cadence, have embraced SystemC. Mentor Graphics is the
most recent addition to the list. But not all HLS tools take SystemC. Synopsys
(not on the panel) introduced synthesis from Matlab/Simulink earlier this year.
Bluespec (on the panel and very vocal) provides synthesis from SystemVerilog. The
panel included some pointed debates between Rishiyur Nikhil of Bluespec and
most of the other panelists.
The panel was moderated by synthesis pioneer Dan Gajski of
U.C. Irvine (not mentioned was Prof. Gajski's role in developing the SpecC
language in the 1990s). Panelists included:
- Michael
"Mac" McNamara, Cadence
- Rishiyur
Nikhil, Bluespec
- John
Sanguinetti, Forte Design
- Andres
Takach, Mentor
Graphics
- Anmol
Mathur, Calypto
- Devadas
Varma, AutoESL
SystemVerilog Versus C/SystemC
I have to give Nikhil credit for taking a controversial
position and sticking to it, even while standing alone. "I think SystemC is the
wrong tool for the problem," he said, in the opening minutes of the panel.
"We're designing algorithms and architectures, and these are highly
concurrent." He argued that C/C++ is inherently sequential, and noted that an
abstract model may have nothing to do with the desired hardware architecture.
Mac noted that C has been around for 30 years and that many
algorithms have already been captured in C. Thus, a specialized language for
HLS is unlikely to catch on at this point. Varma (AutoESL) said "a language
that is primarily a hardware description language is not the right language"
for HLS. Takach (Mentor)
noted that C++ provides the ability to express algorithms, and said that "when
you really need to specify things for which timing is an integral part of the functionality,
you may have to resort to SystemC."
An audience member took up the debate by saying that "C is
the bane of any effort to create parallelism" and that "we have to get past 40
year old languages that have way too many side effects." Mac replied: "If you
look inside our tools, we're taking your input language and trying to find the
parallelism in there. We're capturing algorithms at the highest level of
abstraction and then we have a path to implementation from that highest point."
Later in the discussion, Nikhil asserted that "C is just a
lousy language for expressing many kinds of computations. It's a pipedream that
you should not be thinking about parallelism. C is just the wrong answer to
this question." Sanguinetti responded: "That's why SystemC was developed. C was
not adequate for representing concurrency, and SystemC provides an abstraction
layer. It works."
C/SystemC advocates also talked about the need to model at
different levels of abstraction. The SystemC transaction-level modeling (TLM)
standard allows that. One point I did not hear mentioned is that the SystemC
TLM standard opens the possibility of linking the virtual platform environment
with implementation through HLS. Separately from DAC, Cadence and Wind River recently published
a whitepaper that notes this connection.
What Do You Want From
HLS?
In my view the panel did not really define HLS. But there
was a discussion about what users really want from HLS. Gajski said he wants a
tool that can go from a C language description to an architecture with, for
example, a 3-stage pipeline. "We can do that," Mac said, "but we wouldn't
invent an instruction set or instruction store, fetch and decode."
Nikhil's view: "At the high level, architectures should be
left in the hands of the designer and the language should let the designer
fully express it. C does not." Sanguinetti's response: "You don't take a C
algorithm, stick it into an HLS tool, and say I'm done. The job of the hardware
designer is not being replaced by the HLS tool. You start with an initial C
algorithm and refine it as you do architectural exploration. That's why we need
something like SystemC."
Are HLS algorithms "good enough?" Yes, panelists said. But
Varma noted that HLS is "not pushbutton." Takach said "you do have to put in
some hardware intent at times." Mac said that hardware features should be
extracted "automatically, with light user guidance."
Are Users Good Enough
for HLS?
As I was rushing out to catch a plane, Grant Martin asked a
very pointed question from the audience. He noted that a lot of HLS code is
badly written. "The fact is that many users can't write well in any language,"
he said. How do we overcome that barrier, he asked?
This is a good point. To get good results, users need to
understand how to write good code for HLS and how to best use the tool. It's
important to choose a provider that offers good training and support.
Otherwise, the choice of input language won't matter very much.
Richard Goering