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:
Interoperability between TLM models is not just about technology, but also about methodology. Understanding whether and how different features of a protocol should be modelled, what sort of structures should be used, who should be expected to provide those structures, and what services should be provided. In this case, simply using the same methodology and approach to modelling greatly assists users in understanding each other and enables the market for providers of both training and IP. 2. Commonality of basic technology:
OSCI TLM-2.0 provides a wealth of basic technology, including the Base Protocol for memory mapped busses, but also a host of utility functions and structures which are of use to model interface development across-the-board. Reusing this basic technology not only reduces the burden for organisations like OCP-IP (and others who are providing specific interfaces built on TLM-2.0,) but also greatly assists in ensuring a basic degree of interoperability. Furthermore, OSCI specifies exactly how the basic technology is to be extended, and in doing so, how compatibility can be maintained. Even in cases where direct plug-in interoperability is not possible, use of a common approach and common technology will frequently ensure that simple and efficient bridges can be constructed. 3. Use of the Base Protocol:
For IP components whose interfaces are relatively unsophisticated, the OSCI Base Protocol (BP) may provide a complete off-the-shelf solution on how to model them, at an approximately-timed or loosely-timed/untimed level of abstraction. Every BP bus master (initiator) is 100% compatible with every BP bus slave (target).
The BP does not include common bus features such as out-of-order processing of transactions, bus locking or semaphores, or sophisticated addressing modes, but even without these features a huge number of components will find it a superset of their bus functionality. For example, all components following the OCP-IP consensus profiles should be able to use the BP unmodified, even though the BP is not in any way OCPspecific. At this level of abstraction the fact that a bus interface is OCP in the hardware becomes irrelevant and TLM models enjoy a much higher degree of interoperability than the hardware they represent. OCP components might plug directly to CoreConnect™ components, for example.
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
Layered TLM Technology for Multiple Levels of Abstraction
|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() |
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. |
|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. |
|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()
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...
- a single payload object carrying the necessary information about the transaction, to which references are exchanged by function call between components.
- 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
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.
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.
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. |
| || || |