Modelling OCP Interfaces in SystemC: Standards built on top of OSCI's TLM-2

James Aldis, (Texas Instruments France) Mark Burton, (Greensocs Ltd.,)
Robert Günzel, (Greensocs Ltd and TU Braunschweig,) Herve Alexanian, (Sonics Inc)

reprinted with permission by OCP-IP - (C) Copyright OCP-IP

OSCI has recently published their TLM-2.0 technology which provides for interoperability between SystemC models of electronic components whose primary interfaces are memorymapped busses. This is a very important development in the ESL industry, but it does have some limitations. In particular, TLM-2.0 needs to be extended for some real memory-mapped busses, and TLM-2.0 is only applicable at high levels of timing abstraction: untimed, loosely-timed and very approximately-timed models. These limitations are inevitable given that OSCI can only create technology that is generic in nature and not associated with any specific real component.

OCP-IP, as the publisher of a memory-mapped IP core interface, is able to address these limitations and has done so. This paper describes the approach adopted by OCP-IP to providing SystemC modelling interfaces for a real memory-mapped bus family. TLM-2.0 has shown itself to be an effective and efficient base technology for all variants of OCP at all levels of abstraction, from cycleaccurate to untimed. Furthermore, the nature of TLM-2.0 and its use as a base technology for everything means that bridges between different protocols or between different levels of abstraction are very easy and efficient. We even see that in a very large number of cases an OCP component is directly interoperable with the OSCI Base Protocol.

The Open Core Protocol (OCP) is a public standard memory-mapped core interface, defined by collaboration between systems houses, EDA vendors and IP suppliers within the OCP International Partnership (www.ocpip.org). The motivations for defining the OCP are to enable better IP reuse and a wide spectrum of common tooling and shared experience.

Transaction-level modelling (TLM) is an essential part of all modern system-on-chip development methodologies and where IP is being reused and purchased from third-party suppliers, standard interfaces for TLM models of IPs are as important as standards for the RTL interfaces. Because of this, the OCP-IP provides standard SystemC APIs for modelling OCP interfaces at multiple levels of abstraction. These APIs, along with infrastructure code in the form of SystemC channels, ports, monitors and so on, have been available to the OCP community for more than 5 years. They are mature and widely-used. OCP-IP has shipped many hundreds of thousands of copies each representing many hundreds of thousands of dollars in collective development expertise, and delivering a recognized world-class technical solution for users.

This code uses SystemC, the dominant TLM modelling language, as defined by the Open SystemC Initiative (OSCI). In the summer of 2008, following a lengthy process, OSCI released version 2 of its TLM modelling library. OCP-IP members contributed to TLM-2 and have worked hard to ensure its applicability to OCP.

Importance of the OSCI TLM-2.0 Standard

OSCI’s release of TLM-2.0 marks a seminal point in the life of electronic system-level design. For the first time a non-proprietary modelling technology has been created which offers

• High performance simulation, using shared memory (pointer) communications rather than data copying, and allowing for bypass of network and bridge models
• Fully-defined data payloads, meaning complete interoperability interfaces
• Detailed API rules and conditions, ensuring the ability to create API checkers and verify standards compliance
• Extensibility in both functionality and timingaccuracy

Within TLM-2 OSCI has provided various bits of technology of general utility and also an interoperability standard for basic memory mapped busses. This Base Protocol can be used to model the bus interfaces of many IP components, but it is not a superset of all bus interfaces for all components. Therefore, it needs extension in many cases. OSCI provides an extension mechanism but does not provide any “standard extensions”.

Until the release of TLM-2.0 there had been a plethora of different mechanisms used to model bus interconnect. TLM-2.0 will provide commonality of approach for all of these, and enable levels of direct interoperability that were not achievable before.

The standard provides for three levels of commonality:

1. Commonality of approach:


2. Commonality of basic technology:


3. Use of the Base Protocol:


Clearly, memory-mapped busses are not the only interfaces on TLM models that need to be standardised in this way before the problem of TLM model interoperability goes away completely.. However, OSCI’s TLM-2.0, by focussing on memory-mapped busses, has managed to solve one part of the problem at the same time as providing a technology framework that can be used for other parts, such as clocks, interrupts, network interfaces, and so on. And, because OCP is just a memory-mapped interface protocol, TLM-2.0 already contains all that is needed for OCP-IP to specify modelling APIs for OCP users.

Levels of Abstraction

OCP-IP recommends 5 levels of abstraction for memory-mapped busses, as described in Table 1.

Table 1

OCP Term	Timing Accuracy	Abstractions	OSCI-TLM-2.0 equivalent
TL0	Cycle accurate	None, this is the RTL level	SystemC synthesise-able subset
TL1	Can be fully cycle-accurate, requiring clock synchronisation between bus master and bus slave, and respecting the OCP protocol. All beats of a burst are modelled.	Wires and signals are not modelled	none so far
TL2	User selectable number of timing points per bus burst	No clock synchronisation therefore some non-determinism. Optional averaging of bus occupancy over bursts or parts of bursts. Flow control not modelled explicitly.	none so far
TL3	4 timing points per bus burst, bus occupancy determined only by ‘data receiver’	No modelling of independent write data phases, no ability to model intra-burst timing effects, no distinction between address order within a burst (eg wrapping and incrementing bursts are equivalent)	Approx-timed (AT) nb_transport()
TL4	Minimum necessary to run software on a virtual platform	“Pure functional” representation of memory-mapped bus. No flow control or ordering effects are modelled.	Loosely-timed (LT) b_transport() and nb_transport()

