EZ-USB FX3 Technical Reference Manual, Document Number: 001-76074 Rev. *F 87
Universal Serial Bus (USB)
uvint32_t reserved3[3];
uvint32_t lnk_lfps_observe; /* 0xe0033064 */
uvint32_t reserved4[52];
uvint32_t lnk_compliance_pattern_0; /* 0xe0033138 */
uvint32_t lnk_compliance_pattern_1; /* 0xe003313c */
uvint32_t lnk_compliance_pattern_2; /* 0xe0033140 */
uvint32_t lnk_compliance_pattern_3; /* 0xe0033144 */
uvint32_t lnk_compliance_pattern_4; /* 0xe0033148 */
uvint32_t lnk_compliance_pattern_5; /* 0xe003314c */
uvint32_t lnk_compliance_pattern_6; /* 0xe0033150 */
uvint32_t lnk_compliance_pattern_7; /* 0xe0033154 */
uvint32_t lnk_compliance_pattern_8; /* 0xe0033158 */
} USB3LNK_REGS_T, *PUSB3LNK_REGS_T;
#define USB3LNK ((PUSB3LNK_REGS_T) USB3LNK_BASE_ADDR)
6.6.4 Protocol Layer
The FX3 USB 3.0 function protocol layer defines the "end-to-end" communication rules between a host and device. The
SuperSpeed protocol provides for application data information exchanges between a host and a device endpoint. This
communications relationship is called a "pipe." It is a host-directed protocol, which means the host determines when
application data is transferred between the host and the device. SuperSpeed is not a polled protocol, as a device can
asynchronously request service from the host on behalf of a particular endpoint.
All protocol layer communications are accomplished via the exchange of packets. Packets are sequences of data bytes with
specific control sequences that serve as delimiters managed by the link layer. Unlike USB 2.0 which uses a broadcast
mechanism, host-transmitted protocol packets are routed through intervening hubs directly to a peripheral device. A
peripheral device considers itself that targeted by any protocol layer packet it receives. Device transmitted protocol packets
simply flow upstream through hubs to the host.
Packet headers are the building blocks of the protocol layer. They are fixed-size packets with type and subtype field
encodings for specific purposes. A small record within a packet header is utilized by the link layer (port to port) to manage the
flow of the packet from port to port. Packet headers are delivered through the link layer (port to port) reliably. The remaining
fields are utilized by the end-to-end protocol.
Application data is transmitted within data packet payloads, which are preceded (in the protocol) by specifically encoded data
packet headers. Data packet payloads are not delivered reliably through the link layer (however, the accompanying data
packet headers are delivered reliably). The protocol layer supports the reliable delivery of data packets via explicit
acknowledgement (header) packets and the retransmission of lost or corrupt data. Not all data information exchanges utilize
data acknowledgements.
Data may be transmitted in bursts of back-to-back sequences of data packets (depending on the scheduling by the host). The
protocol allows efficient bus utilization by concurrently transmitting and receiving over the link. For example, a transmitter
(host or device) can burst multiple packets of data back to back, while the receiver can transmit data acknowledgements
without interrupting the burst of data packets. The number of data packets in a specific burst is scheduled by the host.
Furthermore, a host may simultaneously schedule multiple OUT bursts to be active at the same time as an IN burst.
The protocol provides flow control support for some transfer types. A device-initiated flow control is signaled by a device via a
defined protocol packet. A host-initiated flow control event is realized via the host schedule (host will simply not schedule
information flows for a pipe unless it has data or buffering available). On receipt of a flow control event, the host removes the
pipe from its schedule. Resumption of scheduling information flows for a pipe may be initiated by the host or device. A device
endpoint notifies a host of its readiness (to source or sink data) via an asynchronously transmitted "ready" packet. On receipt
of the "ready" notification, the host adds the pipe to its schedule, assuming that it still has data or buffering available.
Independent information streams can be explicitly delineated and multiplexed on the bulk transfer type. This means that
through a single pipe instance, more than one data stream can be tagged by the source and identified by the sink. The
protocol provides for the device to direct which data stream is active on the pipe.
To Next Page
Loading...
Need help?
General
