GreenBus Specification

Quicklinks (access limited to GreenBusGroup and SubscriberGroup):

• In-depth specification
• Implementation details

GreenBus Mission

Today, the composition of complex system-on-chip (SoC) simulation models strongly suffers from incompatible bus interfaces of the various IP used, thus leading to an inefficient and expensive development process. To leverage early software development and design space exploration for heterogenenous embedded systems with SystemC, GreenBus main objectives are:

• Provide a generic yet flexible bus fabric for SystemC/TLM modeling of SoC components.
• Support all the levels of TLM abstraction from untimed programmers view to cycle-count accurate model.
• Enable seamless incorporation of external IP and mixed-mode simulation with heterogeneous components.
• Attain highest possible simulation performance with respect to the desired level of accuracy.
• Base on common standards such as OSCI-TLM and SystemC-SCV.

To this end, the GreenBus initiative aims at combining a flexible and customizable SystemC bus modeling framework with automatic bus fabric and wrapper source code generation from XML.

GreenBus is being specified in close cooperation with leading IP vendors and professional SystemC users. As a long-term objective, the GreenBus specification will be submitted to the OSCI as a standardization proposal.

GreenBus will enable you to generate bus simulation frameworks for your IP bus interfaces at the push of a button.

GreenBus Basic Concepts

In transaction level modeling, a system-on-chip is composed of various master and slave system components which are connected to the bus fabric by a convenience interface. This interface is the API the GreenBus user sees and in most cases is different to the actual low-level transport API of the bus simulation model.

Thus, GreenBus follows a two-layered approach that decouples the user components bus interfaces from the GreenBus interface. Hence, for comparing different buses or bus configurations in terms of overall system performance, you just exchange the GreenBus fabric by an other implementation. There is no need to change your IP core's interfaces at all. Also, no wrappers or transactors that affect simulation performance are necessary.

The above figure shows a simple use case of the GreenBus fabric. The initiator port provides an application-specific communication API, for example simple read and write methods. Slave components are connected to the bus by inheriting from the slave_base class. They implement the application-specific interface and thus, for example, can easily model a memory, a processor, a peripheral hardware module, and so forth.

However, the underlying communication fabric is independent from the convenience API which can be chosen by the GreenBus user and in fact can be different for each IP component in the model. The router module belongs to GreenBus and is accompanied by a bus simulation engine which is responsible for all the bus protocol arbitration and timing estimation.

To provide a maximum level of flexibility and even enable automatic exploration of critical design issues, in GreenBus, the initiator port(s), the slave_base class(es), and the bus protocol implementation will all be generated automatically from XML. Thus, with GreenBus, you will be able to generate your own personal bus fabric in minutes, and it always will be perfectly suited for your current application. Parts of the GreenBus XML schema will base on the SPIRIT approach.

Specification Process

The ultimate goal of this project is to find solutions for generic SoC bus modelling with SystemC that are suitable for a broad range of people who have to connect heterogeneous IP cores together. To this end, we are experimenting with different bus modeling approaches and try to figure out which techniques can help best reaching this destination. We hope that the result from this work will be a proposal useful for the OSCI TLM working group.

In the first phase, we analyse contributions of companies who are already using SystemC and capture the requirements from this for each company. Then, in the next phase, we are collecting ideas on how the GreenBus proposal should look like, and implement engineering experiments. Based on these case examples, we then run a variety of tests, in terms of simulation performance, usability, adaptability, etc.