OCP 'tags' support high-performance SoCs

 
Increasing design complexities in deep sub-micron systems on chip (SoCs) have forced designers to adopt a communications centric approach to cope with the corresponding increase in the design productivity gap. These communications-centric interfaces define a modular socket interface and do not constrain the implementation of the actual SoC interconnect [5] to any particular topology or physical layer.

In this paper we focus on the Open Core Protocol (OCP) [6], one of the first protocols to adopt a non-proprietary, open standards based, on-chip protocol with independence from the physical transport. This independence allows implementers to scale and choose an interconnect topology and parameters which provide commensurate performance to a number of high performance SoCs.

The challenge

For high performance, the OCP 2.0 specification provides "threads" that a designer can use to send multiple independent transactions on the same set of shared wires. This is very useful for certain agents, such as multi-channel DMA cores, which multiplex many independent channels on to a physical OCP port.

However, some cores, most notably high performance processor cores, have slightly different needs. Their programming model dictates a high performance out-of-order data return mechanism with the least area cost penalty, calling for a lighter mechanism than threads called tags1. The complete channel separation of threads and its associated penalty due to independent flow control for each thread is not optimum for these cores.

The obvious solution of mapping tags to threads to work around this problem would be cumbersome, as threads are completely independent and would require the addition of logic to the processor core in order to resolve memory hazards occurring between threads. As an example, a load and a store from two different threads could be to the same target address, and because threads do not guarantee any order between two threads, the load could return the value of memory before or after the store, resulting in a hazard.

So in the OCP-IP Specification Working Group (SWG) we set about defining a tagging extension to OCP-IP version 2.0. This was the main extension to the specification when the version number of the specification was moved up from 2.0 to 2.1.

To read the full article, click here