Our research aimed at extending the hardware-software design language SystemC to enable easy communication modeling for systems-on-chip and ease model reusability between different tools.

• Engineers should be able to compose a system using IP-Cores from different vendors without the need for developing complex communication adapters (GreenSocket/GreenBus).
• A middleware for modeling tools (GreenControl) accompanied by their plug-ins GreenConfig and GreenAV will help to ease development. Concurrently it helps reusing and simulating a model in tools of different vendors, especially allowing configuration interoperability.
• Since recent transaction level modeling standards only cover the higher abstraction layers, a cycle accurate transaction level modeling standard is required.

GreenBus is an open communication modeling standard which we developed while being part of the GreenSocs-Initiative. The main goal was an industry-wide accepted SystemC interface standard for IP-Cores, such that IP-Cores from different vendors may be assembled to a system-on-chip regardless of the IP's communication protocols. In this way high level models of chips can be developed much faster, enabling an earlier analysis of communication bottlenecks and communication related power consumption.

This development took place in close collaboration with well-known partners, both in industry and research. First results were presented to the Open SystemC Initiative (OSCI) in 2005. In November 2007, OSCI released its final TLM-2.0 standard proposal which included several of GreenBus base concepts. In our co-operation with OCP-IP, our experience with GreenBus is influencing the OCP channel implementation for SystemC.

Our GreenBus open source library for SystemC offers a simulation framework for busses and networks on chip and enables mixed mode simulation of heterogeneous IP-Cores which reside at different layers of abstraction. In cooperation with Intel we developed a PCI Express simulator.

In 2008, the GreenBus open source library has been modified to fully support the TLM-2.0 standard (GreenSocket and GreenRouter). The experiences gathered in this project were fed back into the advance of the TLM-2.0 standard. For example, we actively participated in the development of the TLM-2.0 Language Reference Manual, published in 2009 as part of the TLM-2.0.1 release, which forms the basis for turning the TLM-2.0 standard into an IEEE standard.

Figure 1: TLM-2.0 based simulation using GreenSockets and GreenRouter

Figure 1 shows a simulation with two IP-Cores (producer and consumer). The incompatible communication interfaces of the cores, PLB and PCI respectively, are translated into the standard TLM-2.0 protocol by the protocol layer (GreenSocket based User-APIs), such that the GreenRouter can work in a fully TLM-2.0 compliant manner. In this way a reliable communication gets established. At the interconnection layer, different busses and networks on chip can be simulated and their performance impact on the system-on-chip model can be compared. The interfaces used at the interconnect layer are the ones specified in TLM-2.0.

GreenBus and TLM-2.0 mark milestones in the standardization process for TLM of abstract communication. However, there is still no standard for less abstract modelling. With TLM primarily focussing on more abstract modelling, the first obvious question to be answered is, if less abstract or even cycle accurate TLM is necessary at all. To this end, let’s look at the two most important reasons for less abstract/cycle accurate TLM.

First, modelling and analysing a system using abstract TLM might result in the need for a new block of hardware that cannot simply be taken from some IP library. Starting from the abstract model that was built for the analysis mentioned before, the missing block is refined step-by-step until an automatic hardware synthesis becomes possible. The input for such a synthesis is of course far less abstract than the model to start with, in the worst case the input needs to be at the register transfer level. For non-trivial blocks transforming the least abstract but still standardized TLM model into such a synthesizable one in a single step is hardly doable. Moreover, leaving the TLM-world, i.e. moving away from simple TLM interfaces to RTL interfaces with hundreds of signals, should happen as late as possible in the design process. Unfortunately, there is no less abstract TLM standard. Hence, the designer either needs to be proficient in using two presumably totally different TLM interfaces (the standardized, abstract one and the proprietary, cycle accurate one), or he needs to hand over the model to an expert for cycle accurate TLM. The first case implies a massive burden on the designer, especially if there are more than two entirely different TLM interfaces in his system. The second case is expensive and bears the risk of misunderstandings when handing the model, the specifications, and the constraints over to another engineer.

The second reason for the need for less abstract and cycle accurate TLM is that results of abstract simulations are insufficient to answer all important questions. Doing abstract modelling statements like “About 100 MHz should be good enough to achieve a certain response time” might suffice, but when creating e.g. the next generation mobile phone, the decision between 95 MHz and 100 MHz might give the critical advantage over competitors thanks to superior battery longevity. RTL models of the system could be used to calculate exact results, but the simulation performance of RTL simulations pales in contrast to the one of abstract TLM. Ideally, there should be an abstract TLM model that is able to efficiently provide the same essential results as the RTL simulation.

