Introduction
In addition to the data compare feature itself, the sample file write_read_compare.stc script makes use of some of the Host Emulator’s most interesting and powerful tools. The script can be run on any Sierra M6-2 or M6-4 analyzer that is licensed for Host or Initiator Emulation.
Host and Initiator Emulator scripts are based on Sierra analyzer project (capture) files, but traffic generation functionality has been added. The user will notice that the Host Emulator GUI is identical to the SATA Protocol Analyzer GUI, except that two additional tabs (or “pages”) have been added, “Host Emulator” and “Host Setting.” When a Host Emulator project is opened, the default configuration is for traffic generation and recording to commence simultaneously when the “Record” button is pushed. The write_read_compare.stc script follows this convention. A Host Emulator project file can include all of the usual analyzer triggering functionality, thus allowing one to create complex test cases that interweave the features both tools, if desired. The write_read_compare.stc example actually does not make use of this ability, it utilizes the simple default “Don’t Care (Snapshot)” recording setting for the analyzer.
Running the Example, Step 1
Connect any 3G or 6G SATA HDD or SSD to the analyzer’s T1 port and provide power to it as shown in Figure 1. (In the photo power to the DUT is being provided by an ACC-EXP-005-X Device Power card.) If you are using a Sierra M6-4 analyzer, be sure to use the cable labeled “Target” or “Device” and connect the DUT to the cable’s “P1” SATA connector. As the Sierra analyzer will be acting as the host (i.e., generating the traffic), there is no need to connect anything to the I1 port. Next, click on File >> Open and fetch the write_read_compare.stc example script from the “Exerciser” examples folder. It is found down the following path: C:\Users\Public\Documents\LeCroy\SAS SATA Protocol Suite\Examples\Exerciser. When you have loaded the script it will appear in the Host Emulator GUI as shown in Figure 2.
Discussion
The write_read_compare.stc script first connects to the DUT at the DUT’s highest supported speed (“All” has been selected for “Host Emulator Port” on the Host Settings page), it then sends a single 0xEC Identify Device command, and then cycles through an incrementing write then read loop ten times. Each time through the loop a 1024 byte (2 sectors) data pattern is written to the DUT then read back. The just-read data is compared, on the fly, to a static data pattern file that has been saved previously. If the data does not match the saved file, a “Mismatch” will occur and the script will jump out of the loop before completing all ten loops.
Running the Example, Step 2
To run the write_read_compare.stc script start by clicking on the project Record button. It will only take a moment to run. Click on the square, red “Stop Recording” button if the trace does not pop up by itself. If the script has run to completion without any data mismatches the trace will contain 21 completed ATA commands. Following the 21st command, nothing but the COMINIT OOB signal from the DUT on channel T1 is recorded. This is because the Host Emulator shuts off upon completion of the 21st command. (Figure 3.) Let us now take a closer look at the composition of the script. Click on File >> Close to close the recording and bring back the write_read_compare.stc Host Emulator script.
Decomposition of the write_read_compare.stc script
The script’s single write command, “ATA Cmd. 2,” writes a repeating, 1024-byte “A55A” data pattern to the drive. Note that this pattern was selected from several default patterns stored in the Data Block feature. (Figure 4.) With the Data Block feature one can quickly create custom data patterns of any virtually length as well. Detailed instructions for using the Data Block feature are found in section 2.9.12 of the M6-2 user’s manual and in section 2.4.12 of the M6-4 user’s manual.
At the very end of the ATA Cmd. 2 packet there is an “Option” button. Clicking on the button will open up the “Protocol Errors & Command Settings” dialog. This dialog includes an extensive selection of errors that can be incorporated into the command when it is sent. It also includes the “Auto Update LBA” feature, which makes it much easier to create traffic generation scripts. This feature is utilized by the write_read_compare.stc script for both ATA Cmd.2 and for ATA Cmd.3. (Figure 5.) Note that when one has chosen to incorporate errors with the Protocol Errors & Command Settings dialog, the Option field gets marked with a bold, red “X” when the dialog box is closed.
At the end of the loop construction, following ATA Cmd.3, there is an “If On Payload Match/Mismatch” instruction. This is the feature that performs on-the-fly data compare on the previous command’s payload. Clicking on the large gray button to the right of the “Length” field opens up the “Data pattern to compare with specified command payload” dialog. This is where one enters the static data pattern to compare against. The maximum length of the comparison data pattern is 8KB (2048 dwords). The pattern can be entered by hand, but if is of any length it is much easier to create the pattern using the Data Block feature then load it using the dialog’s “Load From File” feature. The 256-dword A55A A55A comparison data pattern in the write_read_compare.stc script was created this way. To make the data compare feature work there is one more setting to be done. For ATA Cmd.3, the read command whose payload will be verified, one needs to set “Store Payload in Buffer” to 256 dwords as shown in Figure 6. As before, the Protocol Errors & Command Settings dialog is accessed by clicking on the Options button at the end of the command packet.
Final Note
Note that the Auto Update LBA feature actually has a number of possible settings. One can choose to increment or decrement the LBA by any desired number of sectors, and the starting LBA can be reset after incrementing or decrementing a specified number of times. One can also set an LBA range and have the Emulator select random LBAs to access from within that range. In the write_read_compare.stc example the loop count has been set to 10. One can easily change the loop count to a larger number or even set it to loop infinitely. One can also easily change the data pattern that is written to the DUT and the comparison pattern file. By making use of the Data Block and Auto Update LBA features, one could easily create very powerful data compare test scripts based on the write_read_compare.stc example.
