Utilizing OCP to design a high performance interconnect

In designing the high-speed interconnect core Z-core InterConnect MIIX, engineers at the Zuken SoC Design Center (now known as Inventure) decided that system performance could be increased using split transaction technology in the inner bus. During the evolutionary transition from PCI to PCI Express, the split transaction concept was adopted for Inventure's Z-core PCI Express. In short, split transaction enables command execution before the response to the previous command. The split transaction technique spread from the CPU world to the system bus world such as PCI Express, and subsequently was adopted for use in the inner bus.

During its initial research the team discovered that the OCP standard already contained split transaction capability. Inventure did not implement the entire OCP standard, but made use of many parts of the OCP throughout the design process. The Inventure MIIX interconnect and the OCP standard are focused on improving overall system performance.

MIIX provides high-speed interconnection using the split transaction feature available in OCP2.0. Through an easy to use GUI, designers can customize MIIX. Inventure is providing "platform IP", where several different IP cores are combined in a pre-configured fashion with an OCP based interconnect, to provide a complete System-On-Chip design solution. The MIIX interconnect serves as the backbone for this platform IP concept.

1. OCP based interconnect core used as a backbone of a platform IP

OCP is a complete synchronous type interface standard established by OCP-IP for the purpose of providing plug-and-play IP design. The specification, available at www.ocpip.org without charge provides a strict definition of interfaces to easily connect each IP. Designers can freely configure OCP in accordance with the characteristic features of their own IP. Designers can implement an optimum interface circuitry with the required signals by utilizing only the necessary bit width.. OCP is often seen as an extension of other bus protocols such as AHB, but OCP is an interface standard not a bus standard. It allows for a one-on-one connection between OCP Master and an OCP Slave. If designers desire to make multiple connections, an interconnect module is required.

When Inventure began the project, focus was placed on the following: criteria:

1. The IP should be simple, high-performance and low latency. To achieve this, the IP is configured without inner memory to satisfy both latency and throughput.
2. Must make use of the new burst model in OCP version 2.0, which includes the use of Single Request Multiple Data (SRMD) bursts, which can be used to achieve packet-like transaction. In addition, use the reqdata_together configuration parameter to simplify the OCP protocol phases, by forcing the OCP request and datahandshake phases to take place during the same cycle avoiding unnecessary precedent issuance of the write commands.
3. Users should be able to easily predict at the system design level how their designed system will perform. In other words, MIIX is not intended to be multifunctional but rather high-performance.
4. User friendly IP. The user can easily customize and debug through GUI.
5. High connect ability to Inventure's existing PCI Express IP.

Traditional interlock type systems issue a request only after accepting the response of the previous request. This means each transaction is affected by latency. Split transaction, on the other hand, can issue consecutive commands without waiting for a response to the previous command (Figure 2). So, only the first latency will generate latency and there will be no latency after that. This mechanism is essential for the system which has long access latency.

2.An interlocking bus generates more latency than a split bus

OCP can execute the split transaction due to three independent phases. The Request Phase issues request, the Data Handshake Phase transmits the write data and the Response Phase transmits read data and responses. These three phases are independent. Note that these OCP phases can be pipelined; for example, any request does not have to have a completed response before the OCP master can issue another request. The OCP interface is inherently pipelined, providing a solution for increased system performance.

How these phases work together is illustrated in Figure 3. In the case of Posted Write, the "Request Phase" comes first where Master issues a command to the Slave. The "Data Handshake Phase" follows. The Master transfers the write data to the Slave independently of the requests.

In the case of NonPostedWrite, the "Response phase" is added to the Posted Write case. The "Response phase" initiates a response from the Slave when the write is finished. In the case of "Read", where the read data is transferred, the response phase follows the request phase. This is the mechanism which executes the "Split Transaction".

3.A split transaction has three phases

OCP defines the signals of the three Phases. From the signals defined by OCP, the critical signals of clock and reset commands are chosen. And then signals such as address, write data path, read data path, burst signal and flow control signal are chosen when needed.

Signals starting with the letter M go from Master to Slave while signals starting with the letter S run from Slave to Master. Clock signals do not follow the convention since they are supplied to both Master and Slave. The designer has a wide variety of signal configurations for the OCP interface to meet the needs of each IP core.