English
Insuring silicon Intellectual Property interoperability with OCP consensus profiles
By Vesa Lahtinen, Yasumasa Nakada, Christophe Sucur and Drew Wingard, OCP-IP Specification Working Group
Embedded.com -- (05/13/08, 12:05:00 AM EDT)
The ability to use internally and externally developed IP (Intellectual Property) cores in ASIC creation is essential to achieving high quality products and time-to-market for any designer of ASICs and SoCs.
Since 2001, OCP-IP (Open Core Protocol " International Partnership) consortium has provided an open standard synchronous protocol for point-to-point interconnection of IP modules.
OCP has a wide range of configuration parameters which makes OCP uniquely easy to be optimized to fit the varying demands of a wide range of IP cores and systems.
When the parameterization of the master and slave interfaces do not match, the protocol defines a set of rules that both ensure interoperability wherever possible, and describes behavioral restrictions on the master and/or slave to increase interoperability.
When the interface parameterization differs sufficiently that key master or slave functionality is not supported by the other side, protocol conversion bridging is occasionally required. When the IP cores that are inconsistent are separated by a shared interconnect, it is sometimes a role of the interconnect to provide this protocol conversion.
Embedded.com -- (05/13/08, 12:05:00 AM EDT)
The ability to use internally and externally developed IP (Intellectual Property) cores in ASIC creation is essential to achieving high quality products and time-to-market for any designer of ASICs and SoCs.
Since 2001, OCP-IP (Open Core Protocol " International Partnership) consortium has provided an open standard synchronous protocol for point-to-point interconnection of IP modules.
OCP has a wide range of configuration parameters which makes OCP uniquely easy to be optimized to fit the varying demands of a wide range of IP cores and systems.
When the parameterization of the master and slave interfaces do not match, the protocol defines a set of rules that both ensure interoperability wherever possible, and describes behavioral restrictions on the master and/or slave to increase interoperability.
When the interface parameterization differs sufficiently that key master or slave functionality is not supported by the other side, protocol conversion bridging is occasionally required. When the IP cores that are inconsistent are separated by a shared interconnect, it is sometimes a role of the interconnect to provide this protocol conversion.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
Related Articles
- Silicon Intellectual Property - Delivering value to customers
- Three Major Inflection Points for Sourcing Bluetooth Intellectual Property
- Design Rights Management of Intellectual Property (IP) Cores in SoPC designs
- Intellectual property security: A challenge for embedded systems developers
- Ensuring Successful Third Party Intellectual Property (IP) Integration
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)