| 1: |
What exactly are threads? |
| A: |
A thread is a request sequence that always maintains its order.
That is, a thread never has out-of-order request delivery, execution
or responses. |
|
| 2: |
Why use threads? |
| A: |
Threads allow the inherent concurrency available in the cores to
be represented. This is typically done to avoid performance loss.
Without threads, multiple concurrent request sequences must be
interleaved and time multiplexed into one sequence. Any delays
encountered by any request impacts all requests after it, and
therefore all concurrent sequences. By labeling each request as
belonging to a distinct thread, the target core is free to re-order
execution in order to optimize.
With OCP, the minimum number of threads a core can have is one.
Moreover, all requests are associated with a thread. However, an
initiator core might need a target core to resolve a high priority
request before other requests it might have generated. However,
within any single thread, all requests and their responses must
remain in order.
Hence, with only one thread, the high priority request would only be
processed after all preceding requests are handled. Reserving a
thread for priority requests allows the second thread to maintain its
order, while allowing the priority request to execute before older,
lower priority requests execute.
Other examples include multi-bank DRAM controller configurations
where each DRAM bank has a unique associated thread. In this
instance, a DRAM controller can significantly increase its DRAM
access concurrency since all banks can theoretically be
simultaneously active. |
|
| 3: |
What is the maximum number of threads a core can
have? |
| A: |
The OCP architecture does not limit the number of threads that a
core may have. Practical matters however do limit. A master core can
only present one command at a time. Thus if multiple threads are
active, it must internally arbitrate to select one to present on the
OCP. IP core performance will be lowered as the number of threads is
increased. Similarly, slaves will often incur storage costs
associated with threads. So gate counts will provide motivation to
keep thread counts to a reasonable number. |
|
| 4: |
Why would I need multiple threads? |
| A: |
The primary use for multiple threads is for simultaneous but
unrelated activities. A classic example is something like an Ethernet
MAC that has both transmit and receive streams, so that each stream
would be on a unique thread. |
|
| 5: |
What is the timing (relative to the phases) of the MThreadID
signals? |
| A: |
The number of phases associated with a write request is one when
Data handshaking is not enabled. Here, the thread ID signal is valid
when the write command is valid (the MThreadID signal is in the
request group). When data handshaking is enabled, the datathreadID
signal is valid when the write data is valid (the MDataThreadID
signal is in the data handshake group).
For read transfers, the threadID signal is valid when the read
command is valid (again, the MThreadID signal is in the request
group). When the slave returns the data, the threadID signal is valid
when the read data is valid (the SThreadID signal is in the response
group). |
|
| 6: |
What is the implication of the master/slave reset on the
executing thread? |
| A: |
Reset should always cancel or complete any pending OCP requests
by the master or responses by the slave. Otherwise, if slaves were to
return data after reset in response to a command sent before reset,
then the state of the system would not be properly initialized by the
reset. The OCP specification also requires that reset must be
asserted for at least 16 clock cycles, in order to allow both the
master and the slave to reach a consistent internal states. |
|
| 7: |
How can a core achieve priority processing? |
| A: |
By supplying more than one thread, normal traffic can use one
thread, while high priority requests use another. Though requests are
handled in order for a single thread, this does not apply to requests
from different threads. Requests from different threads can be
handled out of order, allowing processing prioritization. |
|
| 8: |
What is the Connection ID on the OCP used for? |
| A: |
Connection IDs are similar to threads, but are global in scope
rather than local in scope. The connection ID allows for the
identification of transfers between a system initiator core and a
system target core. Note that the thread information a target
receives is for the local OCP connection while the connection ID
persists across intermediary transports. |
|
| 9: |
How do threads differ from connections? |
| A: |
Threads are associated with an OCP interface. However, if core A
connects to core B which connects to core C, core C receives no core
A OCP thread information for requests core B relays to core C. The
only core information comes from the OCP connection between core B
and core C.
Connections are an OCP signal provision that allow Core A to tag
requests with a global identifier that clearly identifies the origin
of the request. Connection IDs are very important in SOC designs
comprised of numerous initiators and targets because it allows OCP
initiator cores to assign identifying information to requests that
span intermediary OCP interface transmissions. |
|
| 10: |
Can a single slave be connected to multiple masters? If not,
then how are shared memories done? With OCP being a point to point
connection, is there a protocol in OCP for connecting multiple
processors to a memory controller? |
| A: |
A MicroNetwork does two things: it connects multiple slaves to
masters and it connects multiple masters to specific slaves. The
latter allows sharing of a slave with a single OCP point-to-point
connection among multiple masters. This is exactly analogous to the
function of a conventional computer bus. This MicroNetwork would use
OCP to interface to each of the master and slave cores in the
system.
It is perfectly feasible for a slave to have multiple OCP interfaces
- for instance, a multi-ported SRAM memory.
The OCP interface standard, unlike many conventional bus protocols,
optionally incorporates threading. Threading allows transactions to
be tagged, and, on the basis of that tag, to be treated differently.
This allows for dataflows from different masters to be identified by
slave cores, facilitates differential quality of service to distinct
data streams and often improves performance by allowing transfer
reordering to suit subsystem timing constraints (e.g. in DRAM
controllers). |
|
| 11: |
What is tagging? |
| A: |
Recall that the OCP slave normally returns responses to requests
made by the OCP master in the same order in which the requests were
issued by the OCP master. However, sometimes it makes more sense for
the OCP slave to determine when responses should be returned to the
OCP master. Tags can be used to directly link the response with the
original request which triggered the response from the OCP slave. In
many cases, the use of tags can improve overall system
performance. |
|
| 12: |
How do tags differ from threads? |
| A: |
Tags can be thought of as being more “lightweight” than threads
for providing out-of-order responses. In particular, multiple threads
provide independent flow control for each thread, while tags use a
single shared flow of control for all tags. Also, there are no
ordering rules for transactions on different threads, while tagged
transactions can not be re-ordered. Finally, independent buffering is
required for each thread, while there are no buffering requirements
for tags, since the flow control is shared between all tags. |
|
| 13: |
What kind of flow control can be used with threads? |
| A: |
In order to allow a core to handle requests on one thread while
it is busy processing requests on another thread, several “thread
busy” flow control signals are provided. The slave can use the
SThreadBusy signal to indicate to the master that no more requests
should be made on a particular thread. In a similar fashion, the
MThreadBusy signal can be used by the master to signal to the slave
that no more responses should be issued for a particular thread. The
SDataThreadBusy signal is also provided for the slave to signal to
the master that it can not accept any more data handshake phases on a
particular thread. |
|
| 14: |
How do I prevent blocking when multiple threads are
used? |
| A: |
Note that the different “thread busy” signals have no phased
timing requirements from the viewpoint of the OCP protocol, so that
they can only be treated as a hint between the master and the slave.
In order to ensure that blocking does not take place, there are
configuration parameters for each of these “thread busy” signals to
force the master or slave to follow exact “thread busy”
semantics. |
|
