Einführung

Zusätzlich zur eigentlichen Datenvergleichsfunktion nutzt das Skript der Beispieldatei write_read_compare.stc einige der interessantesten und leistungsstärksten Tools des Host-Emulators. Das Skript kann auf jedem Sierra M6-2- oder M6-4-Analysegerät ausgeführt werden, das für Host- oder Initiator-Emulation lizenziert ist.

Host- und Initiator-Emulatorskripte basieren auf Sierra-Analyzer-Projektdateien (Erfassungsdateien), aber es wurde eine Funktionalität zur Generierung von Datenverkehr hinzugefügt. Der Benutzer wird feststellen, dass die Host-Emulator-GUI identisch mit der SATA Protocol Analyzer-GUI ist, außer dass zwei zusätzliche Registerkarten (oder „Seiten“) hinzugefügt wurden, „Host-Emulator“ und „Host-Einstellung“. Wenn ein Host-Emulator-Projekt geöffnet wird, ist die Standardkonfiguration so, dass Verkehrsgenerierung und Aufzeichnung gleichzeitig beginnen, wenn die Schaltfläche „Aufzeichnen“ gedrückt wird. Das Skript write_read_compare.stc folgt dieser Konvention. Eine Host-Emulator-Projektdatei kann alle üblichen Analysator-Triggering-Funktionen enthalten, wodurch es möglich ist, komplexe Testfälle zu erstellen, die die Funktionen beider Tools verweben, falls gewünscht. Das Beispiel write_read_compare.stc macht von dieser Fähigkeit eigentlich keinen Gebrauch, es verwendet die einfache Standard-Aufzeichnungseinstellung „Don't Care (Snapshot)“ für den Analysator.

Abbildung 1:

Analysator-Setup

Ausführen des Beispiels, Schritt 1

Schließen Sie eine beliebige 3G- oder 6G-SATA-Festplatte oder -SSD an den T1-Anschluss des Analysators an und versorgen Sie sie mit Strom, wie in Abbildung 1 gezeigt. (Auf dem Foto wird das DUT von einer ACC-EXP-005-X-Gerätestromkarte mit Strom versorgt.) Wenn Sie einen Sierra M6-4-Analysator verwenden, achten Sie darauf, das mit „Target“ oder „Device“ gekennzeichnete Kabel zu verwenden und das DUT mit dem „P1“-SATA-Anschluss des Kabels zu verbinden. Da der Sierra-Analyzer als Host agiert (dh den Datenverkehr generiert), muss nichts an den I1-Port angeschlossen werden. Klicken Sie anschließend auf Datei >> Öffnen und holen Sie sich das Beispielskript write_read_compare.stc aus dem Beispielordner „Exerciser“. Es befindet sich im folgenden Pfad: C:\Users\Public\Documents\LeCroy\SAS SATA Protocol Suite\Examples\Exerciser. Wenn Sie das Skript geladen haben, wird es in der Host-Emulator-GUI angezeigt, wie in Abbildung 2 dargestellt.

Abbildung 2:

SHost-Emulator-GUI

Diskussion

Das Skript write_read_compare.stc stellt zuerst eine Verbindung zum DUT mit der höchsten unterstützten Geschwindigkeit des DUT her („All“ wurde für „Host Emulator Port“ auf der Seite „Host Settings“ ausgewählt), es sendet dann einen einzelnen 0xEC-Befehl „Identify Device“ und durchläuft es dann eine inkrementierende Schreib- und Leseschleife zehnmal. Jedes Mal, wenn die Schleife durchlaufen wird, wird ein Datenmuster von 1024 Byte (2 Sektoren) in das DUT geschrieben und dann zurückgelesen. Die gerade gelesenen Daten werden im laufenden Betrieb mit einer zuvor gespeicherten statischen Datenmusterdatei verglichen. Wenn die Daten nicht mit der gespeicherten Datei übereinstimmen, tritt ein „Mismatch“ auf und das Skript springt aus der Schleife, bevor alle zehn Schleifen abgeschlossen sind.

Ausführen des Beispiels, Schritt 2

Um das Skript write_read_compare.stc auszuführen, klicken Sie zunächst auf die Schaltfläche „Aufzeichnen“ des Projekts. Es dauert nur einen Moment, um zu laufen. Klicken Sie auf die quadratische, rote „Stop Recording“-Schaltfläche, wenn die Kurve nicht von selbst erscheint. Wenn das Skript vollständig ohne Datenkonflikte ausgeführt wurde, enthält die Ablaufverfolgung 21 abgeschlossene ATA-Befehle. Nach dem 21. Befehl wird nichts als das COMINIT-OOB-Signal vom DUT auf Kanal T1 aufgezeichnet. Dies liegt daran, dass der Host-Emulator nach Abschluss des 21. Befehls heruntergefahren wird. (Abbildung 3.) Sehen wir uns nun den Aufbau des Skripts genauer an. Klicken Sie auf Datei >> Schließen, um die Aufzeichnung zu schließen und das Host-Emulator-Skript write_read_compare.stc wiederherzustellen.

