6.2.2. Typical Data Transfers
This section defines the transfer of data from a source interface to a sink interface. In all cases, the data source and the data sink must comply with the specification. It is not the responsibility of the data sink to detect source protocol errors.
The above figure shows a typical credit and data transfer between source and sink. There can be an arbitrary delay between the sink asserting update and source receiving the update. Similarly, there can be an arbitrary delay between source asserting valid for data and sink receiving that data. Delay on credit path from sink to source and data path from source to sink need not be equal. These delays can be 0 cycle as well, i.e. when the sink asserts update, it is seen by the source in the same cycle. Conversely, when the source asserts valid, it is seen by the sink in the same cycle. If source has zero credits, it cannot assert valid. Transferred credits are cumulative. If sink has transferred credits equal to its maxCredit property, and has not received any data, it cannot assert update until it receives at least 1 data or has received a return_credit pulse from the source.
Sink cannot backpressure data from source if sink has provided credits to the source, i.e. sink must accept data from source if there are outstanding credits. Source cannot assert valid if it has not received any credit or exhausted the credits received, i.e. already sent the data in lieu of credits received.
If source has zero credits, source cannot start the data transfer in the same cycle it receives credits. Similarly, if sink has transferred credits equal to its maxCredit property and it receives data, sink cannot send an update in the same cycle as it received data. These restrictions have been put in place to avoid combinational loops in the implementation.
Did you find the information on this page useful?