Hence, there is a need for cycle accurate TLM. If it was standardized, both, TLM IP vendors and TLM tool vendors, could reduce their efforts and costs by supporting just one cycle accurate TLM standard rather than a plethora of independent proprietary TLM interfaces. Additionally, if such a standard was based on TLM-2.0, designers and engineers would be able to reuse their knowledge on abstract modelling and would only have to learn a few more things and adopt the cycle accurate modelling standard.

Consequently, we were researching a proposal for a standard interface for cycle accurate TLM of system blocks communicating via memory mapped bus interfaces, just like in TLM-2.0. As mentioned above, a cycle accurate TLM model should abstract away as much as possible but still be able to provide the desired information (as accurate as RTL). Hence there must be precise answers to the following questions: What will and can be abstracted away? What information can still be provided? To this end, we further analyzed cycle accurate TLM simulations, and identified abstraction possibilities, which do not endanger the cycle accuracy of the desired information.

Our work on a cycle accurate TLM standard proposal showed that the general modelling mechanisms of TLM-2.0 are sufficient for cycle accurate modelling. Still a number of extensions and additions were necessary to make cycle accurate modelling simple, safe and fast. In addition to these generic modifications of TLM-2.0, we also identified rules on how to map a given memory mapped bus interface onto our extended TLM-2.0. Furthermore, we investigated of SystemC and its simulation can be optimized for cycle accurate TLM modelling and simulation.

Due to our expertise in cycle accurate modelling and our GreenSocs membership, we also participated as a member of OCP-IP (Open Core Protocol - International Partnership). Together with CoWare, Nokia, Sonics and Texas Instruments we were forming the System-Level Design Working Group (SLD-WG). The group worked on the improvement of the OCP standard and especially on its implementation in SystemC. In 2007, we developed a completely new OCP library for SystemC based on GreenBus. GreenSocs has been awarded "OCP-IP Contributor of the Year" in 2007.

The results from 2007 have been used to port the complete OCP TLM kit to the new TLM-2.0 standard. The OCP TLM kit allows using its TLM connections at various abstraction levels including the cycle accurate abstraction layer. Thus we could evaluate and test our research results on cycle accurate TLM in a real world scenario.

In today's ESL design, rapid platform development is done on a high abstraction level. Hence the system description language SystemC is getting used more and more often. For easy and fast architectural exploration, the designers must be able to integrate (high-level) models from different IP or model vendors as well as customized models into one platform. These models need to be interoperable with low effort. One interoperability layer has been addressed recently by the OSCI standard TLM-2.0 for high-level communication. It defines a communication standard, that allows models from different vendors – under some preconditions – to be interoperable. Cycle accurate bus simulation using transaction level modelling is another project.

Another interoperability layer is the tool layer, which has not yet been addresses by a standard: Different vendors developing SystemC models typically use different tools. Each tool vendor has a proprietary mechanism for configuring and controlling the models, all proven good for their specific use case but being different and incompatible with each other. Although the models are interoperable on the communication layer, the platform architect who is integrating the models now has to deal with models written for different configuration mechanisms.

We show two different approaches to achieve configuration interoperability: On the one side there is a flexible interoperability framework which is able to connect different configuration mechanisms to each other, on the other side a configuration standard is discussed.

Initially a definition of interoperability for ESL models is important: We distinguish between communication interoperability and meta interoperability. Communication interoperability in the area of SystemC models ensures the models as well as the real hardware/IP behind the models working together. In SystemC this kind of interoperability is mainly represented by the OSCI TLM-2.0 standard. The meta interoperability addresses methodologies which make the models work together on the tools area. This interoperability is not necessary for the hardware and models to work together, but makes it possible or easier to handle and integrate models with each other within a simulation environment.

We focus on the configuration aspect within the area of meta interoperability. For simulation models, configuration means to set model properties before the simulation is running, and possibly even to control the properties during the simulation.

GreenControlis a middleware platform for modeling tools. It will ease development of SystemC models by providing the two Plug-ins GreenConfig and GreenAV. Concurrently it helps reusing and simulating a model in tools of different vendors.

GreenControl and the Plug-ins were developed in cooperation with GreenSocs and well known companies like Intel and Texas Instruments between 2007 and 2011. GreenControl allows loading different functions by means of Plug-ins (fig. 1).

Figure 1: GreenControl framework with Configuration Plug-in

The configuration mechanism GreenConfig offers configurable parameters that can be configured before and during simulation in various ways. There are a number of APIs for different scripting languages (e.g. Perl or Lua) and there are adapters allowing easy and seamless integration of GreenConfig parameterized models into various commercial tools. GreenControl provides flexible interfaces to different configuration mechanisms that can be connected to the universal framework. Thus it is possible to link configuration mechanisms in two different directions:

1. A model being developed using a vendor-specific tool can be linked to the universal framework GreenConfig and configured (cp. fig. 2 right side).
2. A vendor-specific configuration mechanism can be linked to the universal framework so that it is possible to configure foreign modules within that tool (cp. fig. 2 left side).