Abbildung 3:

Erfolgreicher Lauf, keine Diskrepanzen

Zerlegung des Skripts write_read_compare.stc

Der einzelne Schreibbefehl des Skripts „ATA Cmd. 2“ schreibt ein sich wiederholendes 1024-Byte-Datenmuster „A55A“ auf das Laufwerk. Beachten Sie, dass dieses Muster aus mehreren Standardmustern ausgewählt wurde, die in der Datenblockfunktion gespeichert sind. (Abbildung 4.) Mit der Datenblockfunktion kann man auch schnell benutzerdefinierte Datenmuster beliebiger virtueller Länge erstellen. Detaillierte Anweisungen zur Verwendung der Datenblockfunktion finden Sie in Abschnitt 2.9.12 des M6-2-Benutzerhandbuchs und in Abschnitt 2.4.12 des M6-4-Benutzerhandbuchs.

Abbildung 4:

ATA-Befehlsdatenfeld

Ganz am Ende des ATA Cmd. 2-Paket gibt es eine Schaltfläche „Option“. Ein Klick auf die Schaltfläche öffnet den Dialog „Protokollfehler & Befehlseinstellungen“. Dieser Dialog enthält eine umfangreiche Auswahl an Fehlern, die beim Senden in den Befehl eingebaut werden können. Es enthält auch die Funktion „Auto Update LBA“, die es viel einfacher macht, Skripte zur Verkehrsgenerierung zu erstellen. Diese Funktion wird vom Skript write_read_compare.stc sowohl für ATA Cmd.2 als auch für ATA Cmd.3 verwendet. (Abbildung 5.) Beachten Sie, dass das Optionsfeld beim Schließen des Dialogfelds mit einem fetten, roten „X“ markiert wird, wenn Sie sich entschieden haben, Fehler in das Dialogfeld „Protokollfehler und Befehlseinstellungen“ aufzunehmen.

Abbildung 5:

Dialogfeld "Protokollfehler und Befehlseinstellungen".

Am Ende des Schleifenaufbaus, nach ATA Cmd.3, gibt es eine „If On Payload Match/Mismatch“-Anweisung. Dies ist die Funktion, die einen On-the-Fly-Datenvergleich mit der Nutzlast des vorherigen Befehls durchführt. Ein Klick auf die große graue Schaltfläche rechts neben dem Feld „Länge“ öffnet den Dialog „Datenmuster zum Vergleich mit angegebener Befehlsnutzlast“. Hier gibt man das statische Datenmuster ein, mit dem verglichen werden soll. Die maximale Länge des Vergleichsdatenmusters beträgt 8 KB (2048 Dwords). Das Muster kann von Hand eingegeben werden, aber wenn es eine beliebige Länge hat, ist es viel einfacher, das Muster mit der Datenblockfunktion zu erstellen, als es mit der Funktion „Aus Datei laden“ des Dialogfelds zu laden. Das 256-dword-A55A-A55A-Vergleichsdatenmuster im Skript write_read_compare.stc wurde auf diese Weise erstellt. Damit die Datenvergleichsfunktion funktioniert, muss noch eine Einstellung vorgenommen werden. Für ATA Cmd.3, den Lesebefehl, dessen Payload verifiziert wird, muss „Store Payload in Buffer“ auf 256 dwords gesetzt werden, wie in Abbildung 6 gezeigt. Wie zuvor wird das Dialogfeld „Protocol Errors & Command Settings“ durch Klicken auf aufgerufen Optionsschaltfläche am Ende des Befehlspakets.

Abbildung 6:

Speichern Sie die Nutzlast in der Puffereinstellung

Schlussbemerkung

Beachten Sie, dass die Funktion „Auto Update LBA“ tatsächlich eine Reihe möglicher Einstellungen hat. Man kann wählen, die LBA um eine beliebige gewünschte Anzahl von Sektoren zu inkrementieren oder zu dekrementieren, und die Start-LBA kann zurückgesetzt werden, nachdem eine bestimmte Anzahl von Malen inkrementiert oder dekrementiert wurde. Man kann auch einen LBA-Bereich festlegen und den Emulator zufällige LBAs auswählen lassen, auf die innerhalb dieses Bereichs zugegriffen werden soll. Im Beispiel von write_read_compare.stc wurde die Schleifenzahl auf 10 gesetzt. Man kann die Schleifenzahl leicht auf eine größere Zahl ändern oder sogar auf eine unendliche Schleife einstellen. Man kann auch leicht das Datenmuster ändern, das in das DUT und die Vergleichsmusterdatei geschrieben wird. Durch die Nutzung der Data Block- und Auto Update LBA-Funktionen konnte man auf der Grundlage des Beispiels write_read_compare.stc auf einfache Weise sehr leistungsfähige Datenvergleichstestskripts erstellen.