Something old, something new in SystemC HLS

Perhaps no area in EDA has been as enigmatic as high-level synthesis (HLS). At nearly every industry event, some new-fangled tool always seems to be tabbed as the next big thing by some analyst or pundit. In a twist, the latest news is on one of the oldest tools – CybeWorkBench.

RTL, well entrenched among designers and IP vendors, is hard to get away from as a design tool. While the benefits of SystemC for modeling and simulation are clear, moving designers and IP creators to embrace HLS as part of the design flow has progressed rather slowly. This may be due to a perceived disconnect between automated tools in general and the realities of timing closure, with too many risks and too much hand-holding required.

As designs continue to increase in size, there may not be a choice if designers want to complete designs within a reasonable period of time, remaining competitive with those pushing the envelope. HLS has been shown, when successful, to reduce development time and resources typically by a factor of three and up to a factor of eight in some cases. There are also ramifications in hardware-software co-verification which cannot be overlooked.

In development since 1986, Cyber is the behavior-level synthesis engine from NEC, developed by Kazutoshi Wakabayashi and his team. Wakabayashi-san authored one of the seminal papers on HLS in 1991, and in many ways helped create the science. Since its origins, Cyber has become both C and SystemC capable. The Cyber engine is the heart of CyberWorkBench, combined with a C-to-RTL equivalence prover and a cycle accurate co-simulation platform to form a complete HLS tool.

The news: Aldec is teaming with NEC to resell CyberWorkBench. NEC has retained rights to the tool in Japan, China, and Taiwan, and Aldec is now selling CyberWorkBench outside of those markets. Daniel Payne first covered this news for SemiWiki at DAC 50, including a brief interview with Wakabayashi-san from NEC.
Forum thread: Aldec Enters HLS Market by Selling CyberWorkBench from NEC

Blog w/interview: HW Prototyping and HLS at DAC

Several interesting questions come to mind. First, why enter a crowded SystemC HLS market with the likes of Calypto, Forte, Cadence, Synopsys, and others? NEC has been successfully using CyberWorkBench internally for some 15 years, and has several design successes working with other companies in Japan, but is not globally recognized as an EDA vendor. Teaming with Aldec provides the global reach and support needed. The fit between the two firms is good, and Aldec customers who want to move toward HLS now have a path to do so.

Second, how is CyberWorkBench different from other solutions? Many have said that control-dominated design is difficult in HLS. On page 8 of a white paper written by Wakabayashi-san in the late 1990s and recently republished on the Aldec site, he discusses the difficulties of scheduling and how a manual scheduling mode in Cyber has helped with quality of results. The paper is an interesting read, providing a window into how Wakabayashi-san correctly anticipated many of the issues we are still talking about today.

NEC-Aldec HLS white paper:

C-based SoC Design Flow and EDA Tools: An ASIC and System Vendor Perspective

Third, how is Aldec adding value? Satyam Jani, product manager for Aldec, previewed some ideas for SemiWiki. Aldec has some experience with SystemC modeling and verification tools such as Riviera-PRO, but in synthesis everything until now has been in RTL domain. Jani sees CyberWorkBench fitting in what he calls the Aldec SoC Validation Ecosystem, showing how a complete SoC validation flow now looks.

One point Aldec has shown strength at is listening to customers, and feeding that back into development teams working on new releases. This could inject some new life into CyberWorkBench as Aldec and NEC work closely together, with exposure to more customers and different types of designs.

Will HLS ever become the norm, replacing RTL? Probably not completely, but for larger designs this is likely to happen as more automation will be required for reasonable design cycle times. One key area to watch is how much merchant functional IP becomes available in SystemC. One of the problems we need to stop is tweaking, creating SystemC-like implementations of HLS that are just different enough to prevent wider reuse. Vendors need to get behind SystemC, or help extend it as necessary to get past issues proprietary implementations claim to be solving, if HLS is ever to meet the promise.

lang: en_US