| 1: |
What is the definition of a core? |
| A: |
A core is a semiconductor component that provides a processing
function. A core may contain many other cores as subcomponents. But,
such subcomponent cores are not directly accessible except by other
subcomponent cores within the larger core. Finally, a core might also
be a logic bridge to popular busses such as PCI and AMBA. |
|
| 2: |
What is the OCP? |
| A: |
The Open Core Protocol (OCP) is an efficient, frugal, core
connection standard. It interconnects two semiconductor cores on a
single integrated circuit so that they can reliably communicate when
synthesized and manufactured. |
|
| 3: |
What comprises OCP? |
| A: |
OCP specifies a signal exchange protocol over a family of on-chip
core interfaces. OCP is an interface family because it is a structured
architecture that allows many different configurations. |
|
| 4: |
How flexible is OCP? |
| A: |
OCP is very flexible. Many OCP signal groups, such as the data
signal group, have various widths that designers can select. Other
groups are completely optional. Thus, OCP enables System-on-Chip (SoC)
designers a structured but highly configurable interface. |
|
| 5: |
Which interfaces can OCP be used for? |
| A: |
The OCP interface can be used for any interface. It was not
designed to be used only with "user visible" interfaces. There are, in
fact, many benefits to using the OCP interface for "private"
interfaces. First of all, using a standard makes it easier to develop
the interface and support it in the future. In addition, the OCP
interface is by its very nature designed to be core-centric, so that
you would only need to use the features of OCP that are needed by a
particular IP core. |
|
| 6: |
How does OCP handle analog signals? |
| A: |
OCP is a protocol standard for digital virtual components. As such it only deals with digital signals. |
|
| 7: |
Has the OCP been implemented in any other language (SystemC, C++, Fortran, etc.)? |
| A: |
OCP-IP recognizes the importance to its members of representing the
OCP standard socket in SystemC and so has taken appropriate action
through its System-Level Design Working Group. OCP-IP had shipped many
thousands of TLMs and work in conjunction with OSCI in maintaining a
common set of industry models for TLMs. SystemC OCP models and examples
are available from the OCP-IP Web site. In addition, OCP-IP GSC member,
Sonics, Inc., has developed some C++ models for OCP interfaces without
the use of SystemC, but as we understand it, these are not commercially
available products. This however, illustrates the feasibility of
developing C-level interfaces for OCP through various approaches. |
|
| 8: |
Is an OCP connection a peer-to-peer connection? |
| A: |
No. OCP provides a master/slave connection between two cores. One
core, called the OCP initiator core, has an OCP master interface. A
master interface enables a core to generate OCP requests such as READ
or WRITE and receive the READ responses. The other core, called the OCP
target core, has an OCP slave interface which allows it to receive and
respond to requests. Thus OCP fits better into the client/server model,
with the master as the client and the slave providing a service. |
|
| 9: |
What if two cores require peer-to-peer communication? |
| A: |
In this case, you should provide both cores with two OCP
interfaces, both a master and slave interface. The master on each core
then connects to the slave on the other. |
|
| 10: |
Wouldn't two OCP interfaces require a lot of die size? |
| A: |
No. Because OCP is so frugal, having two OCP interfaces between the same two cores virtually never poses any problems. |
|
| 11: |
Can any two cores with OCP interfaces communicate? |
| A: |
No. First, masters can only communicate with slaves and slaves can
only communicate with masters. Second, a master and a slave must have
"similar" OCP interfaces in order to be compatible. The OCP
specification includes a precise definition of "similar." |
|
| 12: |
What if two cores have similar, but not identical, OCP interfaces? |
| A: |
OCP enumerates various signal tie-off rules and protocol behaviors
that allow many similar cores to interface even though their OCP
interfaces are not identical. |
|
| 13: |
Is OCP really just another bus? |
| A: |
No. A bus typically interconnects more than two cores. OCP is a
simple interconnect between two cores. Moreover, a bus does not have
the high degree of configurability that OCP does. The core might be a
logic bridge to another bus such as PCI or AMBA. So, if you need a
specific bus in your design, you can add it if you have an OCP bridge. |
|
| 14: |
What is the OCP word size? |
| A: |
The maximum number of data bits an OCP interface can transfer in a
single operation is called the word size for that OCP interface. |
|
| 15: |
How big can the OCP word size be? |
| A: |
OCP allows various, selectable width data transfers. Presently
allowed word sizes are 8, 16, 32, 64 and 128 bits. This restriction was
removed in the 2.0 version of the OCP specification, where the OCP word
size would be configurable without a specific range of values. |
|
| 16: |
Is OCP big or little endian? |
| A: |
OCP is little endian with respect to bit numbering, but it is
largely endian-neutral with respect to addressing. Only whole words are
addressed, and byte lane enables are provided for each byte within a
word. So address bits are not directly associated with byte lanes. This
makes adaptation to either big or little endian cores simpler. The
newer OCP 2.0 specification extends the notion of endian neutrality
even farther. Interfaces can be declared as either big or little
endian, endian-agnostic (such as a memory that doesn't care), or
endian-programmable (such as a core with byte swapping logic). |
|
| 17: |
How do I connect my big endian core using OCP? |
| A: |
You create a small logic bridge that converts (byte swaps) the
core's native big endian transfer logic to OCP's little endian transfer
style. |
|
| 18: |
What OCP compliant cores are available? |
| A: |
The number of compliant cores is constantly increasing. Newer cores
use OCP as the native interface. Cores that predate OCP, called legacy
cores, can incorporate bridging logic to present an OCP interface. |
|
| 19: |
What is an OCP bridge? |
| A: |
When bridge logic provides an OCP interface for a legacy core, the bridge logic is called an OCP bridge. |
|
| 20: |
Does the OCP specification cover scratch pad RAMs? |
| A: |
In the case of the scratch-pad memory, you could use a very simple
OCP interface, consisting of the OCP basic features, along with making
use of the "byte enable" option. You would also need to appropriately
set the address and data widths for the scratch-pad memory. Thus, an
OCP interface for the scratch-pad memory can be very simple and not
involve a lot of overhead, either in terms of development time or in
terms of hardware/gates. |
|
| 21: |
Does the OCP specification support transaction protocols? |
| A: |
OCP itself is a full featured and complete transaction protocol. It
is capable of handling all types of point-to-point data transfers using
an address and data bus as well as a full compliment of configurable
control/datahandshaking signals. OCP is more than just a data protocol;
it actually specifies an entire socket, which captures the complete
signal set emanating from a core. All of the signals, data protocol,
test, control and status are subsumed into the OCP socket
specification. This is unique in the industry. |
|
| 22: |
Does the OCP specification provide templates for common types of interfaces? |
| A: |
Yes, the OCP 2.1 Specification provides a set of templates for
different types of IP core OCP interfaces. This is done through the use
of OCP Profiles. Each of these profiles includes predefined OCP
interfaces, along with settings for the various OCP configuration
parameters. Additionally, implementation guidelines are provided for
each of these OCP Profiles. |
|
| 23: |
What OCP Profiles currently exist? |
| A: |
With the OCP 2.1 Specification, two sets of OCP Profiles are
provided: new profiles for new IP cores using a native OCP interface,
and bridging profiles which are used for bridges between OCP and other
bus protocols. The set of new OCP Profiles includes profiles for the
block data flow model, the sequential undefined length data flow model
and the register access model. The set of bridging OCP Profiles
includes profiles for the Simple H-Bus (used for Amba) and the X-Bus
packet write and X-Bus packet read profiles (used for AXI).
With the OCP 3.0 Specification, three additional OCP Profiles are
provided: the Simple Slave Profile (for peripheral subsystems), the
High-Speed and Advanced High-Speed Profiles (for high throughput
multi-processor subsystems). |
|
| 24: |
How is security handled by OCP? |
| A: |
The OCP interface can be used to create secure domains across a
system. Such domains might include a CPU, shared memory, or I/O
subsystems. The OCP master drives the security level for a request by
using the MSecure signal to define security access modes, along with
using MConnID to identify a specific target in the system for the
request. This MSecure signal is a user-defined subnet of the MReqInfo
signal. |
|
| 25: |
Does OCP provide any support for divided clocks? |
| A: |
Yes, divided clocks can be directly handled by making use of the
EnableClk clocking signal. This EnableClk signal is used to indicate
which rising edges of the Clk signal are rising edges of the OCP clock.
This dynamic clock frequency control can be easily adapted to handle
divided clocks for an OCP interface. |
|
| 26: |
Does OCP provide support for cache coherency? |
| A: |
Although cache coherency may be present for an individual processor
in a system, it is also important to provide cache coherency throughout
a multi-processor system, which typically has a number of different
caches. This system-level cache coherency can be supported by OCP
through the use of special cache coherence transactions. These
transactions can be used to invalidate cache lines throughout the
system and thereby ensure that cached data is consistent. |
|
| 27: |
Does OCP provide support for power management? |
| A: |
In order to apply power management techniques to individual cores
in a system, it is first necessary to properly "shut down" these cores.
This can best be handled using the disconnect mechanism for the OCP
protocol, which ensures that no outstanding OCP transactions are
corrupted or left hanging. |
|
| 28: |
How does the OCP disconnect mechanism differ from the OCP reset? |
| A: |
When an OCP reset is asserted by either the Master or the Slave,
then any open transactions are simply "thrown away." By contrast, the
OCP disconnect mechanism allows both the Master and Slave to properly
handle any open transactions, before disconnecting from the existing
OCP interface. |
|