Layered TLM Technology for Multiple Levels of Abstraction

In order to make it possible to bridge simply and efficiently between level of abstraction, OCP-IP is developing a layered technology for SystemC modelling. For the 5 levels of abstraction listed above, 3 SystemC APIs are provided by OCP-IP:

Table 2

OCP Term	OCP-IP SystemC Interface	OSCI TLM compatibility
TL0	Not specified by OCP-IP separately for SystemC from other HDLs	None, this is the RTL level
TL1	OCP-IP TL1	Uses TLM-2 generic payload, sometimes with extensions. Uses different protocol phases and rules from OSCI TLM-2.0 BP. Uses nb_transport()
TL2	OCP-IP TL2	Uses TLM-2 generic payload, sometimes with extensions. Extensions are a subset of the extensions used at OCPIP- TL1. Uses different protocol phases and rules from OSCI TLM-2.0 BP and from OCP-IP-TL1. Uses nb_transport()
TL3	OCP-IP TL3	Uses TLM-2 generic payload, sometimes with extensions. Extensions are a subset of the extensions used at OCPIP- TL2. Uses the same protocol phases and rules as OSCI-TLM-2.0 BP. Extensions may be ignorable in which case OCP-IP-TL3 is directly interoperable with OSCITLM- 2.0-BP. Uses nb_transport() and b_transport()
TL4

The three SystemC APIs are mutually incompatible, but adapters between them are provided. The goal is to allow fully automatic instantiation of adapters within the components, so that a system model can be assembled from whatever component models are available, while the level of abstraction for each memory-mapped bus connection can be selected independently.

The SystemC APIs are quite different from an RTL model of an OCP interface. Whereas in RTL an interface consists exclusively of signals on wires, the SystemC interfaces are all based on the OSCI TLM-2.0 concepts of...

1. a single payload object carrying the necessary information about the transaction, to which references are exchanged by function call between components.
2. data being exchanged directly between the transaction target (the endpoint memory or register bank) and a data buffer internal to the transaction initiator (the CPU or DMA that  launched the transaction) without being touched in any way by intermediate components such as bus routers, arbiters, protocol conversion bridges, and so on.

Because of this, bridging between the SystemC APIs and a TL0 (RTL) model of a component is less efficient than bridging between two SystemC APIs. This is not considered an “issue” because models with TL0 bus interfaces are expected to run slowly, anyway. Adapters will of course be available. The layering is illustrated in Figure 1:


Click to enlarge

Figure 1

In general all technologies used at one level of abstraction are also used at all lower levels. The only exception to this is that the mechanisms for modelling bandwidths and splitting of transactions into chunks are specific to TL2. They are not needed at TL1 where explicit modelling of all beats of bursts, with flow control, is compulsory.

OCP-IP Extensions

The OCP protocol requires extensions to the OSCI generic protocol in the following areas:

• Bus locking and semaphores (all levels of abstraction).

• Exotic addressing modes (all levels of abstraction).

The OSCI TLM-2 GP supports only transactions addressing a contiguous set of addresses in the memory map, possibly with a repeat for accessing FIFOs. A sophisticated protocol will allow forms of transaction outside this scope.

• Transaction re-ordering enabling (required for TL3, TL2 and TL1).

• Posted write support (required for TL2 and TL1).

The OSCI TLM-2 GP only supports one form of “write” command, which to be useful, must be assumed to be a “non-posted-write”, meaning that it always has a response and this response indicates effective completion of the write process at the end target.

• Non-blocking flow control (required for TL2 and TL1)

Most conventional memory-mapped busses have mechanisms for flow control that can be described as “blocking”, in that there is a risk that the wires of the bus will remain occupied by one transaction for a long period, thus preventing other transactions from progressing. OSCI-TLM-2 BP only considers this sort of flow control.

• Address ordering within a transaction (required for TL2 and TL1).

Certain addressing modes do not change the functional interpretation of a entire transaction but do have an effect on performance, if effects internal to the bus burst are considered. For example a “wrapping” burst contains the same sequence of addresses as an “incrementing” burst, but starts with the most critical rather than the lowest address. Such effects cannot be modelled at TL3 or TL4 and so it is unnecessary at those levels of abstraction to distinguish wrapping from incrementing addressing modes.

• User extensions (required for TL1). Since OCP is extensible in itself, it is necessary to support user extensions to OCP in the

SystemC APIs. This is trivial at TL3 and TL2, but at TL1 some consideration needs to be given to how these are mapped to binary wires in hardware, so that it is possible to model components that modify such extensions without being aware of their functional purpose. An example would be a network-on-chip, configured to map initiator extensions onto target extensions, whose SystemC model is capable of doing this mapping only as a modification of anonymous bits.

