Most engineers learn by doing, and so at DAC in June an EDA vendor with High Level Synthesis (HLS) tools held a language tutorial on choosing C++ or SystemC for design and verification projects. The EDA company is Calypto, and Stuart Clubb put together the tutorial on using synthesizable C++ or SystemC. The design and verification flow for HLS starts with language entry, is followed by synthesis to RTL, and finally has verification that the RTL and entry language are equivalent:
The Catapult tool for HLS has been around for some 11 years now and engineers have done 1,000’s of tape-outs with it because this methodology generates high QoR for RTL in less time than hand-coding at the RTL level. Popular designs for HLS include video compression and decompression, image processing, and wireless or wireline applications. Big-name companies have been using HLS tools like Catapult for multi-million gate hardware projects:
- NVidia – Tegra X1
- Qualcomm – Snapdragon
- Google – VP9
- ST Micro – Monaco and Cannes
- CPqD – 400Gb Coherent Optical Processor
This language is like most modern programming languages in that it is very abstract and doesn’t including IC details like timing with clocks and resets, those lower-level details are added by the HLS tool itself. You can use bit accurate data types in C++ to model your hardware ideas, and the interfacing is abstract.
With SystemC you get a set of C++ classes and macros that are useful for HLS because you can define clocks and resets. Hierarchical modules can be used along with concurrent processes (aka threads). Interfaces can be explicitly defined for more control.
Here’s a chart showing a range of interfaces versus functionality and how these two HLS languages are mapped out along with RTL coding:
Both languages offer bit accurate data types, so take a look at a comparison example using a Variable Rate Polyphase Decimator where our code has configurable taps and phases, plus configurable data types and widths:
This design is quite compact to code in synthesizable C++:
The same design coded in SystemC adds a modular I/O to abstract synchronized data transfer, and the untimed filter code is placed in a thread:
When synthesizing this design into RTL code the designer gets to choose the target technology, clock frequency, resource mapping, and the trade-offs between Unrolling, pipelining area and latency.
Running functional simulation on the C++ code is the fastest, followed by SystemC as second fastest, while RTL simulation is always the slowest.
When coding in C++ there are no interface details on the function call, so HLS maps function arguments to a library of interface protocols. With SystemC you can write pin-wiggling and transaction style views of interfaces, so more control is provided.
For hierarchy in C++ each function can have on clock only and then synthesis creates channels between each function. Hierarchy in SystemC is a full RTL-style instantiation and wire connectivity to any depth, just like with Verilog or VHDL.
A big benefit of using C++ or SystemC for verification is that your simulation times are much shorter than with RTL code. Adding formal technologies to your verification flow makes sense because it adds C property checking, enables formal verification of RTL netlist against your source code, and you can continue to use your RTL LEC (Logical Equivalency Checking) for RTL to gate comparisons.
A quick table neatly summarizes some of the comparisons between using C++ or SystemC languages:
C++ offers the fastest simulation times and is about 20X to 200X faster than SystemC, and is well suited for complex feed-forward algorithm designs, while being limited to pre-built interface libraries.
SystemC is still much faster at simulating than RTL code, and you can write everything that you can in C++ by using the Modular I/O and hierarchy, and it unifies RTL-level and higher abstraction language by offering hardware-centric constructs.
Fortunately with the Catapult tool you can use both languages and both sets of data types natively. Maybe it’s time that you considering trying an HLS flow on your next SoC design.