Both a C++ class library and a design methodology, SystemC is suitable for creating cycle-level models of interfaces and hardware architectures. It seems to be emerging as the dominant C/C++ design tool with support from all of the major EDA companies.
SystemC provides a hierarchical design that can address high-level abstractions as well low-level logic designs. It can be used to simulate software algorithms too. This wide range of simulation support enables SystemC to address all aspects of SoC design.
SystemC is more than a simple collection of C++ class templates. Its class definitions address asynchronous timing operations, an interconnect methodology, performance tracking, logging, and debugging. The design of SystemC is extensive and it's still evolving.
When looking at the supporting class library source code, SystemC appears rather complex, but designers don't have to contend with these details. Instead, the definitions supplied by the class library will be used. Understanding their syntax and semantics is significantly less work.
Knowing Verilog or VHDL will help when learning SystemC, and so will a background in C and C++. Unfortunately, having a background in only one of these areas requires learning the other. Luckily, an extensive understanding of C and C++ syntax and semantics isn't required unless designers will take advantage of more advanced features other than those related to SystemC, such as defining and using new classes.
Those familiar with the Verilog and VHDL hardware description languages will have an easier time learning SystemC. The syntax is different, but the semantics are very similar.
For those familiar with C++, the utilization of C macros is easily recognizable. The definition is actually a C++ structure. The use of C++ templates is seen with signal connections. For example, the sc_in<bool> definitions are associated with binary state inputs. The same amount of information is needed to define a multibit bus.
Getting into the details of SystemC requires more space than we have here, but this is a quick overview of the listing. The D flip-flop definition defines two inputs (din and clock) and one output (dout). The doit function is executed when a clock edge occurs and it copies the information from din to dout. The information on dout is maintained until changed again by another clock edge. The SC_CTOR is a C++ constructor function. The code shown in this example binds the doit function and sets the sensitivity to the clock signal so the function can be called at the appropriate time. All of these details are found in the SystemC documentation.
The shifter2.h file contains a second definition for the higher level shifter module consisting of two D flip-flops. The shifter2 class has the same set of inputs as the D flip-flop, but there are two additional variable definitions for the flip-flops. Contained in the SC_CTOR constructor are the connections between the flip-flops, as well as the input and output for the shifter.
SystemC source file conventions follow C++ conventions. Typically, the .h header files only contain definitions that aren't like the example that contains function definitions, such as the SC_CTOR constructor function. This information is normally maintained in a .cpp code file. The two files are usually written in pairs.
Additionally, this sample shows how incremental refinement can occur. In this case the shifter2 could be defined first and implemented without using the D flip-flop objects, but rather C++ code that performs the same function. This higher-level implementation offers better simulation performance. Obviously, a larger impact can be gained when the objects are more complex. That would be the case when defining a processor core.
Developers with SystemC experience are rare at this time, due to the newness of SystemC. While there's no guarantee that SystemC will be the key to SoC designs in the future, it looks very likely at this point.