Every OCP interface has a configuration, which specifies which memory-mapped bus features it includes. The intersection between the bus Master and bus Slave configurations will determine which of the above extensions is present, optional, or absent from each of the SystemC APIs. As the majority of bus interfaces encountered in real life tend to be simple, extensions should be regarded as uncommon. The OSCI TLM-2 generic protocol unextended is able to cover a wide range of SOC components’ bus interfaces.

Configuration and Run-Time Compatibility Testing

OCP is not one memory-mapped bus protocol; it is a family of protocols spanning from very simple to highly complex. A component with an OCP interface on it publishes values for a set of around 90 parameters, the combination of which is commonly called the component’s OCP configuration. The parameters describe which commands and addressing modes are used, address and data widths, and so on. In hardware, a component’s OCP configuration is determined by its internal synchronous digital circuitry and the “configuration file” is a documentation of the hardware. The configuration file is used when an SOC (or testbench) is integrated, to confirm the compatibility between an OCP Master and the OCP Slave it is connected. This process is in general, automated. In some cases the OCP configuration of one side of the interface may be used to create the RTL code for the other component. In RTL we refer to OCP “sockets,” but in this case a socket is nothing more than a set of pins on the boundary of a component.


Figure 2

In SystemC TLM, on the other hand, the components’ source code may be much more generic. A component may be able to adapt its behaviour to support an externally-supplied OCP configuration, or may even be able to adapt to the OCP configuration of the other OCP component to which it is bound (this possibility exists, but is not shown in the diagram). In SystemC we also refer to OCP “sockets,” but in SystemC the socket has more of a real existence than in RTL. It is a SystemC object containing the SystemC port and SystemC export needed for binding, and it can provide a number of other services to the user-code for the component, such as removing timing annotations, providing memory management for transaction payload objects, instantiating adaptors between abstraction levels and testing configuration during simulation elaboration. In the OSCI TLM-2.0 technology, the sockets are C ++ template classes, for which an interface traits class needs to be specified. This traits class is also known as a protocol, hence the OSCI Base Protocol is a such a traits class, used to determine the type of a TLM-2.0 socket. Only a Base Protocol socket can bind to another Base Protocol socket. The principle behind this is that when extending TLM-2.0 to model some functionality beyond the scope of the Base Protocol, a new traits class should be declared, but the same underlying C++ technology used. The extensions should use the extension mechanism of the OSCI Generic Protocol. This ensures that sockets using incompatible protocols can not accidentally be bound to one another, but that creating a bridge between them is simple and efficient.

This mechanism cannot meet all the requirements for modelling OCP, and therefore it has been complemented by an elaboration-time compatibility check between the bound sockets. The reasons for this are:

• The almost unlimited number of different OCP configurations makes it impractical to create a traits class for every one
• OCP compatibility rules are more sophisticated than the mechanism permits. There are many cases where a pair of components with nonidentical configurations are compatible, and the sets of compatible configurations are not disjoint.
• It is highly desirable that where possible, direct binding to the OSCI TLM-2.0 Base Protocol be possible, which dictates the use of the Base Protocol traits class in some cases
• It is desirable to be able to create SystemC sockets that are able to adapt to the level of abstraction of the thing they are bound to, if necessary.

Summary

The OCP family of memory-mapped bus protocols can be effectively modelled using the OSCI-TLM-2.0 technology recently published. OCP-IP is proposing a set of extensions and extra technologies to provide interoperability standards for the OCP at all levels of TLM abstraction.

The following technologies from OSCI TLM-2.0 have been used unchanged:

• generic payload
• base protocol phases
• transport functions with timing annotation

The following technologies have been added to OSCI TLM-2.0:

• generic payload extensions
• transaction ‘chunking’ to increase timing accuracy
• sender bandwidth information
• phases for independent data and command, and for chunked transactions
• clock synchronisation for cycle accuracy
• support for combinatorial dependencies, for cycle accuracy
• run-time bindability testing

And. no part of the OSCI TLM-2.0-BP has been discarded, except that compile-time bindability testing is more limited than anticipated by OSCI.

		James Aldis is a senior member of the Group Technical Staff at Texas Instruments, where he works on the architecture of OMAP SoCs. His degree is in pure mathematics from the University of Liverpool and his PhD is from the University of York.
		Robert Guenzel received his diploma in Computer and Communications Engineering from the technical university of Braunschweig in 2005. Since 2005 he has been a researcher at the department of integrated circuit design (E.I.S.) at the same university.
		Dr. Mark Burton is the founder of GreenSocs. He graduated from Warwick University with a degree in computer systems engineering and completed a PhD in artificial intelligence within education. He is the chair of the OCP-IP SLD working group.
		Herve Alexanian is a staff software engineer at Sonics, Inc. His main focus is on reference models for SoC interconnects. He has been the Sonics representative to the OCP-IP System Level Design workgroup since 2004.

Contact OCP-IP Fill out this form for contacting a OCP-IP representative. Your Name: Your E-mail address: Your Company address: Your Phone Number: Write your message: