Abstractions in SystemC
SystemC is built on a very powerful object oriented language (C++) and thus C++'s features can be used to create many of the necessary abstractions. Sometimes this is cumbersome. Other times, the abstraction can be built in SystemC but has not been built since the abstraction has not been identified as important. Because of its flexibility, SystemC makes an excellent platform on top of which to build the abstractions described here, though SystemC's model of concurrency makes optimization difficult.
System C uses a discrete event model of concurrency which is very flexible and does not limit component composition.
SystemC uses a discrete event model. The discrete event model is very general, but as a result, difficult to analyze. In general data may never even converge to a stable value in a cycle. Other systems using discrete event models (i.e. VHDL and Verilog) have notoriously slow execution times for models.
SystemC is built on C++ and uses high-level types available in C++.
Polymorphic components can be created in SystemC using C++ templates. However, this system can be cumbersome to use since there is no type inference mechanism. Thus each type must be explicitly specified, even for very simple components.
It has been our observation that if components are to be reusable, there needs to be small components that transform the interface of existing components. It can be extremely tedious to explicitly specify the types of each of these components explicitly making C++ templates a cumbersome mechanism for polymorphism when used in a structural system.
Components could be customized in a C++ based modeling system via inheritance. It seems, however, that SystemC does not permit this inheritance without using implementation specific information (Virtanen, et. al, SystemC Based Object Oriented System Design).
SystemC does not provide control abstractions per se. However, since the C++ supports overloading of most operators, along with other object oriented language features, it is possible to build certain control abstractions, such as the one developed for LSE.
SystemC does not support parametric scalability since the size of all array data types and port arrays must be fixed at component construction time, not component instantiation time. This must be done to preserve synthesizability, since SystemC does not distinguish between post-constructor-static arrays and general purpose dynamically allocated arrays.
SystemC supports parametric composition via arguments to an class constructor. Note however, that this prevents one from knowing the structure of the model at compile time.
SystemC does not provide an explicit mechanism to separate data collection and modeling. However using sophisticated features found in C++ one can construct a system where the data collection is separate from modeling. However, more sophisticated data collection schemes with libraries of polymorphic collectors and aspect oriented design of data collection will not be possible.
Strictly speaking, it is not possible to know the full model structure of a SystemC model at compile time. This is because components can be customized based on the arguments passed to constructors, and these arguments are only known at run-time. Since SystemC is synthesizable, clearly some SystemC compilers can know the knowledge of some SystemC models' structure at compile time, however, this information may not be useful for reducing the overhead of reuse in the system. For example, it isn't clear if one can even compile a C++ program correctly unless the user manually instantiates all template types. Yet, we want to be able to resolve template types using the model's structure.