|
| 5: |
What differs between the 2.2 and 2.2 Rev 1.1 versions of
the OCP Specification? |
| A: |
The OCP 2.2 Rev 1.1 Specification incorporates published
errata and two consensus profiles developed by expert OCP users. A
trace file format (.ocp) was also added to this revision. |
|
| 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 2.2. This is the direction of OCP, and it includes a number of
improvements based upon real user experiences. Understanding 2.2
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. |
