GreenBus Specification Details

Overview

GreenBus is a common bus structure for high level modeling of systems-on-chip. It is an extension of the OSCI Transaction Level Modeling (TLM) library. The aim is to provide a modeling tool that is independent of the underlying bus being modeled, but allows models of IP that use different buses to be easily and efficiently connected in a common way.

The GreenBus fabric splits up into two layers: The user layer and the bus layer. The user layer bases on the OSCI TLM proposal and provides a convenience API to connect IP using initiator ports and slave_base inheritence. The bus layer will be easily adaptable to reflect specific bus protocol implementations at different levels of TLM abstraction. Transaction Level Modeling covers a number of modeling abstraction levels from cycle based models (which are fairly close to their RTL implementations) through to higher level models such as Programmer View models that hold no or only estimated timing information.

The ultimate goal of GreenBus is not to provide just another TLM bus model with an application-specifiic API. Rather, GreenBus is a framework for building buses. To this end, GreenBus will be customizable to provide heterogeneous user APIs and bus protocol implementations. These customized GreenBus implementations will be automatically generated from XML descriptions. In contrast to highly configurable bus frameworks, each GreenBus implementation will be perfectly suited for its application and thus will boast the highest possible simulation performance.

GreenBus will enable different models to be integrated together to form a system model without the need for major re-working of the models involved. This has long been the aim of SystemC itself, but it is unachievable without a level of infrastructure, and agreed ways of using the language. GreenBus will allow efficient IP reuse and IP exchange. It will reduce training costs, and most importantly it will enable tools to be built that support models built using GreenBus.

Requirements

This is a list of requirements being taken into account during the GreenBus specification development.

Must be there in first release

Must be planned to be implemented

Nice to have

Abstraction Layers

R1	GreenBus is to be built on top of the SystemC TLM libraries.
R2	GreenBus will support an abstraction layer suited to very fast models, which may have little or no implementation information (such as timing or power). These are typically suited to software development. Elsewhere called a PV (Programmers View) model.
R3	GreenBus will support an abstraction layer suited to more detailed models which can (if the model writer desires) represent full implementation information (such as timing or power). These are typically suited to system exploration and verification. This abstraction layer can be further broken down into different modelling styles
R3.1	Models build on an otherwise unchanged PV model, elsewhere called PVT (Programers View + Timing).
R3.2	Models use the SystemC event mechanism to schedule bus activity, elsewhere called BA (Bus Accurate).
R3.3	Models use a cycle clock to execute eactly one cycles worth of activity at a time, elsewhere called CC (Cycle Callable). All of the above mechanisms have their advantages and disadvantages, and are of use under different circumstances.
|	>] If one of these were missing in the first release, the result would still be useful, but we do need them all in the end

Generic bus fabric user interfaces

R4	The GreenBus reference implementation will provide a user layer at both PV/PVT and BA/CC level with OSCI TLM interfaces. Data transfers will base on well-defined request and response data structures.
R5	An arbitrary number of master and slave modules at different levels of abstraction will be connectable to the bus fabric. Arbitration and routing are implemented inside the bus and will be decoupled from the user layer.
R6	Plug-in interfaces will allow for extendability and connection to simulation tools, etc.

Generic bus fabric implementation

R7	The GreenBus reference implementation will include a generic router implementation
R7.1	it can be specialized to different bus protocols
R7.2	at different levels of abstraction
R8	Inside the bus fabric, TLM put() and get() calls will be used for data transfers.
|	>]Not sure how important this one is?
R9	A priority queue will be used for request queuing and scheduling. Bus communication events will be scheduled on a virtual time line, thus leading to a very high simulation performance since the arbiter thread "knows" how long it may sleep until the next event has to be processed.
|	>]Admittedly, 'VERY' nice to have!
R10	Event notifications inside the bus fabric should be kept to a minimum.
R11	The whole implementation should base on only two threads, keeping context switches to a minimum.
R12	The reference implementation will support runtime-configurable slave-driven memory map configuration and will provide a simple PVT router implementation with the following convenient API methods:
R12.1	Event-based (non-blocking)
R12.2	Blocking calls
R13	Moreover, to demonstrate GreenBus full capabilities, the reference implementation also will provide a comprehensive implementation of the complex IBM CoreConnect processor local bus (PLB) at BA level. This model will support:
R13.1	Pipelined transactions
R13.2	Overlapped address / data handshake phases
R13.3	Static / dynamic priority schemes
R13.4	Burst transfers
R13.5	Bus locking
R13.6	Transfer timeouts
|	>] These are not requirements so much as features of PLB?

Adaptability to application/vendor-specific bus interfaces and protocols

R14	GreenBus will provide templates for initiator ports and slave_base classes which will be customizable by XML and facilitate as much inter-working as possible between the various different implementation modeling styles and abstraction levels.
R15	Bus protocols, arbitration schemes, and transfer timings will be recorded in well-defined XML decriptions. Using template code, from these descriptions, application-specific GreenBus implementations will be automatically created.
|	>] A first release might not be completely automatic
R16	User-specific convenience interfaces to connect heterogeneous IP at different levels of abstraction will also be described using XML. GreenBus will enable the automatic generation of initiator ports and abstraction level adapters from these descriptions.
R17	The XML descriptions should differentiate between compile-time, elaboration-time, and runtime-configurable options.
|	>] A first release might do more at compile time than it needs to (for instance)
R18	The XML descriptions should incorporate the SPIRIT XML specifications for RTL interfaces and the upcoming SPIRIT TLM schemas.
|	>] I think this is a corner stone of the value of GreenBus

Monitoring and Introspection/Reflection

R19	The generic bus fabric should support runtime-configurable transaction recording.
R20	Protocol-checkers, statistics gatherers, and trace dumpers should be optionally includable on a connection. For this, the SystemC Verification Library should be utilized.

MarkBurton's comments are in Green