Кто отправляет поля USB SYNC/EOP, хост или устройство?

В настоящее время я изучаю спецификацию USB, и у меня есть вопрос о том, кто отправляет поля SYNC и EOP в пакете. Типичная транзакция GET_DESCRIPTOR (скажем) состоит из пакетов SETUP и DATA0, отправленных с хоста, и пакета ACK, возвращенного с устройства. Мои вопросы:

1) правильно ли я понимаю, что устройство отправляет поля SYNC и EOP для своего собственного пакета ACK (в отличие от их отправки хостом)?

2) если да, значит ли это, что также может быть задержка, пока устройство не ответит? (Кажется, я помню, что видел что-то подобное в спецификации).

3) означает ли это также, что часы устройства не обязательно могут оставаться синхронизированными с часами хоста во время этой задержки, и что для чтения ответного пакета мне нужно будет повторно синхронизировать хост после получения поля SYNC устройства, например, с помощью передискретизация?

Ответы (1)

Ваше понимание правильное. Пакеты USB идут в обоих направлениях, поэтому SYNC, PID, DATA, CRC и EOP формируются тем, кто отправляет конкретный пакет. И да, устройство (со скоростью передачи сигналов HS) должно отвечать за 192 бита (400 нс) на стандартные запросы. [хост, однако, будет ждать 1700 нс, прежде чем объявить тайм-аут, чтобы приспособиться к другим задержкам распространения по каналу]. И да, часы устройства обычно асинхронны с часами хоста. Но оба тактовых сигнала должны быть в пределах 500 ppm от номинальной частоты для успешной связи на скорости HS и 2000 ppm для каналов FS/LS. И да, каждый USB-приемник имеет передискретизацию и использует полученное поле SYNC для поиска правого фронта тактового сигнала и правильной выборки входящих данных.

Говоря о том, что необходимо сделать, все эти операции используют хорошо зарекомендовавшие себя аппаратные алгоритмы, которые обычно реализуются в аппаратном блоке под названием «USB PHY». Он выполняет все эти функции восстановления тактовых данных (CDR) при приеме, декодирования NRZI и проверки ошибок, а также предварительной обработки SYNC, кодирования NRZI и присоединения EOP при передаче. Если вы не разрабатываете какую-то революционно новую технологию реализации PHY, вам обычно не следует беспокоиться о CDR, SYNC, EOP и т. д., USB PHY сделает все это за вас.

Спасибо @Ale, ценю разъяснение/подтверждение. И да, я играю с реализацией SIE на FPGA, так что все это актуально. Согласно моим тестовым стендам, все мои NRZI/бит-стаффинг/CRC и т. д. работают правильно, я просто хотел убедиться, что не трачу время впустую на реализацию считывающей стороны протокола из-за неправильного понимания спецификации.