【正文】 姓名： 一、 外文原文 出處： Protocol Layer Byte/Bit Ordering Bits are sent out onto the bus leastsignificant bit (LSb) first, followed by the next LSb, through to the mostsignificant bit (MSb) last. In the following diagrams, packets are displayed such that both individual bits and fields are represented (in a left to right reading order) as they would move across the bus. Multiple byte fields in standard descriptors, requests, and responses are interpreted as and moved over the bus in littleendian order, ., LSB to MSB. SYNC Field All packets begin with a synchronization (SYNC) field, which is a coded sequence that generates a maximum edge transition density. It is used by the input circuitry to align ining data with the local clock. A SYNC from an initial transmitter is defined to be eight bits in length for full/lowspeed and 32 bits for highspeed. Received SYNC fields may be shorter as described in Chapter 7. SYNC serves only as a synchronization mechanism and is not shown in the following packet diagrams. The last two bits in the SYNC field are a marker that is used to identify the end of the SYNC field and, by inference, the start of the PID. Packet Field Formats Field formats for the token, data, and handshake packets are described in the following section. Packet bit definitions are displayed in unencoded data format. The effects of NRZI coding and bit stuffing have been removed for the sake of clarity. All packets have distinct Start and EndofPacket delimiters. The Startof Packet (SOP) delimiter is part of the SYNC field. Token Packets Figure 85 shows the field formats for a token packet. A token consists of a PID, 7 specifying either IN, OUT, or SETUP packet type and ADDR and ENDP fields. The PING special token packet also has the same fields as a token packet. For OUT and SETUP transactions, the address and endpoint fields uniquely identify the endpoint that will receive the subsequent Data packet. For IN transactions, these fields uniquely identify which endpoint should transmit a Data packet. For PING transactions, these fields uniquely identify which endpoint will respond with a handshake packet. Only the host can issue token packets. An IN PID defines a Data transaction from a function to the host. OUT and SETUP PIDs define Data transactions from the host to a function. A PING PID defines a handshake transaction from the function to the host. Token packets have a fivebit CRC that covers the address and endpoint fields as shown above. The CRC does not cover the PID, which has its own check field. Token and SOF packets are delimited by an EOP after three bytes of packet field data. If a packet decodes as an otherwise valid token or SOF but does not terminate with an EOP after three bytes, it must be considered invalid and ignored by the receiver. StartofFrame Packets StartofFrame (SOF) packets are issued by the host at a nominal rate of once every ms ms for,a fullspeed bus and 125 μs μs for a highspeed bus. SOF packets consist of a PID indicating packet type followed by an 11bit frame number field as illustrated in Figure 813. The SOF token prises the tokenonly transaction that distributes an SOF marker and acpanying frame number at precisely timed intervals corresponding to the start of 8 each frame. All highspeed and fullspeed functions, including hubs, receive the SOF packet. The SOF token does not cause any receiving function to generate a return packet。 therefore, SOF delivery to any given function cannot be guaranteed. The SOF packet delivers two pieces of timing information. A function is informed that an SOF has occurred when it detects the SOF PID. Frame timing sensitive functions, that do not need to keep track of frame number (., a fullspeed operating hub), need only decode the SOF PID。 they can ignore the frame number and its CRC. If a function needs to track frame number, it must prehend both the PID and the time stamp. Fullspeed devices that have no particular need for bus timing information may ignore the SOF packet. Handshake Packets Handshake packets are used to report the status of a data transaction and can return values indicating successful reception of data, mand acceptance or rejection, flow control, and halt conditions. Only transaction types that support flow control can return handshakes. Handshakes are always returned in the handshake phase of a transaction and may be returned, instead of data, in the data phase. Handshake packets are delimited by an EOP after one byte of packet field. If a packet decodes as an otherwise valid handshake but does not terminate with an EOP after one byte, it must be considered invalid and ignored by the receiver. There are four types of handshake packets and one special handshake packet: indicates that the data packet was received without bit stuff or CRC errors over the data field and that the data PID was received correctly. ACK may be issued either when sequence bits match and the receiver can accept data or when sequence bits mismatch and the sender and receiver must resynchronize to each other. An ACK handshake is applicable only in transactions in which data has been transmitted and where a handshake is expected. ACK can be returned by the host for IN transactions and by a function for OUT, SETUP, or PING transactions. indicates that a function was unable to accept data from the host (OUT) or that a function has no data to transmit to the host (IN). NAK can only be returned by functions in the data phase of IN transactions or the handshake phase of OUT or PING transactions. The host can never issue NAK. NAK is used for flow control purposes to indicate that a function is temporarily unable to transmit or receive data, but will eventually be able to