GreenControl

GreenControl is a superior framework for different extensions.

• Configuration Framework GreenConfig for parameter runtime configuration
• Green Analysis and Visibility framework that enables real-time visibility into an executing platform model at a low level (C++ variables), and at a high-level (architectural statistics).

The GreenControl framework is extendable with plugins which provide a service and add new functionality. One example is the configuration of parameters within the GreenConfig project, other parts may be added by developing new plugins.

Transaction-based approach

The GreenControl framework is based on a transaction-based approach. The GreenControl Core is a router that connects user modules with service providers (plugins).

• The connections are established via ports.
• Communication takes place using a generic transaction container.

This concept is very similar to GreenBus.

This figure shows the approach. The GreenControl Core routes transactions between the IPs and plugins. One or more of the IPs may be a tool.

Transaction container

A transaction container contains generic attributes to transfer commands between the user modules and the service providers. The concepts of atoms and quarks in the GreenBus transaction container is adopted.

Example:

Service = ConfigService

Target = top.jpeg.compression_rate

Command = setParam

Value = 42

...

Advantages of this approach are

• decoupling of config APIs and config implementation
• well-defined protocol with clear semantics
• easy to add new commands
• easy to add new services, e.g. address management, memory framework, debug fabric, ...

GreenControl Core

The Core forwards transactions from the initiator to the target. For the above example, the target would be the ConfigPlugin which provides the ConfigService. Upon receipt of the transaction, the ConfigPlugin would process the service request setParam("top.jpeg.compression_rate", 42) and acknowledge the transaction.

• Flexibility: Service providers (plugins) and user modules can be attached at elaboration time, without the need for re-compilation of the model.
• Reliability: if a service is requested that is not available/implemented by the service provider, the transaction can be rejected and a warning generated.
• Debugging: all transactions can be monitored in order to trace usage of the GreenControl services.

Service Plugins

Plugins provide functionality, such as parameter configuration, memory and address management, debugging, analysis and visibility etc. The services of the plugins can be accessed by User IP through User APIs (see next section).

Thus, GreenControl is a versatile base fabric for the implementation of SystemC extension frameworks.

User APIs

User APIs are the APIs the user module sees and interacts with. They provide some functionality to the user module (IP). User APIs are connected to the GreenControl Core with a port (GreenControl Port gc_port). They send transactions to the one service plugin which belongs to their functionality and task.

• APIs provide methods whose calls are translated into the appropriate GreenControl transactions.
  • Simple API methods such as setParam/getParam can be directly translated into a transaction.
  • More complex API method calls may require some housekeeping.
• User APIs receive transactions from the plugin and process them.

Additional information

The SystemC model only needs to include the used plugins. When e.g. parameter configuration isn't needed, this plugin can be left out. The connection is done during elaboration, hence no recompiling is needed if the usage of a plugin is changed.

The communication through ports and universal transaction containers gives the ability to extend GreenControl without changing the Core itself.

Newly developed plugins can be connected with the standard port without changing the GreenControl Core. So this extension can even done by a user.