English
Got OCP? The Role of the OCP in Multicore Designs
By Clive "Max" Maxfield
Embedded.com (11/09/08, 04:30:00 PM EST)
When I began my career way back in the mists of time ("When dinosaurs ruled the Earth"), things were so much simpler than they are today. As a simple example, microprocessors were understandable by almost anyone who cared to experiment with them. Ah, the joy of playing with an 8-bit data bus, a 16-bit address bus, and a handful of general-purpose registers.
By comparison, today's high-end System-on-Chip (SoC) designs boggle the mind and defy description. Comprising tens or hundreds of millions of logic gates, these beasts typically feature multiple processor cores performing different tasks, tiered memory structures with multi-level memory caching, and multi-layer bus structures (and don't get me talking about super-pipelining and super-scaling).
The problem is that the vast majority of these bits-and-pieces " like the processor cores and other functions " come in the form of third-party IP blocks. The process of building an SoC involves gathering processor, peripheral, and memory cores from a wide variety of sources. Furthermore, there is a temporal aspect, because these cores may have originated at different times.
The function of a core dictates its interface to the outside world (in the form of the rest of the chip). There's no way we can expect that everyone who created cores at different times in different places for different purposes all made the same decisions. Thus, the designers of a modern SoC are in the position of constructing the chip out of functional units that they did not themselves devise, and that they almost certainly do not understand at some level.
(If designers did need to fully understand the internals of each and every core, they might as well design them all from the ground up, which would result in a new chip reaching the market once every hundred years or so.)
Obviously, some way to address these multicore problems is required. But fear not my braves ("There's nothing to fear, but fear itself," as my dear old dad used to say), because there is a solution in the form of the OCP (Open Core Protocol). In order to wrap our brains around this we need to ask (and answer) three fundamental questions:
Embedded.com (11/09/08, 04:30:00 PM EST)
When I began my career way back in the mists of time ("When dinosaurs ruled the Earth"), things were so much simpler than they are today. As a simple example, microprocessors were understandable by almost anyone who cared to experiment with them. Ah, the joy of playing with an 8-bit data bus, a 16-bit address bus, and a handful of general-purpose registers.
By comparison, today's high-end System-on-Chip (SoC) designs boggle the mind and defy description. Comprising tens or hundreds of millions of logic gates, these beasts typically feature multiple processor cores performing different tasks, tiered memory structures with multi-level memory caching, and multi-layer bus structures (and don't get me talking about super-pipelining and super-scaling).
The problem is that the vast majority of these bits-and-pieces " like the processor cores and other functions " come in the form of third-party IP blocks. The process of building an SoC involves gathering processor, peripheral, and memory cores from a wide variety of sources. Furthermore, there is a temporal aspect, because these cores may have originated at different times.
The function of a core dictates its interface to the outside world (in the form of the rest of the chip). There's no way we can expect that everyone who created cores at different times in different places for different purposes all made the same decisions. Thus, the designers of a modern SoC are in the position of constructing the chip out of functional units that they did not themselves devise, and that they almost certainly do not understand at some level.
(If designers did need to fully understand the internals of each and every core, they might as well design them all from the ground up, which would result in a new chip reaching the market once every hundred years or so.)
Obviously, some way to address these multicore problems is required. But fear not my braves ("There's nothing to fear, but fear itself," as my dear old dad used to say), because there is a solution in the form of the OCP (Open Core Protocol). In order to wrap our brains around this we need to ask (and answer) three fundamental questions:
- What is a multicore design?
- What is a socket?
- What is the OCP?
|
E-mail This Article | 
|
|
Printer-Friendly Page |
Related Articles
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)