OCP 'tags' support high-performance SoCs
Sanjay Vishin, MIPS Technologies
(05/08/2006 12:09 AM EDT), EE Times
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.
(05/08/2006 12:09 AM EDT), EE Times
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
Related Semiconductor IP
- TSMC 7nm 0V75 / 0V9 ESD Local Clamp – Low Cap
- TSMC 65nm 3V3 ESD Local Clamp – Rad Hard
- TSMC 5nm 1V8, 1.2V and 0.9V ESD Local Protection – Low Cap
- TSMC 3nm 3V3 ESD Local Clamp
- TSMC 3nm 1V2 ESD Local Clamp – Low Capacitance
Related Articles
- Utilizing OCP to design a high performance interconnect
- Enabling High Performance SoCs Through Multi-Die Re-use
- A Flexible, Low Power, High Performance DSP IP Core for Programmable Systems-on-Chip
- High Performance Connectivity IP -- Avoiding Pitfalls When Selecting An IP Vendor
Latest Articles
- LACE: Large Language Model Aided Multi-Agent Framework for Agile RISC-V Instruction Extension
- A Process-Aware Hybrid Si/IGO Monolithic-3D 6T SRAM with BEOL Pass-Gates for the 2nm Node
- Automated Estimation of MBIST Area and Test Time in Heterogeneous Memory IPs via Stacked Ensemble Framework
- VIPER: Architecture-Aware Performance Modeling for Processing-in-Memory Design-Space Exploration
- CTTE: An Open Dual-Protocol RISC-V Trace Encoder for N-Trace and E-Trace