Implementation ideas for the configuration framework GreenControl

This page contains an idea how to implement the GreenControl framework.

e.g. one of the IP blocks may be a tool

Transaction-based approach

GreenControl follows a transaction-based approach. The GreenControl core is a router that connects user modules with service providers.

• the connections are established via ports
• communication takes place using a generic transaction container

This concept is very similar to GreenBus.

A problem that we might want to overcome is that ideally, the user shoudl not have to \"bind\" the ports together. Somehow, a module's \"control\" port should just bind itself automagically to the GreenControl (or whatever control backplane is available in the system)... is this possible?

(WolfgangKlingauf) should be possible by overwriting end_of_elaboration (or some similar kernel callback) in the GreenControl module. This method would traverse the module hierarchy and bind the GreenControl ports.

Transaction container

The 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 will be adopted.

Example:

Service = ConfigParam

Target = top.jpeg.compression_rate

Command = setParam

Value = 42

...

• Advantages
  • 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 managemet, memory framework, debug fabric, ...
• Disadvantages
  • need to think about extensions
    • >] Within GreenBus, the extension mechanism is beginning to come together. We need it here too!

GreenControl core

The core forwards transactions from the initiator to the target. For the above example, the target would be a ConfigPlugin. Upon reception 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

Config APIs

Config APIs are implemented on top of the GreenControl core.

• they translate API method calls into the appropriate GreenControl transactions.
  • simple API calls such as setParam/getParam can be directly translated into a transaction
  • more complex API calls may require some housekeeping
• they receive transactions from the ConfigPlugin and process them.
  • notification of value change events
  • push parameters

TBD: Config API implementations should be kept minimalistic. BUT: shall they locally cache parameter values, or shall each parameter access lead to a transaction to the ConfigPlugin?

ConfigPlugin

The ConfigPlugin provides all functionality required by the Config-APIs. Hence it is an implementation of our requirement list.

Parameter management

The configurable parameters are managed by the ConfigPlugin. To load and store parameters, it uses a Param-API which is connected to a storage implementation. This might be

• a simple map
• an SQL database
• a text / XML config file
• ...

Hence, initializing parameters from a config file just requires an appropriate Param-API that is able to interpret this config file.

Other plugins

In our concept, the ConfigPlugin is just one service provider for the GreenControl framework. Other plugins may provide other functionality, such as memory and address management, debugging, ...

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

Discussion

Advantages

The SystemC model only needs to include the used plugins. When e.g. memory management isn't needed, this plugin can be left out. The connection is done during elaboration, accordingly 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.

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

The approach is very close to GreenBus architecture. Hence GreenBus code fragments and particularly experience according performance optimization, transaction pooling, smart pointers, routing, address caching and so on can be re-used.

Disadvantages

To give the ability of extending GreenControl the transaction container has to be either very general to be useful in a new developed plugin or it has to be extendable itself.

The extension of the container could be done by inheriting from it.

The transmission of a transaction is more complex (and more time consuming) than simple method calls.