Bus Operation Example - Bus Operation Example - 3.0 English - PG369

The following figure shows a simplified (that is, no sop or associated preamble information included) timing diagram to illustrate the use of the extended channelization signals for DCMAC Subsystem Independent PHY/MAC mode.

Figure 1. AXI4-Stream Extended Channelization Signals for Independent PHY/MAC Mode

• Cycle #1 shows an ID request from the DCMAC Subsystem for channel 2.
  • From an AXI4-Stream perspective, the DCMAC Subsystem is requesting the ID; however, the request source is really the user logic connected to the MAC I/F. The MAC I/F client determines the ID request pattern/calendar in accordance with its per-channel bandwidth needs. The DCMAC Subsystem relays the MAC I/F ID requests through the core and out to the AXI4-Stream user logic.
  • Data is also provided for client0, using the full data bus (12 x 16-byte segments enabled)
    • This is in response to an ID request for channel 0 that is not shown – to the left of the diagram.
    • The ena{11-0} pins are not a bus; they are individual inputs at the DCMAC Subsystem top level, shown here with bus annotation (hex FFF) to keep the diagram compact.
• Cycle #2 has a request for channel 3 and data for channel 1.
  • The channel 1 data is either a new 64-byte frame, or the end of a previously started frame (which would be indicated by tx_axis_tuser_sop0 – not shown).
• Cycle #3 has a request for channel 4 and data for channel 2.
  • This is the channelized AXI4-Stream client’s response to the request made in cycle #1.
    • The request-to-response interval in this case is two cycles. As stated earlier, the number of cycles between request and response does not matter to the DCMAC Subsystem, but it must be unchanging.
  • For the purposes of this diagram, the activation of channel 2 in this case triggers a skip request by the DCMAC Subsystem. This data and its framing information cause extra Ethernet stream bytes to accumulate in a DCMAC Subsystem context, such that it replaces a full inactive client cycle (12 x 16-byte segments) with data from its internal storage.
• Cycle #4 has a request for channel 2 and data for channel 3.
• Cycle #5 has a request for channel 0 and data for channel 4.
  • At least one channel 4 frame ends in this cycle – ena11 is deasserted.
• Cycle #6 shows no request for channel information (req_id_vld is deasserted). The channelized AXI4-Stream client returns the ID for channel 2, but no corresponding data.
  • Even when a channel has no data to send, the AXI4-Stream client must provide tvalid and corresponding ID in response to the received req_id.
  • It is important to understand that cycles with no active data from the channelized AXI4-Stream client (that is to say, all tuser_ena bits zero) result in corresponding Ethernet IDLE blocks on the MAC I/F.
    • 12 x 16-byte segments of no-data in result in 24 66-bit blocks out on the MAC I/F.
  • The MAC I/F is the rate determiner for all channels; every active ID request is a request for 24 more 66-bit blocks from the DCMAC Subsystem MAC.
  • This no-data cycle does not run down the DCMAC Subsystem's internal per-channel context accumulation. Although the previous channel 2 data triggered a skip request (which has not yet been presented externally), this cycle cannot serve as a response to that. This would be true even if the no-data cycle came after the skip request. The only channelized AXI4-Stream cycles that reduce internal context accumulation are cycles in which skip_response is asserted.
• Cycle #7 has a request for channel 3, data for channel 0, and a valid skip_req for channel 2.
  • There is a dashed arrow indicating that this status_vld cycle is correlated to the tvalid/_tid (ID 2) pair that was presented on cycle #2.This is representative only; the DCMAC Subsystem does not guarantee a particular number-of-cycles correlation between tx_axis_tid and tx_axis_ch_status_status_id, but does guarantee that the occurrence of particular status_id indications do not exceed the tvalid/tid signals presented for that channel.
• Cycle #8 has a request for channel 5 and tvalid deasserted.
  • The tvalid deassertion corresponds to the req_id_vld deassertion in cycle #6.
• Cycle #9 has a request for channel 2 and data for channel 3.
• Cycle #10 has a request for channel 2 and data for channel 5.
• Cycle #11 has a request for channel 2 and a skip response for channel 2.
  • The skip response requires that no valid data be presented, so the ena signals are all deasserted, but tvalid is asserted.
  • This diagram shows a host response time in which the channelized AXI4-Stream client returns the skip response four cycles after the DCMAC Subsystem request.
    • This time is application dependent and influenced by factors such as channel frequency within the calendar, frame rate, and internal resources allocated to the channel.
    • In general, the transmit AXI4-Stream client must provide a skip response as quickly as possible because this ensures no overrun of the DCMAC Subsystem’s internal per-channel resources.
• Cycle #12 has a request for channel 2 and data for channel 2.
  • A five-segment frame begins and ends in this cycle.
• Cycle #13 has a request for channel 0 and data for channel 2.
• Cycle #14 has a request for channel 1 and data for channel 2.
  • This is the final data for a four-cycle burst on channel 2.
  • Depending on the application and corresponding MAC I/F calendar, back-to-back bursts are possible on channels; as individual channel burst size grows, so do the requirements for internal context resources for that channel.