|
| 5: |
What differs between the 2.2 and 3.0 versions of the OCP Specification? |
| A: |
The OCP 3.0 Specification includes a number of major enhancements,
including support for system-level cache coherency for multi-processor
systems. In addition, a disconnect mechanism was added to support the
application of power management techniques to individual cores in a
system. Finally, three new OCP Profiles (Simple Slave, High-Speed and
Advanced High-Speed) were added to the OCP Specification. |
|
| 6: |
What is the purpose of lazy synchronization? |
| A: |
Lazy synchronization is an enhancement to the protocol featured in
2.0. It recognizes existing microprocessor synchronization practices
and eases the problems in synchronizing multiprocessor SoC designs. The
2.0 enhancement adds a non-blocking semaphore command in addition to
the existing blocking semaphore command in recognition of non-blocking
capability in some existing embedded processors. |
|
| 7: |
Which version of the OCP Specification should I use? |
| A: |
Generally, if you are starting a new design, you should use OCP
3.0. This is the direction of OCP, and it includes a number of
improvements based upon real user experiences. Understanding 3.0 is
always helpful, as it helps you utilize previous specification features
in a way that is forward compatible. |
|
| 8: |
2.0 has been referred to as allowing a "minimalist" interface. What does that mean? |
| A: |
By "minimalist", we simply mean using very few wires. The minimum
OCP 1.0 interface has six required fields: ocp_clock, MCmd, MAddr,
MData, SData, and SResp. That's pretty frugal. But, the minimum OCP 2.0
interface has only two required fields: ocp_clock and MCmd. That's
minimalist. |
|
| 9: |
What parameter controls have responses for write commands? |
| A: |
Please note that the capability of non-posted writes is not
actually in the OCP Specification version 1.0. The capability of
non-posted writes is in version 2.0 of the OCP Specification. In the
1.0 version of the specification, all writes are required to be posted
writes. However in the OCP 2.0 Specification, the "writeresp_enable"
parameter will be used to indicate that responses should be generated
for write commands, so that non-posted write semantics can be supported. |
|
| 10: |
What will be the behavior of an OCP master in the case where the
slave generates the response phase for write commands (in posted write
model)? |
| A: |
In the case of the version 1.0 specification, it would not be legal
for the slave to generate a response to the write operation, since all
writes are required to be posted writes. Thus, this would actually be a
violation of the OCP protocol. However, this would be allowed in the
2.0 version of the specification. |
|
| 11: |
How are the master and slave reset signals asserted in different OCP versions? |
| A: |
In the OCP 2.2 versions, reset signals for the master and slave can
be asserted either synchronously or asynchronously. In earlier
versions, all resets were required to be asserted synchronously. Note
that in OCP version 1.0, there was only a single reset signal; the
provision for separate master and slave reset signals was provided in
OCP version 2.0. |
