The ability to use internally and externally developed IP (Intellectual Property) cores in ASIC creation is essential toachieving high quality products and time-to-market for any designer ofASICs and SoCs.
Since 2001, OCP-IP (Open Core Protocol ” InternationalPartnership ) consortium has provided an open standardsynchronous protocol for point-to-point interconnection of IP modules.
OCP has a wide range of configuration parameters which makes OCPuniquely easy to be optimized to fit the varying demands of a widerange of IP cores and systems.
When the parameterization of the master and slave interfaces do notmatch, the protocol defines a set of rules that both ensureinteroperability wherever possible, and describes behavioralrestrictions on the master and/or slave to increase interoperability.
When the interface parameterization differs sufficiently that keymaster or slave functionality is not supported by the other side,protocol conversion bridging is occasionally required. When the IPcores that are inconsistent are separated by a shared interconnect, itis sometimes a role of the interconnect to provide this protocolconversion.
As an alternative, system companies like Nokia, Texas Instrumentsand Toshiba have defined their own internal OCP subsets or profileswhich provide company engineers with standardized configurations of OCPoptions for specific system use cases, ensuring interoperabilitywithout conversion.
Based on this work, OCP 2.1 defined a first set of profilestargeted at new OCP users. The intent was to give examples of optimizedOCP interface configurations for standard communication functions, suchas block data flow or register access, to help map the requirements ofa new IP block designs to the relevant OCP configuration parameters.These profiles were intended to be starting points to the actualinterface definition for such cores.
The idea behind the consensus profiles is to extend the concept ofprofiles to a higher level and to define a unified set of OCPinterfaces for all OCP users to utilize. This will make it easier forsystem houses, IP providers, and EDA vendors to develop matchingOCP-based solutions.
In fact, part of the original pressure to develop a set of jointprofiles came from an IP provider, namely Synopsys, who was faced withthe daunting task of perhaps needing to match each of the internallystandardized OCP profiles of the various system houses.
The definition work was started by Nokia, Texas Instruments andToshiba in early of 2007 when they exchanged their internal OCPprofiles with each other. Once an initial agreement was achievedbetween these three companies, the new profiles were finalized in theOCP-IP Specification Working Group including representatives fromSonics, STMicroelectronics and MIPS.
The profiles were defined during 2007; the first two of the profileswill be published as a document revision to the current OCPSpecification (OCP 2.2 Revision 1.1) in May 2008, and the third one inthe coming OCP 3.0.
Defining the profiles
Figure 1 below presents anexample system composed out of several IP cores. The shown IP cores canbe roughly divided into two groups: peripherals and processor subsystemcomponents.
The difference between them from an interconnect point-of view isthat peripherals are usually quite simple and would therefore utilize asimple (low area) interconnect and use only a small subset of theavailable OCP parameters, since the latency and throughput requirementsof the peripherals are normally quite relaxed.
On the other hand, the processor subsystem components require highthroughput and demand more advanced communication capabilities fromtheir high bandwidth interfaces and interconnects. Connecting the twotypes of interconnects together usually requires a bridge component.
In Figure 1, peripheral components are represented by interruptcontrollers, timers, and I/O devices. Processors, DMA engines, memorycontrollers, and graphics/video accelerators, on the other hand, aretypical processor subsystem components.
For these two use cases, three consensus profiles have been defined:Profile 1 titled “Simple slave profile”, Profile 2 titled “High-speedprofile”, and Profile 3 titled “Advanced high-speed profile”. Of these,Profile 1 is meant to be used by peripheral components, whereasProfiles 2 and 3 are targeted for processor subsystem components.
|Figure1. Open Core Protocol Profiles|
These profiles have been defined so that the complexity and area ofthe bridge component that handles potential interoperability issuesbetween the profiles is minimized. The coming OCP specifications willlist the minor potential interoperability issues across the profiles,and describe how to deal with them.
Some OCP features are so generic that their specific (consensus)usage is hard to define. They are left out of the features required bythe profiles as optional features and they can be used in systemdependent ways. Examples of features like these are tags and threads.Furthermore, it is allowed to use OCP signals delivering additionalinformation like MAddrSpace, MReqInfo, SRespInfo, MError, SError,MFlag, and SFlag.
Profile 1: Simple slave profile
The simple slave profile is defined for components that favor simpleimplementation over high throughput. The profile is limited to singleaccesses which means that burst accesses are not allowed. The supportedcommands are idle, read, posted write, and non-posted write.
To further simplify the interface, byte enable patterns are limitedto be power-of-two in size and aligned to that size. All endianessoptions can be used but it is required that components state theirendianess with the appropriate OCP configuration parameter.
For correct operation, slaves have to be able to support the wholedefined feature set. On the other hand, masters may restrict themselvesto that subset of the interface capability that they require.
As a final note, if a slave can accept commands on every cycle (i.e.it has no request phase flow control), it is allowed to permanently tiethe command accept signal of OCP asserted (i.e. high), explicitlyaccepting any OCP commands in the same clock cycle they are presentedto the interface.
Profile 2: High speed profile
The high-speed profile is defined for processor subsystem componentsthat require high throughput. The main additional features that areadded in comparison to Profile 1 are the response accept signal andmultiple-request multiple-data (MRMD) type bursts, which provide a fullrequest (including address) phase for each data beat of the burst.
Profile 2 bursts define precise length transactions with knownaddressing sequences, which offer higher transfer efficiencies whencompared with single accesses.
The efficiency improvement is drastic when targeting DRAMs, whichnatively access several words of data at a time and for which datalocality is essential to attain high memory utilization rates, andoverall system memory bandwidth.
The allowed burst address sequences are incrementing, wrapping, andstreaming (i.e. constant) addresses. This profile includes burstframing signals which can be used by the master to identify the lastrequest (including any associated write data) and by the slave toidentify the last response in a transaction.
These framing signals are introduced into Profile 2 to limit burstlength counting logic whenever possible. As in Profile 1, all slaveshave to be able to support the whole feature set defined in thisprofile.
Masters must support at least one of the allowed burst addressingsequences, but may still restrict themselves to a subset of theinterface capability. For instance, a master may only support one ofthe three OCP burst address sequences defined in this profile.
Profile 3: Advanced high-speedprofile
The advanced high-speed profile is also used in processor subsystemmodules that require high throughput like Profile 2, but the maintargets are systems that process a large amount of real-time data suchas high definition digital TV sets.
Optimized for their use, Profile 3 supports 2D block bursts in whicha rectangular data block can be transferred efficiently as a singletransfer.
In addition, Profile 3 allows using XOR-type (i.e. interleaved)burst address sequences for high-performance memory subsystems (such asDDR3 or XDR DRAMS) and exclusive reads for implementing synchronizationprimitives such as test-and-set, read-modify-write, or atomic swapsequences.
The data handshake phase is used in Profile 3 to enable independentflow control for write data. Lastly, single request-multiple data(SRMD) type bursts are strongly recommended for the efficientinitiation of high bandwidth data transfers.
Master devices using Profile 3 are strongly recommended to use SRMDonly but for compatibility with Profile 2, slave devices using Profile3 are also required to support MRMD bursts.
Where to next with OCP Profiles
The proposed profiles offer a consistent, well defined base of OCPinterfaces to the OCP community based upon experiences proven in realdesign environments. They will make it easier for IP providers and EDAtool vendors to target their OCP-compatible offerings.
In addition, they will make it easier for system houses to checkthat acquired tools and IP cores comply with their internal tool flows,IP cores, and interconnect components.
There is still, of course, room for system-specific orcompany-specific optimization of the interfaces. It is expected thatsuch optimizations will frequently be additive to these profiles,leveraging existing OCP capabilities, and thus ensuringinteroperability between IP cores using such optimizations and thoseusing the published profiles.
This flexibility to support unique system requirements continues tobe a clear advantage that the OCP interface definition has over other,statically defined, IP block interfaces.
The presented profile work has clearly demonstrated the value ofmulti-company co-operation in an open standardization forum and thejoint development of specifications.
In the ongoing development of OCP specifications, ideas can comefrom different types of member companies but the goal is to always findsolutions to existing issues that serve the whole community. Thepresented work is a good example of a process that was started by biguser companies but that in the end benefits everybody.
The current work at OCP-IP reported here has defined three profilesbut the work does not have to end here. If shared future use cases andinterface-requirements emerge, the Specification Working Group willextend the set of commonly agree profiles further.
The configurable structure of the OCP interface specification makesit ideally suited for an incremental development like this. Inaddition, there exists a proven willingness among the core OCP users todo so.
Vesa Lahtinen works in the Wireless Platforms unit of the