The OBI – OFFIS Bus Interface was a project that aimed at the development of a common interface for various bus architectures. A typical System-on-a-chip (SoC) consists of different components, which are connected through a communication infrastructure. Several combinations of communication infrastructure and components are feasible. Thus, designing complex embedded micro-electronic systems requires a vast exploration of the design space. During these explorations different and competing optimisation goals should be reached. For example:
Virtual platforms are a good way for comparing different design alternatives. They give a good basis for various decisions during the design process.
Most complex systems are not developed from scratch. In order to save development time existing components are reused, if it is possible. Functionalities that have not implemented, yet and cannot be bought from a third party vendor still need to be newly developed. Enabling the reuse of pre-existing components requires generic interfaces. These have to support a large number of platforms i. e., communication structures. Various commercial suppliers provide buses and other communications infrastructures that can be used in a SoC. In order to be able to interchange these structures, development of components must be done independently from communication infrastructure. That is, an interface must be developed that allows using components particular components independently from the later used communication infrastructure.
During the project different communication architectures have been analysed with respect to their commonalities and a generic interface have been developed. Using transactors different buses can be connected to this generic interface, as the following figure shows.
Currently three architectures are supported. These include the ARM Advanced High-speed bus (ARM AMBA AHB), the IBM Core Connect On-Chip peripheral bus (OPB) as well as the OpenCores WHISHBONE.
During the project bus architectures as well as their underlying state machines of the bus masters and slaves have been analysed and compared with each other. For each communication infrastructure a master as well as a slave transactor has been developed and implemented. The transactor translates the protocol of the generic interface into the protocol of the concrete infrastructure used for communication. As can be seen in the following figure, the OPB requires an additional arbiter for arbitrating the access to the bus.
For the evaluation of the implementation a simple syntax for a so-called command file has been developed. The command file allows repeated execution of equal read and write accesses to the bus, independent from the used type of the bus master. This way it is possible to use one test case for different implementations of the design. Despite the correctness of the implementation it had been shown, that introducing the transactors causes only a minimal delay. It is important to note that the transactors for slave are significantly smaller than the transactors for masters. The additional required chip area can be neglected.