Figure 2: Interoperable Configuration

Figure 2 illustrates an example: models originally requiring the tools A, B, C can be configured using just one of these tools or the universal tool.

Experiments suceeded using CoWare Platform Architect's SCML properties and ARM CASI parameters within the universal environment GreenConfig, as well as configuring models using the universal mechanism with the CoWare tool. The integration has also been shown successfully with Synopsys Innovator's CCSS parameters and some integration with smaller tools.

Our work makes incompatible configuration mechanisms interoperable, thus making models more interoperable on the meta level.

The GreenAV service enables the analysis und visualization of data for debugging purposes.

The project GreenReg was a use case to study the flexibility and portability of GreenConfig parameters. The registers modelled using GreenReg were based on GreenConfig parameter, thereby enabling them to be configured both using the original GreenConfig tools or a commercial tool of the user’s choice.

These projects are available as open source on GreenSocs with a free license. Thus we facilitate free vendor-independent model development.

The SystemC Remote Service Interface (SCRSI) – a result of a number of student thesis works between 2008 and 2011 – is a graphical front-end for GreenControl. A graphical user interface allows to interactively control the advance of the simulation, to choose which data shall be analyzed/visualized, what results shall be computed out of the gathered data, and to set conditional behavioural break points. These results can be converted into charts or graphs during simulation (figure 3).

Figure 3: SCRSI window showing the current and past values of a parameter

Being part of the GreenSocs initiative allowed us to feed the results of the research on configuration into the Configuration, Control & Inspection (CCI) working group of the Open SystemC Initiative, as well as to actively participate in the CCI WG itself. Thereby we were able to influence the resulting CCI standard significantly and to do the prototypal implementation of the standard (2009-2011).

Ziel des Forschungsprojekts TRAIN (Transaction Interchange) ist, abstrakt modellierte Kommunikation wie in Bild 1 automatisch in eine geeignete Hardware-Software-Kommunikation abzubilden. Aus einem SystemC-Modell werden dazu die benötigten Daten mit GreenControl extrahiert und in ein GreenBus -basiertes Systemmodell umgesetzt (Bild 2).

Bild 1: High-Level-Kommunikation durch Methodenaufruf

Bild 2: TrainRPC-Kommunikation über GreenBus

Das Beispiel zeigt zwei Proxy-Module, die den Methodenaufruf getPixel() auf das GreenBus-Protokoll abbilden. Verschiedene Kommunikationsarchitekturen können nun mit Hilfe der GreenBus-Bibliothek simuliert und miteinander verglichen werden, um eine optimale Systemkonfiguration zu finden.

Bild 3: Synthetisiertes Hardware-Software-System mit PLB-Bus und Train-Kommunikationsadaptern

Abschließend kann die Hardware verfeinert und mit einem Synthesewerkzeug in ein Gatternetz für den endgültigen Chip umgewandelt werden. Die Kommunikationsverbindung zwischen Hardware und Software über Busse oder ein Network-on-Chip soll dabei komplett automatisch erzeugt werden. Bild 4 zeigt dies an dem endgültigen Hardware-Software-System für das getPixel()-Beispiel. Das Hardware-Modul wurde mit einer Open-Core-Protokoll-Schnittstelle (OCP) ausgestattet. Durch Kommunikationsadapter kann das Hardware-Modul nun an verschiedene Busarchitekturen angebunden werden.

Auf der Software-Seite wurde ein Hardware-Abstraction-Layer generiert und der Prozessor mit einem CPU-Adapter ausgestattet. Dieser Kommunikations-Coprozessor stellt die Verbindung mit dem Hardware-Moduls und schließt so die Brücke zwischen Hardware und Software.

Ziel unserer Forschungsarbeiten ist die automatische Generierung aller benötigten Kommunikationsadapter, sowohl für Hardware als auch für Software (Bild 4). Aktuell werden zwei Prozessoren, der IBM PowerPC-405 und der Xilinx MicroBlaze unterstützt. Mit diesen Adaptern wurde das Verfahren erfolgreich an einem Video-Prozessor zur Echtzeit-Erkennung von Körpergesten erprobt.

2008 wurde ein Verfahren zur automatischen Integration von IP-Cores entwickelt. Hierzu wurde eine IP-Schnittstellen-Beschreibungssprache definiert und ein Tool geschaffen, das Kommunikationsadapter automatisch aus IP-Schnittstellenbeschreibungen generiert. Die Ergebnisse dieser Arbeit wurden im Dezember 2008 auf der IEEE International Conference on Embedded and Ubiquitous Computing in Shanghai präsentiert.

Bild 4: TRAIN Kommunikationsarchitektur-Synthese