SystemC-based high-level synthesis (HLS) tools have greatly improved in recent years and are undergoing adoption by many large semiconductor companies. But to get high productivity out of HLS, current RTL designers will first face a learning curve, according to panelists at the recent Design Automation Conference (DAC 2012).
The panel was titled, "High-Level Synthesis Production Deployment; Are We Ready?" It was moderated by Clem Meas of quickStart Consulting. Panelists were as follows, in order of presentations:
Meas began the discussion by noting that "four of these six panelists reside in semiconductor companies and have responsibility for implementing high-level synthesis flows. The purpose of the panel is to make sure we have a good understanding of where we are in that process." He noted that it takes 10 years for the industry to move to a new level of abstraction, and said that with HLS "we're 8 years into a 10 year period."
Mark Johnstone - The View from Freescale
Johnstone noted that Freescale management has decided that it's time to move above RTL. Why? Complexity! "Today we're seeing 1.3 billion transistors per design," he said. "In 2020, at the projected end of Moore's Law, it will be 21 billion transistors. Clearly this is not sustainable with RTL."
But HLS poses some challenges. "Our number one problem is the learning curve," Johnstone said. "RTL engineers may have taken one C class in college 25 years ago, and that's the extent of their experience." Without training, they're not going to write good C code or get good hardware out of it. He also noted that "we see a lot of C code that tries to get down to the Verilog RTL level."
Johnstone also said that some tools have "not well documented" restrictions on code the tool can accept, that more library code is needed, and that ECO flows need to improve. But he thinks these issues can be solved. To demonstrate the importance of HLS, Johnstone showed some RTL code, asked the audience what it does, and then showed how HLS abstracts out what the programmer is trying to say. "And that is why there's higher productivity, and why it's a winning strategy," he said.
Eli Singerman - The View from Intel
So, as the panel title asks, is HLS ready for production deployment? "The short answer is no," Singerman said, "but I think we can get there and we want to get there." He cited Intel's belief that abstraction is the most important way to tackle complexity, and observed that "we are at an inflection point where the traditional RTL design flow is simply not good enough for the level of complexity we need."
Intel is taking active steps to realize the vision of HLS, Singerman said, and is running a number of experiments with HLS design flows. While the company is "encouraged by the results we saw," there is a steep learning curve for RTL designers who must suddenly understand more about software development, he noted. He also said that current tools and methodologies don't fully support verification at the SystemC level, and he called upon EDA companies to "start validating SystemC models like we've been doing for the past 20 years in RTL."
Singerman also noted the challenge of integrating blocks designed with HLS with pre-existing RTL blocks. "Integration issues can very easily offset any benefit we get from this new design paradigm," he said. "If we get a two month savings, and it takes us four months to integrate generated RTL with the rest of the system, we lose two months."
Benjamin Schafer - The View from NEC
HLS is not new to NEC. Shafer noted that the company developed its own HLS tool in the 1980s and had its first HLS tapeout in 1993. Even so, most designs are a combination of HLS blocks and legacy RTL IP, which must all be verified together.
Shafer observed that HLS gives rise to some challenging questions, such as:
He also noted that virtual platforms are becoming essential, but they don't work with HLS. "Can we make [virtual platform] SystemC TLM models synthesizable? It's a big gap in the design flow," he said.
Vinod Kathail - The View from Xilinx
HLS is important for FPGAs for two reasons, Kathail said. One is that it's very time-consuming to design a multi-million gate FPGA. Another is that software programmers want to use FPGA fabrics to accelerate certain tasks. This is particularly true for the Xilinx Zynq platform, which combines a processor with an FPGA fabric.
Xilinx recently announced an HLS capability with its Vivado toolset. Kathail cited an example design that took 12 weeks to hand-code in VHDL, versus one week for Vivado HLS. QoR is comparable to within 10-15% of hand-coded designs, he said. Further, HLS allows design space exploration. But he acknowledged that HLS requires different skill sets.
Mark Warren - What Cadence Customers are Saying
Warren offered some observations based on experiences customers are having with the Cadence C-to-Silicon Compiler. One important point is that HLS requires far fewer lines of code than RTL synthesis to describe functionality, making it unnecessary to commit to a micro-architecture. This, in turn, makes it possible to explore a number of different micro-architectures and evaluate area, timing, and latency tradeoffs. Another big win is the faster functional verification available with SystemC. Because fewer lines of code are required, simulation is faster and debugging is more efficient.
"But it's not all rosy," Warren said. "The overwhelming feedback from this panel is that there is a learning curve, there is a new skill set that's required." It may take several months for an RTL designer to learn C++ from scratch, although once he or she learns C++, learning SystemC should only take a few days, he said. "We really need a lot more designers who are comfortable in C++. We need to push back to the universities to bring C++ back."
Because of the need for new skill sets, most companies don't get full productivity benefits the first time they use HLS. "But the second, third or fourth times - that's when you really start to see the productivity benefits," Warren said.
Andres Takach - Calypto Surveys User Wants
Takach noted that a number of production designs have already gone through HLS. "Typically productivity gains are 4X to 20X," he said. "In the first design it's less, but as you move up in experience you get further and further improvement." He added that "certainly people need to understand the language and be comfortable with it."
Takach cited a customer survey that asked about the three most important technologies to integrate with HLS. The answers: Formal verification, RTL synthesis, and power analysis and optimization. The survey also asked about criteria used to select HLS tools. The number one item was "reduced verification time and effort."
Does System Design Require a New Class of Engineer?
That's the question I raised in a blog post over a year ago, and the question is still valid today. The ideal HLS user is an engineer with both hardware and software skills. He or she needs to be able to write an efficient SystemC (C++) model that expresses desired system functionality, but remains far above the register-transfer level in abstraction. This "hardware savvy" synthesizable model must achieve QoR comparable to hand-written RTL in a fraction of the time that hand-coding would take.
Herein lies a challenge - and an opportunity for those seeking a new or better career.