Wer sendet die USB SYNC/EOP-Felder, Host oder Gerät?

Ich studiere gerade die USB-Spezifikation und habe eine Frage dazu, wer die SYNC- und EOP-Felder in einem Paket sendet. Eine typische GET_DESCRIPTOR-Transaktion (sagen wir) besteht aus SETUP- und DATA0-Paketen, die vom Host gesendet werden, und einem ACK-Paket, das vom Gerät zurückgesendet wird. Meine Fragen sind:

1) Verstehe ich richtig, dass das Gerät die SYNC- und EOP-Felder für sein eigenes ACK-Paket sendet (im Gegensatz zu ihnen, die vom Host gesendet werden)?

2) Wenn ja, bedeutet das, dass es auch zu einer Verzögerung kommen kann, bis das Gerät antwortet? (Ich glaube, ich erinnere mich, etwas in dieser Richtung in der Spezifikation gesehen zu haben).

3) Bedeutet dies auch, dass die Geräteuhr während dieser Verzögerung nicht unbedingt mit der Host-Uhr synchronisiert bleibt und dass ich zum Lesen des Antwortpakets den Host nach Erhalt des SYNC-Felds des Geräts neu synchronisieren muss, z Oversampling?

Antworten (1)

Dein Verständnis ist korrekt. USB-Pakete gehen in beide Richtungen, sodass SYNC, PID, DATA, CRC und EOP von demjenigen gebildet werden, der das jeweilige Paket sendet. Und ja, ein Gerät (mit HS-Signalisierungsrate) muss in 192 Bitzeiten (400 ns) auf Standardanforderungen antworten. [der Host wartet jedoch 1700 ns, bevor er eine Zeitüberschreitung deklariert, um andere Ausbreitungsverzögerungen entlang der Verbindung auszugleichen]. Und ja, die Geräteuhr ist normalerweise asynchron zur Hostuhr. Aber beide Takte müssen innerhalb von 500 ppm der Nennfrequenz für eine erfolgreiche Kommunikation mit HS-Rate und 2000 ppm für FS/LS-Verbindungen liegen. Und ja, jeder USB-Empfänger hat Oversampling und verwendet das empfangene SYNC-Feld, um die richtige Taktflanke zu finden und die eingehenden Daten korrekt abzutasten.

Apropos, was getan werden muss, all diese Operationen verwenden gut etablierte Hardwarealgorithmen, die normalerweise in einem Hardwareblock namens "USB PHY" implementiert sind. Es führt all diese Funktionen der Taktdatenwiederherstellung (CDR) beim Empfangen, NRZI-Decodieren und Überprüfen von Fehlern und SYNC-Voranstellen, NRZI-Codieren und EOP-Anhängen beim Senden aus. Wenn Sie keine revolutionäre neue Technologie der PHY-Implementierung entwerfen, sollten Sie sich normalerweise keine Gedanken über CDR, SYNC, EOP usw. machen, der USB-PHY erledigt all dies für Sie.

Danke @Ale, danke für die Klarstellung/Bestätigung. Und ja, ich spiele mit der Implementierung eines SIE auf einem FPGA herum, also ist das alles relevant. Laut meinen Testbänken funktionieren meine NRZI/Bit-Stuffing/CRCs usw. alle ordnungsgemäß. Ich wollte nur sicherstellen, dass ich keine Zeit verschwende, die Leseseite des Protokolls aufgrund eines Missverständnisses der Spezifikation zu implementieren.