SNPS1301149083 snug sv 2024 semiwiki 400x400 px v2
WP_Term Object
    [term_id] => 157
    [name] => EDA
    [slug] => eda
    [term_group] => 0
    [term_taxonomy_id] => 157
    [taxonomy] => category
    [description] => Electronic Design Automation
    [parent] => 0
    [count] => 3866
    [filter] => raw
    [cat_ID] => 157
    [category_count] => 3866
    [category_description] => Electronic Design Automation
    [cat_name] => EDA
    [category_nicename] => eda
    [category_parent] => 0

SystemC vs C++ for High Level Synthesis

SystemC vs C++ for High Level Synthesis
by Paul McLellan on 12-04-2012 at 4:00 pm

One of the decisions that needs to be made when using high-level synthesis (HLS) in general and Catapult in particular is what language to use as input. The choice is C++ or SystemC. Of course at some level SystemC is C++ with added libraries and templates, but in fact the semantics of the two languages end up being very different.

The biggest difference is in the area of hierarchy, concurrency, clocks and timing. C++ is an untimed approach with no explicit hierarchy, IO protocol, clocks or resets (that is, appearing in the code). During HLS these are added by the synthesis tool. C++ data-types also work well for bit-accurate modeling of hardware. Because of the lack of explicit hierarchy, inter block IO and clocks, C++ is actually a higher level of abstraction in coding style, with no need for such hardware details to be made explicit. The architecture is implicit in the coding style and derived through the HLS process and constraints. However, it is not possible to explicitly specify in the source detailed wiggling of pin signals or controlling on which precise clock cycle something occurs. Another benefit is that C++ simulation is much faster than SystemC (10-100 times).

On the other hand, SystemC makes clocks and resets explicit. The design is represented as a hierarchy of modules using threads to express concurrency. When bit-accurate modeling of pins is needed then this is done by writing at an RTL level. However, all those clocks and threads make the simulation much slower, since it is operating at a much lower level of granularity and there is a lot of overhead associated with the thread context switching. However, for most SystemC (provided you don’t write it entirely like RTL which is very suboptimal if you are using HLS since it overconstrains the tool) the simulation speeds are still 1000s of times faster than RTL.

 For HLS, bit accurate datatypes are a necessity. The functional simulation of the source must match the simulation of the generated RTL or there is no way to verify the design. SystemC contains its own datatypes (part of the SystemC standard) and Calypto also provides some algorithmic datatypes that are easier to use. This is provided in the form of a C++ header file that can also be used in SystemC designs too. One big advantage of the algorithmic datatypes is that the simulation is 30-60 times faster.

By using an appropriate coding style it is possible to write synthesizable code where the kernel of the algorithm is unchanged and can be switched between C++ and SystemC, and between different families of datatypes.

Of course when the design is synthesized the core HLS capabilities are the same. Catapult supports both languages as does the sequential equivalence checking tool SLEC. Depending on timing (and technology) constraints, resource mapping will be done (scheduling, allocation etc) to meet the target, which may involve unrolling loops to increase concurrency for high performance (but high power/area) versus making everything serial so that the design is slow but does not require a lot of resource.

Calypto has a webinar coming up on December 13th at 11am to go over all this in more detail. For more information and to register go here.

Share this post via:


There are no comments yet.

You must register or log in to view/post comments.