1
\$\begingroup\$

I'm currently studying the USB spec and I have a question about who sends the SYNC and EOP fields in a packet. A typical GET_DESCRIPTOR transaction (say) consists of SETUP and DATA0 packets sent from the host and an ACK packet returned from the device. My questions are:

1) am I correct in the understanding that the device sends the SYNC and EOP fields for its own ACK packet (as opposed to them being sent by the host)?

2) if so, does that mean there may also be a delay until the device responds? (I think I remember seeing something along these lines in the spec).

3) does that also mean that the device clock may not necessarily remain synchronized with the host clock during this delay, and that in order to read the response packet I'll need to re-synchronize the host upon receipt of device's SYNC field e.g. by oversampling?

\$\endgroup\$
2
\$\begingroup\$

Your understanding is correct. USB packets go both ways, so SYNC, PID, DATA, CRC, and EOP are formed by whoever sends the particular packet. And yes, a device (at HS rate of signaling) must respond in 192 bit times (400 ns) to standard requests. [the host, however, will wait 1700ns before declaring time-out, to accommodate for other propagation delays along the link]. And yes, device clock is normally asynchronous to host clock. But both clocks must be within 500ppm of nominal frequency for successful communication at HS rate, and 2000ppm for FS/LS links. And yes, every USB receiver has oversampling and uses the received SYNC field to find right clock edge and sample the incoming data correctly.

Speaking about what needs to be done, all these operations use well established hardware algorithms, which are usually implemented in a hardware block called "USB PHY". It does all these functions of clock-data recovery (CDR) on receiving, NRZI decoding, and checking errors, and SYNC pre-pending, NRZI encoding and EOP attachment on transmitting. Unless you are designing some revolutionary new technology of PHY implementation, you normally shouldn't worry about CDR, SYNC, EOP, etc, the USB PHY does all this for you.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks @Ale, appreciate the clarification/confirmation.And yes, I'm playing around with implementing an SIE on an FPGA, so this is all relevant. According to my test-benches my NRZI/bit-stuffing/CRCs etc are all working properly, I just wanted to make sure I don't waste any time implementing the read side of the protocol due to a misunderstanding of the spec. \$\endgroup\$ Jan 3 '20 at 7:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.