sata digital device moi jdsu utd1.4 1.00

Serial ATA Logo Group 1 Digital MOI for JDSU Xgig Test Platform

15 October 2009 Version 1.00 Serial ATA Interoperability Program Revision 1.4 JDSU MOI for Device Digital Tests (ASR, GTR, NCQ, SSP, IPM and DOF)

This document is provided "AS IS" and without any warranty of any kind, including, without limitation, any express or implied warranty of non‐infringement, merchantability or fitness for a particular purpose. In no event shall SATA‐IO or any member of SATA‐IO be liable for any direct, indirect, special, exemplary, punitive, or consequential damages, including, without limitation, lost profits, even if advised of the possibility of such damages. This material is provided for reference only. The Serial ATA International Organization does not endorse the vendor’s equipment outlined in this document


Microsoft, Microsoft Windows 2000, Windows XP, and Windows Vista are registered trademarks or trademarks of Microsoft Corporation. All other trademarks and registered trademarks are property of their respective owners. THIS DOCUMENT IS PROVIDED TO YOU “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON‐INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE. THE AUTHORS OF THIS DOCUMENT DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PROPRIETARY RIGHTS, RELATING TO USE OR IMPLEMENTATION OF INFORMATION IN THIS DOCUMENT. THE AUTHORS DO NOT WARRANT OR REPRESENT THAT SUCH USE WILL NOT INFRINGE SUCH RIGHTS. THE PROVISION OF THIS DOCUMENT TO YOU DOES NOT PROVIDE YOU WITH ANY LICENSE, EXPRESS OR IMPLIED TO ANY INTELLECTUAL PROPERTY RIGHTS. Copyright © 2009 by JDSU Corporation All rights reserved Contacting JDSU JDSU Corporation 430 North McCarthy Blvd Milpitas, CA 95035 Main: 408‐546‐5000 Fax: 408‐546‐4300 Technical Support 1‐408‐546‐7096 ( International ) 1‐866‐594‐2557 ( US Toll Free ) Website: www.jdsu.com Questions/comments about this document send to: [email protected]


TABLE OF CONTENTS

1. INTRODUCTION .......................................................................................... 6 PURPOSE ........................................................................................................................................ 6 REFERENCES .................................................................................................................................... 6 RESOURCE REQUIREMENTS ................................................................................................................ 6 LAST MODIFICATION ......................................................................................................................... 7 TEST SETUP ..................................................................................................................................... 7 TEST PROCEDURE ............................................................................................................................. 7 POST PROCESSING ............................................................................................................................ 7 OBSERVABLE RESULTS ....................................................................................................................... 7 POSSIBLE PROBLEMS ......................................................................................................................... 9

2. REFERENCES .............................................................................................. 10

3. TEST PROCEDURE ...................................................................................... 11 ASR‐01:COMINIT RESPONSE INTERVAL ........................................................................................... 11 ASR‐02:COMINIT OOB INTERVAL .................................................................................................. 12 GTR‐01:SOFTWARE RESET .............................................................................................................. 13 GTR‐02:3GB/S OR ABOVE SIGNALING SPEED BACKWARDS COMPATIBILITY ............................................... 15 GTR‐03: DMA PROTOCOL SUPPORT ................................................................................................ 17 GTR‐04:GENERAL SATA SUPPORT ................................................................................................... 20 GTR‐05:UNRECONGNIZED FIS RECEIPT (INFORMATIVE) ........................................................................ 21 NCQ‐01:FORCED UNIT ACCESS ........................................................................................................ 23 NCQ‐02:READ LOG EXT LOG PAGE 10H SUPPORT ................................................................................ 24 NCQ‐03:INTERMIX OF LEGACY AND NCQ COMMANDS ........................................................................ 26 NCQ‐04:DEVICE RESPONSE TO MALFORMED NCQ COMMANDS ............................................................ 28 NCQ‐05:DMA SETUP AUTO‐ACTIVATE ............................................................................................. 31 SSP‐01: INITIALIZE DEVICE PARAMETERS ............................................................................................ 33 SSP‐02: READ/WRITE STREAM ERROR LOG ........................................................................................ 35 SSP‐03: SECURITY MODE STATE ....................................................................................................... 37 SSP‐04: SET ADDRESS MAX ............................................................................................................ 39 SSP‐05: SET FEATURES – WRITE CACHE ENABLE/DISABLE ..................................................................... 41 SSP‐06: SET FEATURES – SET TRANSFER MODE .................................................................................. 43 SSP‐07: SET FEATURES – ADVANCED POWER MANAGEMENT ENABLE/DISABLE ......................................... 46 SSP‐08: SET FEATURES – READ LOOK‐AHEAD ..................................................................................... 48 SSP‐09: SET FEATURES – RELEASE INTERRUPT ..................................................................................... 49 SSP‐10: SET FEATURES – SERVICE INTERRUPT ..................................................................................... 51 SSP‐11: SET MULTIPLE MODE ......................................................................................................... 53 SSP‐12: SET FEATURES – WRITE‐READ‐VERIFY ................................................................................... 55 IPM‐01: PARTIAL STATE EXIT LATENCY (HOST‐INITIATED) ...................................................................... 57 IPM‐02: SLUMBER STATE EXIT LATENCY (HOST‐INITIATED) .................................................................... 59


IPM‐03: SPEED MATCHING UPON RESUME (HOST‐INITIATED) ............................................................... 61 IPM‐04: NAK OF REQUESTS WHEN SUPPORT NOT INDICATED .............................................................. 63 IPM‐05: RESPONSE TO PMREQ_P .................................................................................................. 64 IPM‐06: RESPONSE TO PMREQ_S .................................................................................................. 66 IPM‐07: DEVICE DEFAULT SETTING FOR DEVICE INITIATED REQUESTS ...................................................... 67 IPM‐08: DEVICE INITIATED POWER MANAGEMENT ENABLE/DISABLE ...................................................... 69 IPM‐09: PARTIAL STATE EXIT LATENCY (DEVICE‐INITIATED) ................................................................... 72 IPM‐10: SLUMBER STATE EXIT LATENCY (DEVICE‐INITIATED) ................................................................. 74 IPM‐11: SPEED MATCHING UPON RESUME (DEVICE‐INITIATED) ............................................................ 76 DOF‐01: ASYNCHRONOUS NOTIFICATION .......................................................................................... 78 DOF‐02: PHY SPEED INDICATOR ....................................................................................................... 81

APPENDIX A: TEST SETUP PROCEDURE .............................................................. 83

APPENDIX B – SETTING UP THE LABJACK DEVICE ............................................... 86


MODIFICATION RECORD Revision Date Comments 0.1 March 10, 2009 Initial draft 0.7 March 18, 2009 Internal review, updated typos and

fixed certain test procedures 0.8 May 25, 2009 Updated to include comments from

SATA‐IO feedback, plus internal review and updated to the UTD 1.4 document.

0.9 June 4, 2009 Reviewed during SATA‐IO conference call on June 4, 2009 and approved to .90 draft.

0.91 August 5, 2009 Updated to support UTD 1.4 version .933, updated the MOI for IPM‐04. Replaced Finisar with JDSU and added “Informative” to some tests.

1.0RC August 13, 2009 Updated to 1.0RC by SATAIO vote approval on 08/13/09. Accepted all changes and also due to formatting errors, found and fixed some minor typos in document.

1.0 October 15, 2009 Updated to 1.0 Release Status by vote during the SATAIO conference call on October 15, 2009. Also, updated contact information for JDSU.

ACKNOWLEDGMENTS The author would like to acknowledge the efforts of the following individuals in the development and review of this document:

• Amit Bakshi, Lecroy • John Calvin, Tektronix • Yeow Chuan Chng, JDSU • Tien Hiong Lee, JDSU • Tim Mostad, VTM • Yun Wang, Ulink


1. INTRODUCTION The test definitions themselves are intended to provide a high‐level description of the motivation, resources, procedures, and methodologies specific to each test. Formally, each test description contains the following sections: Purpose The purpose is a brief statement outlining what the test attempts to achieve. The test is written at the functional level. References This section specifies all reference material external to the test suite, including the specific sub clauses references for the test in question, and any other references that might be helpful in understanding the test methodology and/or test results. External sources are always referenced by a bracketed number (e.g., [1]) when mentioned in the test description. Any other references in the test description that are not indicated in this manner refer to elements within the test suite document itself (e.g., “Appendix 5.A”, or “Table 5.1.1‐1”) Resource Requirements The requirements section specifies the test hardware and/or software needed to perform the test. This is generally expressed in terms of minimum requirements, however in some cases specific equipment manufacturer/model information may be provided. In order to perform the tests, the following hardware and software components are needed as shown in Table 1‐1.

Table 1‐1: Required Testing Resources

Item Description 1 Windows 2000, XP or Vista Host Computer, with the following minimum characteristics:

512MB RAM, Ethernet Port, Keyboard, Mouse, Monitor, and active network connection to LAN.

2 Functional LAN to support HOST computer and Xgig Testing Platform 3 JDSU Xgig 6 Gb/s SAS/SATA Testing Platform which contains 6Gb wide port blade and Chassis 4 Mini SAS x4 External Connector to 4 SATA x1 Internal Connectors Cable (SFF‐8088) 5 Vendor Supplied SATA Target Device , Device Under Test (DUT) 6 Vendor Supplied Power Supply to power the DUT 7 Correct media compatible with ATAPI devices; Blank RW media or known media disc 8 Power controller devices for automated testing of DUT (For example, LabJack Device)


Last Modification This specifies the date of the last modification to this test, which can be found in the Modification Record section. Test Setup The setup section describes the initial configuration of the test environment. Small changes in the configuration should not be included here, and are generally covered in the test procedure section. Test Procedure The procedure section of the test description contains the systematic instructions for carrying out the test. It provides a cookbook approach to testing, and may be interspersed with observable results. Post Processing This section lists the steps involved to analyze the Xgig trace result for integrity verification of each tests. In this test suite, all of the tests perform automatic verification on the test results, except for tests NCQ-03 and ASR-02. For all tests with automatic verification, Post Processing is optional. User may conduct Post Processing to validate the behaviour of the DUT as well as to understand how the DUT had responded to each tests. To view the decoded Identify (Packet) Device data, user must run Xgig Expert on the trace result and have Expert ports added to the original trace. Next, the trace result on Xgig TraceView must be reloaded. Observable Results This section lists the specific observables that can be examined by the tester in order to verify that the DUT is operating properly. When multiple values for an observable are possible, this section provides a short discussion on how to interpret them. The determination of a pass or fail outcome for a particular test is generally based on the successful (or unsuccessful) detection of a specific observable. See Figure 1‐1 below shows the JDSU Compliance Suite result view


Figure 1‐1: Compliance Test Result View

Also, the results can be viewed by inspecting the tool’s log file, which can be found at: c:\Program Files\Finisar\Xgig SATA CTS\log, assuming that JDSU Compliance Suite software is being installed in c:\Program Files\Finisar, and double click the appropriate file for review and analysis. The test results falls into the following categories:

1. The result of “Passed” indicates the DUT has fulfilled the required testing criteria via the JDSU Compliance Test Procedure.

2. The result of “Failed” indicates the DUT has NOT fulfilled the required testing criteria via the JDSU Compliance Test Procedure in one or more areas.

3. The results of “N/A” indicates the test does not apply to a particular DUT, which is obtained from examining the DUT’s identify page.

4. The results of “Test Aborted” or “Error” indicates a critical error has occurred which prohibited the test from executing against the target DUT.


5. The results of “Invalid Device” indicates that an invalid DUT type (ATA or ATAPI) has been detected, and test will not be performed on the DUT.

6. The results of “Manual Stopped” indicates that the test has been manually stopped by

the user during its execution.

7. The results of “Manual Verification” indicates that the test requires user to perform manual verification to determine its compliance, based on the Xgig trace result.

8. The results of “Timed Out” indicates that the time taken by the test to execute has

passed the timeout value defined by user, and the test is terminated. Possible Problems This section contains a description of known issues with the test procedure, which may affect test results in certain situations. It may also refer the reader to test suite appendices and/or other external sources that may provide more detail regarding these issues.

1. If the host computer loses LAN connectivity from the Xgig Testing Platform, the tests will be aborted. The following error may be displayed as a result: Cannot Acquire Tester Card from Driver, OpenTester failed Can't Open Tester...aborting test Error Code is 1 Should the above error occur, validate the LAN environment and associated cables for the HOST Computer and Xgig Testing Platform.

2. Is it recommended that the Xgig testing platform port speed be set to match the same speed of the DUT rather than using the auto detect feature in those cases where the port speed auto detection is not working.


2. REFERENCES The following document is referenced in this document: • Serial ATA Revision 2.5 • Serial ATA Revision 3.0 • SATA‐IO Interoperability Rev 1.4 Unified Test Document


3. TEST PROCEDURE ASR‐01:COMINIT Response Interval Purpose: To verify that a device in quiescent state will respond to a host COMRESET signal with an associated COMINIT signal within 10 milliseconds. Status: Informative Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: After connecting the DUT and powering it on, the Host Emulator tool will issue a COMRESET to the device. The automated Test Procedure measures the response time. Also, while performing this test, capture a trace and validate response time results. This test is executed a total of 5 times. Test Setup: See section Appendix A: Test Setup Procedure on page 83. Test Procedure: Start Test:

1. Enable Xgig tracing between Host and Device (Optional). 2. Click the ASR-01 Test in the tool to activate this test.

3. Click the Start Tests Button (This test is automatically executed 5 times).

4. If user had enabled Xgig tracing before hand, Post Processing can be performed to

analyze the Xgig trace result of this test (Optional). The ASR-01 Test does the following:

1. Power cycle the device.

2. Initiate COMRESET sequence.


3. Verify OOB sequence completion and COMINIT is within 10 milliseconds after COMRESET is transmitted by host. If this criteria is not fulfilled, test is marked as “FAILED”.

Post Processing: (See section Post Processing on page 7.)

1. Review host side COMRESET and Device response COMINIT in the captured trace and verify correct execution of the test.

2. Verify that the COMINIT response timing to the COMRESET request is within the window of 10 milliseconds in the trace.

Observable Results: (See section Observable Results on page 7.)

1. Examine the test result section of the JDSU compliance test suite main window or view the test results by examining the log file.

2. Results for all the test cycles will be reported and the values used to determine overall pass/fail results. If the test fails any of the test cycles, the overall test result is failed.

Possible Problems: See section Possible Problems on page 9. ASR‐02:COMINIT OOB Interval Purpose: When host is powered off or under PHY OFFLINE, test will confirm that the device does not initiate a new out of band (OOB) COMINIT to the host faster than 10 milliseconds. Status: Informative Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: The host emulator is disabled and not transmitting to the device, and then only device activities are captured and analyzed. The time distance between each two consecutive COMINIT exchanges, send by the device is measure within the captured trace. The out of window or invalid time period is reported in the tool. This test is executed a total of 10 times.


Test Setup: See section Appendix A: Test Setup Procedure on page 83. Test Procedure: Start Test:

1. Enable Xgig tracing between Host and Device (Optional). 2. Click the ASR-02 Test in the tool to activate this test. 3. Click the Start Tests Button (This test is automatically executed 10 times).

The ASR-02 Test does the following:

1. Power cycle the device. 2. Prompt user to start Xgig tracing.

3. Power off the host or place the host under PHY OFFLINE mode.

4. Introduce a delay of 1.5 seconds before issuing a COMRESET, to return the host to initial

mode.

5. Prompt user to stop Xgig tracing and manually perform the following verifications: • Verify that once host is powered off or went into PHY OFFLINE mode, device sends

COMINIT repeatably. • The time interval between each COMINIT sent by the device must not be faster than

10 milliseconds. If these criteria are not fulfilled, user is to mark the test as “FAILED”.




Possible Problems: See section Possible Problems on page 9. JDSU GTR‐01:Software Reset Purpose:


To determine if a Device can successfully process a Device‐To‐Host FIS request and process the software reset protocol correctly. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: After a host issues a COMRESET to the Device and the Device then successfully acknowledged without any errors, a Device then shall successfully respond to the setting of the SRST (Software Reset) bit in the Device Control register and perform the software reset protocol. The device must respond within 31 seconds. This test is executed a total of 5 times. Test Setup: See section Appendix A: Test Setup Procedure on page 83.

Test Procedure: Start Test:

1. Enable Xgig tracing between Host and Device (Optional). 2. For ATAPI device, place JDSU Special CD in Drive Tray.

3. Click the GTR-01 Test in the tool to activate this test.

4. Click the Start Tests Button (This test is automatically executed 5 times).


analyze the Xgig trace result of this test (Optional). The GTR-01 Test does the following:

1. Issue either IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) to the Device.

2. Issue either READ SECTOR (ATA) or READ CD (ATAPI) to the Device.

3. Issue a SRST to the Device.

4. Verify that after the software reset sequence, the received Register FIS contains no

errors and has the appropriate signature content in the Sector Count and LBA fields. If this criteria is not fulfilled, test is marked as “FAILED”.



1. Within the trace, verify that Software Reset (SRST) was issued correctly by the host. Ensure that BSY, DRQ, or ERR bits are not set.

2. Verify that reset falls with the 31 second window and Register FIS received corresponds

to the following: • Status Register Bit: 7, 3, and 0 shall be set to: 0h • Error register shall be set to: 01h • Sector Count shall be set to: 01h • LBA Low shall be set to: 01h • LBA Mid shall be set to: 00h (ATA) or 14h (ATAPI) • LBA High shall be set to: 00h (ATA) or EBh (ATAPI)




Possible Problems: See section Possible Problems on page 9. GTR‐02:3Gb/s or Above Signaling Speed Backwards Compatibility Purpose: To validate if a Device claims support for Serial ATA Gen‐2 (and Gen‐3 signaling speed), it also supports Serial ATA Gen‐1 signaling speed. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion:


An IDENTIFY (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command is issued to the Device to validate support for Gen‐3, Gen‐2 speeds and Gen‐1 speeds. This test is executed a total of 10 times. Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the GTR-02 Test in the tool to activate this test. 3. Click the Start Tests Button (This test is automatically executed 10 times).



1. Issue either IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) to the Device.

2. Check Interface Speed Support (WORD 76, bits 3:1).

3. For any interface speed grade that is supported, verify that all other speed grades below

this grade is supported also. If this criterion is not fulfilled, test is marked as “FAILED”.

4. Set interface speed to highest supported speed grade.

5. Issue COMRESET and complete OOB sequence.

6. Verify that after the OOB sequence, the received Register FIS contains no errors and has appropriate signature content in the Sector Count and LBA fields. If this criterion is not fulfilled, test is marked as “FAILED”.

7. This test is repeated with all other supported speed grades below the highest supported

speed grade. Post Processing: (See section Post Processing on page 7.)

1. Within a trace, verify that host successfully set the link to all supported interface speed grades and issue a COMRESET.


2. A device must support all other speed grades below its highest supported interface

speed grade. For example, if the device supports 6.0G interface speed, it must also support 3.0G and 1.5G interface speed grades as well.

3. After COMRESET is issued, within the trace, verify that the Register FIS received corresponds to the following: • Status Register Bit: 7, 3, and 0 shall be set to: 0h • Error register shall be set to: 01h • Sector Count shall be set to: 01h • LBA Low shall be set to: 01h • LBA Mid shall be set to: 00h (ATA) or 14h (ATAPI) • LBA High shall be set to: 00h (ATA) or EBh (ATAPI)




Possible Problems: See section Possible Problems on page 9. GTR‐03: DMA Protocol Support Purpose: To validate if a Device supports DMA Identify Page information, DMA modes, and handles all DMA requests and issues the correct responses to each DMA operation. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: First check WORD 49 Bit 8 which should be 1 to determine DMA support. Next, determine the highest level of Ultra DMA mode supported by Device and then set to that mode. Issue IDENTIFY (PACKET) DEVICE to validate that DMA mode has been set correctly. Followingly, issue a series of WRITE/READ command (for ATA), WRITE/READ CD (for RW ATAPI) or just


READ CD (For RO ATAPI) to determine correct operations. Check for data mismatch. This test is executed a total of 5 times. Test Setup: See section Appendix A: Test Setup Procedure on page 83. Test Procedure: Start Test:

1. Enable Xgig tracing between Host and Device (Optional). 2. Click the GTR-03 Test in the tool to activate this test. 3. Click the Start Tests Button (This test is automatically executed 5 times).



1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if WORD 49, bit 8 is set, if not, mark test as “N/A”.

2. Check that the content in WORD 88 is valid (WORD 53, bit 2).

3. Check on the Ultra DMA modes that are supported (WORD 88, bits 6:0). If Ultra DMA is supported, issue SET FEATURES to set the device to use the highest supported Ultra DMA mode.

4. If Ultra DMA is not supported, check on the Multi‐Word DMA modes that are supported

(WORD 63, bits 2:0). If Multi‐Word DMA is supported, issue SET FEATURES to set the device to use the highest supported Multi‐Word DMA mode. If both Ultra DMA and Multi‐Word DMA are not supported, test is marked as “FAILED”.

5. For ATA devices, issue a WRITE DMA command with transfer size of 8Kbytes.

6. Issue a READ DMA command to the same disk location.

7. Verify that the data read matches the data written. If this criterion is not fulfilled, test is

marked as “FAILED”.

8. Repeat steps 5‐7 with transfer size of 128Kbytes.


9. For ATAPI devices that support writing to media, complete one track worth of write commands with transfer size of 8Kbytes.

10. Complete one track worth of read commands to the same disk location.

11. Verify that the data read matches the data written. If this criterion is not fulfilled, test is


12. Repeat steps 9‐11 with transfer size of 128Kbytes.

13. For ATAPI devices that only support reading from media (e.g. CDROM, DVDROM, etc.), complete one track worth of read commands with transfer size of 8Kbytes.

14. Complete another track worth of read commands to the same disk location.

15. Verify that data read from both sets of read commands matches. If this criterion is not

fulfilled, test is marked as “FAILED”.

16. Repeat steps 13‐15 with transfer size of 128Kbytes. Post Processing: (See section Post Processing on page 7.)

1. Within the trace, verify that the SET FEATURES command was executed successfully and its changes to the DMA mode were reflected in the IDENTIFY (PACKET) DEVICE (ATA) data.

2. For ATA Devices: • Ensure that the WRITE DMA and READ DMA commands were executed successfully.

• If all WRITE/READ DMA commands completed successfully, then ensure that the data read matches the data written.

3. For ATAPI Devices (Support Writing To Media):

• Ensure that the WRITE 10 and READ 10 commands were executed successfully. • If all WRITE/READ 10 commands completed successfully, then ensure that the data read matches the data written.

4. For ATAPI Devices (Support Reading From Media):

• Ensure that the READ 10 commands were executed successfully.


• If all READ 10 commands completed successfully, then ensure that the data read from similar disk locations returns a match.




Possible Problems: See section Possible Problems on page 9. GTR‐04:General SATA Support Purpose: To determine if a Device Identify Page data (WORD 93) content is cleared to zero and that the Device supports 1.5G signaling speed (WORD 76, bit 1). Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: After a host issues an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI), verify that WORD 93 is all 0s and that WORD 76 (Bit 1) is set to 1. Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the GTR-04 Test in the tool to activate this test. 3. Click the Start Tests Button.


analyze the Xgig trace result of this test (Optional).


The GTR-04 Test does the following:

1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command.

2. Verify that WORD 93 is cleared to 0. If this criterion is not fulfilled, test is marked as “FAILED”.

3. Verify that Serial ATA Gen‐1 interface speed (WORD 76, bit 1) is supported (set to 1). If

this criterion is not fulfilled, test is marked as “FAILED”.

4. Verify that bit 0 of WORD 79:76 are cleared to 0. If this criterion is not fulfilled, test is marked as “FAILED”.

Post Processing: (See section Post Processing on page 7.) 1. Within the trace, verify that within the IDENTIFY (PACKET) DEVICE data, WORD 76

bit 1 is set to 1, bit 0 of WORD 79:76 should be cleared to 0. Observable Results: (See section Observable Results on page 7.)



Possible Problems: See section Possible Problems on page 9. GTR‐05:Unrecongnized FIS Receipt (Informative) Purpose: To determine if a Device will reject unrecognized FIS requests, thus proving that link layer state machine definitions found in the Serial ATA specifications are operating correctly. When a device rejects a FIS, it will respond with an R_ERR response. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009


Discussion: From a SATA specification point of view, a Device response to a recognized FIS is with a R_OK. This test will validate that when the Host sends a total of 242 unrecognized FIS requests, the Device must response to them all with an R_ERR. This test is considered “Informative”. However, test result information is displayed in the testing tool. Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the GTR-05 Test in the tool to activate this test. 3. Click the Start Tests Button.




2. Issue undefined FIS to the device. 3. Verify that R_ERR primitives are received from the device. If this criterion is not fulfilled,

test is marked as “FAILED”. 4. This test is repeated with a total of 242 undefined FIS issued to the device.


1. Within the trace, verify that transmit of undefined FIS to the device were successful. 2. Verify that all the responses from the device to each undefined FIS were R_ERR

primitives. Observable Results: (See section Observable Results on page 7.)




Possible Problems: See section Possible Problems on page 9. NCQ‐01:Forced Unit Access Purpose: To determine if a Device supports READ FPDMA QUEUED and WRITE FPDMA QUEUED commands. If so, then it shall also support the Force Unit Access (FUA) bit as well. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: Check to see if the data written is the same as the read; using the READ/WRITE FPDMA QUEUED commands. Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the NCQ-01 Test in the tool to activate this test. 3. Click the Start Tests Button.


analyze the Xgig trace result of this test (Optional). The NCQ-01 Test does the following:

1. Issue an IDENTIFY DEVICE command and check to see if NCQ is supported (WORD 76, bit 8 is set), ). If not, mark test as “N/A”.

2. Issue a WRITE FPDMA QUEUED command with FUA bit set to 1.


3. Issue a READ FPDMA QUEUED command to the same disk location.

4. Verify that data read matches the data written. If this criterion is not fulfilled, test is


Post Processing: (See section Post Processing on page 7.) 1. Within the trace, verify that NCQ is supported as reflected in the IDENTIFY DEVICE

data (WORD 76, bit 8 set to 1).

2. Check that all WRITE FPDMA QUEUED and READ FPDMA QUEUED commands are completed successfully.

3. Ensure that the data read matches the data written.




Possible Problems: See section Possible Problems on page 9. NCQ‐02:Read Log Ext log page 10h Support Purpose: To determine if a Device that claims support for NCQ (WORD 76, Bit 0) is set to 1, then the Device shall also support READ LOG EXT to log page 10h and General Purpose Logging feature set. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion:


When NCQ support is claimed, see if the READ LOG EXT log page is available and General Purpose Logging Feature is supported. Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE command and check to see if NCQ is supported (WORD 76 bit 8 is set), ). If not, mark test as “N/A”.

2. Check that General Purpose Logging Feature is supported (WORD 87, bit 5 is set to 1).

3. Issue READ LOG EXT to log page 00h.

4. Verify the successful completion and data transfer for log page 00h. If this criterion is not fulfilled, test is marked as “FAILED”.

5. Verify that within log page 00h, offset 20h contains a value of 1 and offset 21h

contains a value of 0. If this criterion is not fulfilled, test is marked as “FAILED”.

6. Issue READ LOG EXT to log page 10h.

7. Verify the successful completion and data transfer for log page 10h. If this criterion is not fulfilled, test is marked as “FAILED”.


1. Within the trace, verify that NCQ is supported as reflected in the IDENTIFY DEVICE data (WORD 76, bit 8 set to 1).


2. WORD 87, bit 5 should also be set to 1 to reflect the device’s support for the General Purpose Logging Feature.

3. Check that both READ LOG EXT (00h) and READ LOG EXT (10h) commands are completed successfully and that the log page data is transferred correctly.

4. Within the log page data for log page 00h, offset 20h should contain a value of 1,

and offset 21h should contain a value of 0. Observable Results: (See section Observable Results on page 7.)



Possible Problems: See section Possible Problems on page 9. NCQ‐03:Intermix of Legacy and NCQ Commands Purpose: To determine if a Device receiving a legacy ATA command while a NCQ command is pending, when an error has occurred and the Device shall handle the necessary state cleanup and return to the state with no commands pending. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: July 29, 2009 Discussion: The device shall set an error condition to the host by issuing a Register FIS with the ERR bit set to 1 and the BSY bit cleared to 0, then the error field (ABRT bit) will be set to 1. If there were NCQ command pending, the device shall stop processing commands until the READ LOG EXT command is issued. When this command is received by the Device, the FIS to discard any pending commands in the device queue. Test Setup:


See section Appendix A: Test Setup Procedure on page 83.



The NCQ-03 Test does the following:

1. Issue an IDENTIFY DEVICE command and check to see if NCQ is supported (WORD 76, bit 8 is set), if not, mark test as “N/A”.

2. Check Maximum Queue Depth – 1 (WORD 75, bits 4:0).

3. Prompt user to start Xgig tracing.

4. Issue X number of READ FPDMA QUEUED commands, where X is the Maximum Queue Depth – 1.

5. Issue legacy ATA command: IDENTIFY DEVICE.

6. Upon receiving a Register FIS with error, a READ LOG EXT command will be issued to

log page 10h.

7. Verify that in the data within log page 10h, NQ bit is 1. If this criterion is not fulfilled, test is marked as “FAILED”.

8. Verify that in the data within log page 10h, checksum is correct. If this criterion is not


9. Prompt user to stop Xgig tracing and manually perform the following verifications: i. Verify the receipt of Register FIS with the following criteria after the legacy ATA

command is issued: • BSY bit = 0 • ERR bit = 1 • ABRT bit = 1

ii. Verify the receipt of Set Device Bits FIS with the following criteria after READ LOG EXT is issued: • BSY bit = 0


• DRDY bit = 1 • DF bit = 0 • DRQ bit = 0 • ERR bit = 0 • ‘I’ bit = 0 • SActive field = FFFFFFFFh

If these criteria are not fulfilled, user is to mark the test as “FAILED”.

10. The test is repeated with the following legacy ATA commands: i. WRITE SECTOR ii. READ DMA iii. READ LOG EXT with log page 10h




Possible Problems: See section Possible Problems on page 9. NCQ‐04:Device Response to Malformed NCQ Commands Purpose: To determine if a Device handles malformed NCQ command correctly. For example, a duplicate tag value can be received for an outstanding NCQ command, or the specified LBA is out of the devices supported range. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: July 29, 2009 Discussion: TBD


Test Setup: See section Appendix A: Test Setup Procedure on page 83.






2. Check Total Number of User Addressable Sectors (WORD 61:60 and WORD 103:100).

3. Issue READ FPDMA QUEUED with LBA out of range.

4. Verify that either a Register FIS or a Set Device Bits FIS is received with the following

criteria: • ERR bit = 1 • DRDY bit = 0 • ‘I’ bit = 1 • Either the ABRT bit or IDNF bit = 1

If these criteria are not fulfilled, test is marked as “FAILED”.

5. Issue READ LOG EXT to log page 10h. 6. Verify that the Set Device Bits FIS is received with the following criteria:

• ERR bit = 0 • DRDY bit = 1 • DF bit = 0 • ‘I’ bit = 0 • SActive Field = FFFFFFFFh


7. In the data within log page 10h, verify that the following criteria are matched: • TAG field includes the tag associated with the malformed NCQ command


• NQ bit = 0 • ERR bit = 1 • DRDY bit = 1 • DF bit = 0 • For test involving malformed NCQ command with out‐of‐range LBA, either ABRT

bit or IDNF bit = 1 • For all other tests involving malformed NCQ commands, ABRT bit = 1 • Checksum is correct


8. For test involving malformed NCQ command with out‐of‐range LBA, in the data within log page 10h, LBA field must include the LBA address issued in the failed NCQ command. If this criterion is not met, test is marked as “FAILED”.

9. Test is repeated with the following malformed NCQ commands:

• Issue 2 READ FPDMA QUEUED with duplicated tag • Issue READ FPDMA QUEUD with tag value out of device supported range



2. Check that all malformed READ FPDMA QUEUED commands are executed successfully

with errors being returned as either a Register FIS or a Set Device Bits FIS. The content within either one of these FISes should be:

• ERR bit = 1 • DRDY bit = 0 • ‘I’ bit = 1 • Either the ABRT bit or IDNF bit = 1

3. Check that all READ LOG EXT commands are executed successfully with Set Device Bits

FIS being returned. The content within the Set Device Bits FIS should be: • ERR bit = 0 • DRDY bit = 1 • DF bit = 0 • ‘I’ bit = 0 • SActive Field = FFFFFFFFh

4. Verify that the content in the data within log page 10h should have:

• TAG field is associated to the tag of the malformed NCQ command


• NQ bit = 0 • ERR bit = 1 • DRDY bit = 1 • DF bit = 0 • If the test involves malformed NCQ command with out‐of‐range LBA, either

ABRT bit or IDNF bit = 1, and the LBA field should include the LBA address of the failed NCQ command

• If the test involves other types of malformed NCQ commands, ABRT bit = 1 • Checksum is correct




Possible Problems: See section Possible Problems on page 9. NCQ‐05:DMA Setup Auto‐Activate Purpose: To determine if a Device that claims support DMA Setup Auto‐Activate feature will not transmit a DMA Activate FIS to trigger transmission of the first Data FIS from the host, if it had already sent a DMA setup FIS with the Auto-Activate bit set to 1. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: Check to see if a device claims support for DMA Setup Auto Activiate, by examining WORD 78 bit 2 is set to 1. If true, a device shall not send a DMA Activate FIS if it had already sent a DMA Setup FIS with “A” bit set to 1. Test Setup: See section Appendix A: Test Setup Procedure on page 83.







2. Check that DMA Setup Auto‐Activation is supported (WORD 78, bit 2 is set to 1).

3. Issue a SET FEATURES command with Sector Count = 02h and Features = 10h

to enable DMA Setup Auto‐Activation.

4. Verify that DMA Setup Auto‐Activation (WORD 79, bit 2) is successfully enabled. If this criterion is not fulfilled, test is marked as “FAILED”.

5. Issue WRITE FPDMA QUEUED with Auto-Activate bit set to 1.

6. Verify that the initial DMA Activate FIS is missing prior to first transmitted Data FIS. If


7. Verify that the WRITE FPDMA QUEUED command completed successfully. If this criterion is not fulfilled, test is marked as “FAILED”.



2. WORD 78, bit 2 should also be set to 1 to reflect the device’s support for DMA Setup

Auto‐Activation. 3. Verify that the SET FEATURES command was executed successfully and DMA Setup

Auto Activation was enabled, as reflected in the IDENTIFY (PACKET) DEVICE data.


4. Check that the WRITE FPDMA QUEUED command was executed successfully.

5. From the trace, observe that between the DMA Setup FIS and the first Data FIS, DMA Activate FIS is missing.

Observable Results: (See section Observable Results on page 7.) 1. Examine the test result section of the JDSU compliance test suite main window or view

the test results by examining the log file.


Possible Problems: See section Possible Problems on page 9. SSP‐01: Initialize Device Parameters Purpose: To validate if a Device when receiving a COMRESET, shall maintain the device settings established by the INITIALIZE DEVICE PARAMETERS command. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the SSP-01 Test in the tool to activate this test. 3. Click the Start Tests Button.


4. If user had enabled Xgig tracing before hand, Post Processing can be performed to analyze the Xgig trace result of this test (Optional).

The SSP-01 Test does the following:

1. Issue an IDENTIFY DEVICE command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and WORD 58:54 are valid (WORD 53, bit 0 set to 1). If these bits are not set, mark test as “N/A”.

2. Check the value of Device Settings (WORD 58:54).

3. Issue an INITIALIZE DEVICE PARAMETERS command to change the values of Device

Settings.

4. Verify that the values of Device Settings are changed successfully. If this criterion is not fulfilled, test is marked as “FAILED”.

5. Issue a COMRESET and complete the OOB sequence.

6. Issue an IDENTIFY DEVICE command and verify that the content of Device Settings is maintained after a COMRESET. If this criteriacriterion is not fulfilled, test is marked as “FAILED”.


1. Within the trace, verify that SSP is supported as reflected in the IDENTIFY DEVICE data (WORD 78, bit 6 set to 1).

2. WORD 53, bit 0 should also be set to 1 to reflect that the content within WORD 58:54 is

valid.

3. Check that the INITIALIZE DEVICE PARAMETERS command was executed successfully and the content within WORD 58:54 was changed from its default values.

4. Verify that COMRESET was completed successfully and the content within WORD 58:54

remained the same as before the COMRESET was issued. Observable Results: (See section Observable Results on page 7.)




Possible Problems: See section Possible Problems on page 9. SSP‐02: Read/Write Stream Error Log Purpose: To validate that a Device, when claiming support for Streaming, that it maintains values from Read Stream Error Log after a COMRESET. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.




analyze the Xgig trace result of this test (Optional). The SSP-02 Test does the following:

1. Issue an IDENTIFY DEVICE command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Streaming Feature Set Supported (WORD 84, bit 4 set to 1). If these bits are not set, mark test as “N/A”.

2. Issue a READ LOG EXT command to get the default content of the READ STREAM

ERROR LOG (log page 22h).


3. Issue a WRITE LONG command to generate error at LBA location 30h.

4. If the WRITE LONG command is not supported, issue SCT WRITE LONG to generate

error at LBA location 30h. 5. If the SCT WRITE LONG command is not supported, issue WRITE UNCORRECTABLE to

generate error at LBA location 30h.

6. Verify that the content in the READ STREAM ERROR LOG is successfully changed. If this criterion is not fulfilled, test is marked as “FAILED”.

7. Issue a COMRESET and complete OOB sequence.

8. Issue a READ LOG EXT command to get the content of the READ STREAM ERROR LOG.

9. Verify that the content of the READ STREAM ERROR LOG is maintained after a COMRESET. If this criteria is not fulfilled, test is marked as “FAILED”.



2. WORD 84, bit 4 should also be set to 1 to reflect the device’s support for Streaming

Feature Set.

3. Either a WRITE LONG command, or an SCT WRITE LONG command, or a WRITE UNCORRECTABLE command will be issued to generate stream error. Check that any one of these commands was executed successfully.

4. Check that the content within the Read Stream Error Log (log page 22h) was changed

from its default values, and these newly changed values remained the same after COMRESET was issued.




Possible Problems:


See section Possible Problems on page 9. SSP‐03: Security Mode State Purpose: To validate that a Device, when claiming support for Security Mode, after a COMRESET, will maintain the value of the Security Mode setting. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Security Feature Set is supported (WORD 82, bit 1 set to 1). If these bits are not set, mark test as “N/A”.

2. Verify that Security Feature Set is enabled (WORD 85, bit 1 is set to 1).

3. If SECURITY STATUS is LOCKED, issue a SECURITY UNLOCK command.


4. Issue a SECURITY SET PASSWORD command to change the values of Security Status (WORD 128, bits 3:1).

5. Verify that the content of Security Status is changed successfully. If this criterion is not


6. To verify that the device works in SEC5 state, for ATA device, issue a READ DMA command, and a WRITE SECTOR command. For ATAPI device, issue an INQUIRY command.


8. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command. 9. Verify that the Security Feature Set remains enabled after a COMRESET. If this criterion

is not fulfilled, test is marked as “FAILED”.

10. Verify that the content of Security Status is maintained after a COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.

11. Verify that the device works in SEC5 state instead of SEC4 state. For ATA device, issue a READ DMA command, and a WRITE SECTOR command. For ATAPI device, issue an INQUIRY command. If this criterion is not fulfilled, test is marked as “FAILED”.

12. Restore the SECURITY PASSWORD.


1. Within the trace, verify that SSP is supported as reflected in the IDENTIFY (PACKET) DEVICE data (WORD 78, bit 6 set to 1).

2. WORD 82, bit 1 should also be set to 1 to reflect the device’s support for Security

Feature Set.

3. WORD 85, bit 1 should also be set to 1 to reflect the device’s Security Feature Set is enabled for the device.

4. Check that the SECURITY SET PASSWORD command was executed successfully and

the content within Security Status (WORD 128, bits 3:1) was changed from its default values.


5. For ATA devices, check that the READ DMA and WRITE SECTOR commands were executed successfully. Successful completion of these commands signifies the device’s support for SEC5 state.

6. For ATAPI devices, check that the INQUIRY command was executed successfully.

Successful completion of this command signifies the device’s support for SEC5 state.

7. Verify that COMRESET was completed successfully and Security Feature Set remained enabled, while the content of Security Status was unchanged as compared to that before the COMRESET was issued.

8. For ATA devices, check again that the READ DMA and WRITE SECTOR commands were

executed successfully. Successful completion of these commands signifies the device’s support for SEC5 state.

9. For ATAPI devices, check again that the INQUIRY command was executed successfully.

Successful completion of this command signifies the device’s support for SEC5 state. Observable Results: (See section Observable Results on page 7.)



Possible Problems: See section Possible Problems on page 9. SSP‐04: Set Address Max Purpose: To validate that a Device, when claiming support for Host Protected Area, will maintain the max address established by the SET MAX ADDRESS or SET MAX ADDRESS EX command after a COMRESET. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009


Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Host Protected Area Feature Set is supported (WORD 82, bit 10 set to 1). If these bits are not set, mark test as “N/A”.

2. If 48‐bit Feature Set is not supported (WORD 83, bit 10 cleared to 0), issue READ NATIVE MAX ADDRESS to get the 28‐bit Max User Accessible Address.

3. Issue SET MAX ADDRESS with new valid 28‐bit Max User Accessible Address.

4. Verify that the content of the 28‐bit Max User Accessible Address is changed

successfully. If this criterion is not fulfilled, test is marked as “FAILED”.

5. If 48‐bit Feature Set is supported (WORD 83, bit 10 set to 1), issue READ NATIVE MAX ADDRESS EXT to get the 48‐bit Max User Accessible Address.

6. Issue SET MAX ADDRESS EXT with new valid 48‐bit Max User Accessible Address.

7. Verify that the content of the 48‐bit Max User Accessible Address is changed

successfully. If this criterion is not fulfilled, test is marked as “FAILED”.



9. Issue an IDENTIFY DEVICE command.

10. If 48‐bit Feature Set is not supported, verify that the content of the 28‐bit Max User Accessible Address is maintained after a COMRESET. If 48‐bit Feature Set is supported, verify that both contents of the 48‐bit and 28‐bit Max User Accessible Addresses are maintained after a COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.

11. Restore Max User Accessible Address to its original values.



2. WORD 82, bit 10 should also be set to 1 to reflect the device’s support for Host Protected Area Feature Set.

3. Check that the SET MAX ADDRESS / SET MAX ADDRESS EXT command was executed

successfully and contents within either one or both of 28‐bit Max User Accessible Address (WORD 61:60) and 48‐bit Max User Accessible Address (WORD 103:100), were changed from their default values.

4. Verify that COMRESET completed successfully and contents within either one or both of

28‐bit Max User Accessible Address (WORD 61:60) and 48‐bit Max User Accessible Address (WORD 103:100), remained the same as before the COMRESET was issued.



2. Results for all the test cycles will be reported and the values used to determine overall

pass/fail results. If the test fails any of the test cycles, the overall test result is failed. Possible Problems: See section Possible Problems on page 9. SSP‐05: Set Features – Write Cache Enable/Disable Purpose:


To validate that a Device, when claiming support for WRITE CACHE, will maintain the value of the write cache after a COMRESET has been received. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Write Cache is supported (WORD 82, bit 5 set to 1). If these bits are not set, mark test as “N/A”.

2. Check Write Cache’s setting (WORD 85, bit 5).

3. If Write Cache is enabled, issue SET FEATURES to disable Write Cache. Otherwise,

issue SET FEATURES to enable Write Cache. 4. Verify that Write Cache’s setting is changed successfully. If this criterion is not fulfilled,

test is marked as “FAILED”.



6. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and verify that Write Cache’s setting is maintained after a COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.

7. Restore Write Cache’s setting to its original value. Post Processing: (See section Post Processing on page 7.)


2. WORD 82, bit 5 should also be set to 1 to reflect the device’s support for Write Cache

3. Check that the SET FEATURES command was executed successfully and Write Cache’s setting (WORD 85, bit 5) was toggled.

4. Verify that COMRESET was completed successfully and Write Cache’s setting remained

the same as before the COMRESET was issued. Observable Results: (See section Observable Results on page 7.)



Possible Problems: See section Possible Problems on page 9. SSP‐06: Set Features – Set Transfer Mode Purpose: To validate that a Device, will maintain Multiword DMA and Ultra DMA mode settings after a COMRESET has been received. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009


Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if SSP is supported (WORD 78, bit 6 set to 1). If this criterion is not met, mark test as “N/A”.

2. Check the Multiword DMA Mode Support (Word 63, bits 2:0) and Multiword DMA

Mode Selected (WORD 63, bits 10:8).

3. If Multiword DMA transfer is supported, issue SET FEATURES to change the content of Multiword DMA Mode Selected.

4. Verify that the content in Multiword DMA Mode Selected is successfully changed. If this

criterion is not fulfilled, test is marked as “FAILED”. 5. Issue a COMRESET and complete OOB sequence.

6. Verify that the content in Multiword DMA Mode Selected is maintained after a

COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.

7. For ATA devices, issue a READ DMA command. For ATAPI devices, handle the reset condition accordingly and issue a READ 10 command.


8. Check the Ultra DMA Mode Support (Word 88, bits 6:0) and Ultra DMA Mode Selected (Word 88, bits 14:8).

9. If Ultra DMA transfer is supported, issue SET FEATURES to change the content of Ultra DMA Mode Selected.

10. Verify that the content in Ultra DMA Mode Selected is successfully changed. If this

criterion is not fulfilled, test is marked as “FAILED”. 11. Issue a COMRESET and complete OOB sequence.

12. Verify that the content in Ultra DMA Mode Selected is maintained after a COMRESET. If


13. For ATA devices, issue a READ DMA command. For ATAPI devices, handle the reset condition accordingly and issue a READ 10 command.

14. Restore Multiword DMA Mode Selected / Ultra DMA Mode Selected to its original value.



2. WORD 63, bits 10:8 should also be set to 1 to reflect the device’s support for Security Feature Set.

3. Check that the SET FEATURES command was executed successfully and the content

within Multi‐Word DMA Mode Selected (WORD 63, bits 10:8) or Ultra DMA Mode Selected (Word 88, bits 14:8) was changed from its default values.

4. Verify that COMRESET completed successfully and the content within Multi‐Word DMA

Mode Selected and Ultra DMA Mode Selected remained the same as before the COMRESET was issued.




Possible Problems:


See section Possible Problems on page 9. SSP‐07: Set Features – Advanced Power Management Enable/Disable Purpose: To validate that a Device, that claims support for Advanced power Management, will maintain Advance Power Management setting after a COMRESET has been received. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Advanced Power Management is supported (WORD 83, bit 3 set to 1). If these bits are not set, mark test as “N/A”.


2. Check Advanced Power Management’s setting (WORD 86, bit 3).

3. If Advanced Power Management is enabled, issue SET FEATURES to disable it. Otherwise, issue SET FEATURES to enable Advanced Power Management.

4. Verify that contents in Advanced Power Management Enabled and Advanced Power

Management Level (WORD 91, bits 7:0) are successfully changed. If this criterion is not fulfilled, test is marked as “FAILED”.


6. Verify that contents in Advanced Power Management Enabled and Advanced Power

Management Level are maintained after a COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.

7. Restore Advanced Power Management’s setting to its original value.



2. WORD 83, bit 3 should also be set to 1 to reflect the device’s support for Advanced Power Management.

3. Check that the SET FEATURES command was executed successfully and Advanced

Power Management’s setting (WORD 86, bit 3) was toggled, while the content within Advanced Power Management Level (WORD 91, bits 7:0) was changed from its default values.

4. Verify that COMRESET completed successfully and Advanced Power Management’s

setting and Advanced Power Management Level remained the same as before the COMRESET was issued.




Possible Problems: See section Possible Problems on page 9.


SSP‐08: Set Features – Read Look‐Ahead Purpose: To validate that a Device, that claims support for Read Look‐Ahead, will maintain the Read Look‐Ahead settings after a COMRESET has been received. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Read Look‐Ahead Supported (WORD 82, bit 6 set to 1). If these bits are not set, mark test as “N/A”.

2. Check Read Look‐Ahead’s setting (WORD 85, bit 6).

3. If Read Look‐Ahead is enabled, issue SET FEATURES to disable it. Otherwise, issue SET

FEATURES to enable Read Look‐Ahead.


4. Verify that Read Look‐Ahead’s setting is successfully changed. If this criterion is not fulfilled, test is marked as “FAILED”.


6. Verify that Read Look‐Ahead’s setting is maintained after a COMRESET. If this criterion is

not fulfilled, test is marked as “FAILED”.

7. Restore Read Look‐Ahead’s setting to its original value. Post Processing: (See section Post Processing on page 7.)


2. WORD 82, bit 6 should also be set to 1 to reflect the device’s support for Read Look‐

Ahead.

3. Check that the SET FEATURES command was executed successfully and Read Look‐Ahead’s setting (WORD 85, bit 6) was toggled.

4. Verify that COMRESET completed successfully and Read Look‐Ahead’s setting remained

the same as before the COMRESET was issued. Observable Results: (See section Observable Results on page 7.)



Possible Problems: See section Possible Problems on page 9. SSP‐09: Set Features – Release Interrupt Purpose: To validate that a Device, that claims support for Release Interrupt, will maintain Release Interrupt setting after a COMRESET has been received. Resource Requirements:


See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Release Interrupt is supported (WORD 82, bit 7 set to 1). If these are not set, mark test as “N/A”.

2. Check Release Interrupt’s setting (WORD 85, bit 7).

3. If Release Interrupt is enabled, issue SET FEATURES to disable it. Otherwise, issue SET

FEATURES to enable Release Interrupt.

4. Verify that Release Interrupt’s setting is successfully changed. If this criterion is not fulfilled, test is marked as “FAILED”.


6. Verify that Release Interrupt’s setting is maintained after a COMRESET. If this criterion is


7. Restore Release Interrupt’s setting to its original value. Post Processing: (See section Post Processing on page 7.)



2. WORD 82, bit 7 should also be set to 1 to reflect the device’s support for Release Interrupt.

3. Check that the SET FEATURES command was executed successfully and Release

Interrupt’s setting (WORD 85, bit 7) was toggled.

4. Verify that COMRESET completed successfully and Release Interrupt’s setting remained the same as before the COMRESET was issued.




Possible Problems: See section Possible Problems on page 9. SSP‐10: Set Features – Service Interrupt Purpose: To validate that a Device, that claims support for Service Interrupt, will maintain Service Interrupt, setting after a COMRESET has been received. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.

Test Procedure:


Start Test: 1. Enable Xgig tracing between Host and Device (Optional). 2. Click the SSP-10 Test in the tool to activate this test. 3. Click the Start Tests Button.



1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Service Interrupt is supported (WORD 82, bit 8 set to 1). If these bits are not set, mark test as “N/A”.

2. Check Service Interrupt’s setting (WORD 85, bit 8). 3. If Service Interrupt is enabled, issue SET FEATURES to disable it. Otherwise, issue SET

FEATURES to enable Service Interrupt.

4. Verify that Service Interrupt’s setting is successfully changed. If this criterion is not fulfilled, test is marked as “FAILED”.


6. Verify that Service Interrupt’s setting is maintained after a COMRESET. If this criterion is


7. Restore Service Interrupt’s setting to its original value. Post Processing: (See section Post Processing on page 7.)


2. WORD 82, bit 8 should also be set to 1 to reflect the device’s support for Service Interrupt.

3. Check that the SET FEATURES command was executed successfully and Service Interrupt’s setting (WORD 85, bit 8) was toggled..


4. Verify that COMRESET completed successfully and Service Interrupt’s setting remained the same as before the COMRESET was issued.




Possible Problems: See section Possible Problems on page 9. SSP‐11: Set Multiple Mode Purpose: To validate that a Device, that claims support for Set Multiple Mode will maintain block size established by Multiple Mode command setting after a COMRESET has been received. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional).

2. Click the SSP-11 Test in the tool to activate this test. 3. Click the Start Tests Button.



The SSP-11 Test does the following:

1. Issue an IDENTIFY DEVICE (ATA) command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and Multiple Logical Setting is valid (WORD 59, bit 8 set to 1). If these bits are not set, mark test as “N/A”.

2. Check the Maximum Logical Sector Per Read/Write Multiple (WORD 47, bits 7:0) for

non‐zero values. 3. Issue a SET MULTIPLE command to alter device block size from the value reported in

Maximum Logical Sector Per Read/Write Multiple. 4. Verify that the content in Logical Sector Per Read/Write Multiple (WORD 59, bits 7:0) is

successfully changed resulting from the SET MULTIPLE command. If this criterion is not fulfilled, test is marked as “FAILED”.


6. Verify that the content in Logical Sector Per Read/Write Multiple is maintained after a

COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”. 7. Restore Logical Sector Per Read/Write Multiple to its original values.



2. WORD 59, bit 8 should also be set to 1 to reflect that Multiple Logical Setting is valid.

3. Check that the SET MULTIPLE command was executed successfully and the content within Maximum Logical Sector Per Read/Write Multiple (WORD 47, bits 7:0) was changed from its default values.

4. Verify that COMRESET completed successfully and the content of Maximum Logical Sector Per Read/Write Multiple was unchanged as compared to before the COMRESET was issued.




2. Results for all the test cycles will be reported and the values used to determine overall

pass/fail results. If the test fails any of the test cycles, the overall test result is failed. Possible Problems: See section Possible Problems on page 9. SSP‐12: Set Features – Write‐Read‐Verify Purpose: To validate that a Device, that claims support for Write‐Read‐Verify will maintain Write‐Read‐Verify command settings after a COMRESET has been received. Note: This test is not applicable to ATAPI devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83. Test Procedure: Start Test:





1. Issue an IDENTIFY DEVICE (ATA) command and check to see if SSP is supported (WORD 78, bit 6 set to 1) and WORD 120:119 are valid (WORD 86, bit 15 set to 1). If these bits are not set, mark test as “N/A”.

2. Check Write‐Read‐Verify Feature Set is supported (WORD 119, bit 1 set to 1). If this

criterion is not met, mark test as “N/A”. 3. Check Write‐Read‐Verify Feature Set’s setting (WORD 120, bit 1).

4. If Write‐Read‐Verify Feature Set is enabled, issue SET FEATURES to disable it.

Otherwise, issue SET FEATURES to enable Write‐Read‐Verify Feature Set.

5. Verify that contents in Write‐Read‐Verify Feature Set Enabled, Write‐Read‐Verify Current mode (WORD 220, bits 7:0) and Write‐Read‐Verify Sector Count Mode 3 Only (WORD 211:210), are successfully changed resulting from the SET FEATURES command. If thisthese criteria are not fulfilled, test is marked as “FAILED”.


7. Verify that contents in Write‐Read‐Verify Feature Set Enabled, Write‐Read‐Verify

Current mode and Write‐Read‐Verify Sector Count Mode 3 Only are maintained after a COMRESET. If this criteria these criterion are not fulfilled, test is marked as “FAILED”.

8. Test device’s support for multiple Write‐Read‐Verify Modes. Issue SET FEATURES to

enable Write‐Read‐Verify into Mode 0, Mode 1, Mode 2 and Mode 3.

9. In each iteration, after calling SET FEATURES, verify that the change has been successful and issue a COMRESET. Verify that the content in Write‐Read‐Verify Current Mode setting is maintained after the COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.

10. Test device’s support for multiple sector count when using Write‐Read‐Verify Mode 3.

Issue SET FEATURES to enable Write‐Read‐Verify into Mode 3. Iterate this step with 4 different values of Mode 3 sector count.

11. In each iteration, after calling SET FEATURES, verify that the change has been

successful and issue a COMRESET. Verify that the content in Write‐Read‐Verify Sector Count Mode 3 Only setting is maintained after the COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.

12. Restore Write‐Read‐Verify settings to its original values.




2. WORD 86, bit 15 should also be set to 1 to reflect that the content within WORD 120:119 is valid.

3. WORD 119, bit 1 should also be set to 1 to reflect the device’s support for Write‐Read‐

Verify Feature Set.

4. Check that the SET FEATURES command was executed successfully and the Write‐Read‐Verify setting (WORD 120, bit 1) was toggled, while contents of Write‐Read‐Verify Current Mode (WORD 220, bits 7:0) and Write‐Read‐Verify Sector Count Mode 3 Only (WORD 211:210) are changed from their default values.

5. Verify that COMRESET completed successfully and contents of the Write Read Verify

setting, Write‐Read‐Verify Current Mode and Write‐Read‐Verify Sector Count Mode 3 Only remained the same as before the COMRESET was issued.

6. Perform similar verification for repeated portions within this test.




Possible Problems: See section Possible Problems on page 9. IPM‐01: Partial State Exit Latency (Host‐Initiated) Purpose: To validate that a Device and corresponding Host exit latency from the partial state shall start within 10 microseconds from the COMWAKE receipt. For consistency, this test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI. Status: Informative


Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the IPM-01 Test in the tool to activate this test. 3. Click the Start Tests Button. (This test is automatically executed 10 times)


analyze the Xgig trace result of this test (Optional). The IPM-01 Test does the following:

1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if HIPM is supported (WORD 76, bit 9 is set to 1). If not, mark test as “N/A”.

2. Issue PMREQ_P primitives and obtain device response.

3. Issue COMWAKE and wait for complete wake of device.

4. Verify that Partial wake sequence completion is within 10 microseconds after COMWAKE

is transmitted by host. If this criterion is not fulfilled, test is marked as “FAILED”.

5. Issue IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command. Post Processing: (See section Post Processing on page 7.)

1. Within the trace, verify that HIPM is supported as reflected in the IDENTIFY (PACKET) DEVICE data (WORD 76, bit 9 set to 1).


2. Check that PMREQ_P primitives were successfully issued by host, followed by success completion of COMWAKE sequence.

3. Verify that the device responded COMWAKE within a window of 10 microseconds upon

receiving COMWAKE from host.

4. Check that the IDENTIFY (PACKET) DEVICE command is completed successfully. Observable Results: (See section Observable Results on page 7.)



Possible Problems: See section Possible Problems on page 9. IPM‐02: Slumber State Exit Latency (Host‐Initiated) Purpose: To validate that Device exit latency from the slumber state shall start within 10 milliseconds from the COMWAKE receipt. For consistency, this test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI. Status: Informative Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.






1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if HIPM is supported (WORD 76 bit 9 is set to 1). If not, mark test as “N/A”.

2. Issue PMREQ_S primitives and receive device response.


4. Verify that Slumber wake sequence completion is within 10 milliseconds after COMWAKE

is transmitted by host. If this criterion is not fulfilled, test is marked as “FAILED”.

5. Issue IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command. Post Processing: (See section Post Processing on page 7.)


2. Check that PMREQ_S primitives were successfully issued by host, followed by success

completion of COMWAKE sequence.

3. Verify that the device responded COMWAKE within a window of 10 milliseconds upon receiving COMWAKE from host.

4. Check that the IDENTIFY (PACKET) DEVICE command is completed successfully.





Possible Problems: See section Possible Problems on page 9. IPM‐03: Speed Matching Upon Resume (Host‐Initiated) Purpose: To validate that Device signaling speed upon returning from the slumber or partial state shall match the signaling speed prior to the COMWAKE receipt. If the Device claims multiple speeds, then this test must be run for each supported signaling speed. For consistency, this test is executed a total of 10 times for each supporting signaling speed. Note: The Host side testing is not supported by this MOI. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.







2. Set interface speed to the lowest supported speed.

3. Issue PMREQ_P primitives and receive device response.

4. Issue COMWAKE and wait for complete wake of Device. 5. Verify that the interface speed matches the interface speed prior to entering Partial

state. If this criterion is not fulfilled, test is marked as “FAILED”.

6. Verify that PMACK or PMNAK primitives are returned after PMREQ_P primitives are issued. If this criterion is not fulfilled, test is marked as “FAILED”.

7. The test is repeated with PMREQ_S primitives being issued.

8. If the device supports multiple Serial ATA interface speed, this test is repeated with all

supported interface speeds. Post Processing: (See section Post Processing on page 7.)


2. Check that PMREQ_P primitives were successfully issued by host, followed by device’s

response of PMACK or PMNAK primitives.

3. Check for successful completion of COMWAKE sequence, and the interface speed at the start of the test must match with the interface speed after the COMWAKE sequence.

4. Perform similar verification for repeated portions within this test, where the PMREQ_S

primitives are issued by the host. Observable Results: (See section Observable Results on page 7.)



Possible Problems:


See section Possible Problems on page 9. IPM‐04: NAK of Requests When Support Not Indicated Purpose: To validate that when a Device doesn’t support host interface power management and receives a PMREQ_S or PMREQ_P, the Device should response with a PMNAK. For consistency, this test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI. Resource Requirements: See section Resource Requirements on page 6. Last Modification: July 29, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.



The IPM-04 Test does the following:

1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if HIPM is not supported (WORD 76 bit 9 is cleared to 0). If it is supported, mark test as “N/A”.



3. Verify that PMACK primitives are not received after PMREQ_P primitives are sent. If this

criterion is not fulfilled, test is marked as “FAILED”. If PMNAK primitives are received or there is no response from drive, the test result is a “PASSED”.

4. The test is repeated with PMREQ_S primitives being issued.


1. Within the trace, verify that HIPM is not supported as reflected in the IDENTIFY (PACKET) DEVICE data (WORD 76, bit 9 cleared to 0).

2. Check that PMREQ_P primitives were successfully issued by host.

3. Verify that the device does not respond with PMACK primitives. If there is no response

from the drive, the test result is still a “PASSED”.

4. Perform similar verification for repeated portions within this test, where the PMREQ_S primitives are issued by the host.




Possible Problems: See section Possible Problems on page 9. IPM‐05: Response to PMREQ_P Purpose: To validate that when a Device supports host interface power management and receives a PMREQ_P, it sends the correct responses that include: sends between 4 and 16 PMACK primitives and places the device in Partial state, or it sends PMNAK responses until SYNC is received, with no power transition state change. For consistency, this test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI.


Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.







3. Issue COMWAKE and wait for complete wake of Device.

4. Verify that either PMNAK or more than 4 PMACK primitives are received, after PMREQ_P

primitives are sent. If this criterion is not fulfilled, test is marked as “FAILED”. Post Processing: (See section Post Processing on page 7.)


2. Check that PMREQ_P primitives were successfully issued by host, followed by device’s response of either PMNAK primitives, or 4 or more PMACK primitives.


3. Check for successful completion of COMWAKE sequence. Observable Results: (See section Observable Results on page 7.)



Possible Problems: See section Possible Problems on page 9. IPM‐06: Response to PMREQ_S Purpose: To validate that when a Device supports host interface power management and receives a PMREQ_S, it sends the correct responses that include: sends between 4 and 16 PMACK primitives and places the device in Slumber state, or it sends PMNAK responses until SYNC is received, with no power transition state change. For consistency, this test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





The IPM-06 Test does the following:


2. Issue PMREQ_S primitives and receive device response.

3. Issue COMWAKE and wait for complete wake of Device.

4. Verify that either PMNAK or more than 4 PMACK primitives are received, after PMREQ_S

primitives are sent. If this criterion is not fulfilled, test is marked as “FAILED”. Post Processing: (See section Post Processing on page 7.)


2. Check that PMREQ_S primitives were successfully issued by host, followed by device’s response of either PMNAK primitives, or 4 or more PMACK primitives.

3. Check for successful completion of COMWAKE sequence.




Possible Problems: See section Possible Problems on page 9. IPM‐07: Device Default Setting For Device Initiated Requests Purpose: To validate that when a Device supports host interface power management and this feature is disabled via the SET FEATURES command by default, then the Device shall not issue any


Partial/Slumber requests until the feature is enabled again. For consistency, this test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83.





1. Power cycle device. 2. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command

and check to see if DIPM is supported (WORD 78 bit 3 is set to 1). If not, mark test as “N/A”.

3. Check that DIPM Enabled (WORD 79, bit 3) is cleared to 0.


to enable DIPM. 5. Verify that DIPM is successfully enabled. If this criterion is not fulfilled, test is marked as

“FAILED”.



7. Verify that DIPM Enabled is cleared to 0 after a COMRESET. If this criterion is not fulfilled, test is marked as “FAILED”.


1. Within the trace, verify that DIPM is supported as reflected in the IDENTIFY (PACKET) DEVICE data (WORD 78, bit 3 set to 1).

2. WORD 79, bit 3 should also be cleared to 0 to reflect that by default, DIPM is disabled for the device.

3. Check that the SET FEATURES command was executed successfully and DIPM is

enabled for the device.

4. Verify that COMRESET is completed successfully and DIPM is disabled after the COMRESET.




Possible Problems: See section Possible Problems on page 9. IPM‐08: Device Initiated Power Management Enable/Disable Purpose: To validate that when a Device’s power management has been disabled via the SET FEATURES command, the Device shall not issue Partial/Slumber requests. For consistency, this test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009


Discussion: TBD Test Setup: See section Appendix A: Test Setup Procedure on page 83. Test Procedure: Start Test:

1. Enable Xgig tracing between Host and Device (Optional). 2. Click the IPM-08 Test in the tool to activate this test.

3. Click the Start Tests Button. (This test is automatically executed 10 times)



1. Power cycle device.

2. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command and check to see if DIPM is supported (WORD 78 bit 3 is set to 1). If not, mark test as “N/A”.

3. Check that DIPM Enabled (WORD 79, bit 3) is cleared to 0.


to enable DIPM.

5. Verify that DIPM is successfully enabled. If this criterion is not fulfilled, test is marked as “FAILED”.

6. Leave the device idle and wait for PMREQ_P or PMREQ_S primitives for 10 seconds.

7. If no PMREQ_P or PMREQ_S primitives have been received, issue a STANDBY

IMMEDIATE command. Leave the device idle and wait for these primitives for another 10 seconds.



9. Issue a SET FEATURES command with Sector Count = 03h and Features = 90h to disable DIPM.

10. Verify that DIPM is successfully disabled. If this criterion is not fulfilled, test is marked as

“FAILED”.

11. Leave the device idle and verify that no PMREQ_P or PMREQ_S primitives are received within 10 seconds. If this criterion is not fulfilled, test is marked as “FAILED”.

12. Issue a STANDBY IMMEDIATE command. Leave the device idle and wait for another 10

seconds. Verify that no PMREQ_P or PMREQ_S primitives are received within this period of time. If this criterion is not fulfilled, test is marked as “FAILED”.



2. WORD 79, bit 3 should also be cleared to 0 to reflect that by default, DIPM is disabled for the device.


enabled for the device.

4. Verify that either PMREQ_P or PMREQ_S primitives were issued by the device after it went idle.

5. Check for successful completion of COMWAKE sequence.


disabled for the device.

7. Verify that neither PMREQ_P nor PMREQ_S primitives were issued by the device after it went idle.





Possible Problems: See section Possible Problems on page 9. IPM‐09: Partial State Exit Latency (Device‐Initiated) Purpose: To validate that a Device and Host exit latency from partial state shall start within 10 microseconds from a COMWAKE from the host. This test is executed a total of 10 times. Note: The Host side testing is not supported by this MOI. Status: Informative Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: To determine if the Device latency from a partial wake sequence can be completed within the 10‐microsecond window from COMWAKE receipt. Test Setup: See section Appendix A: Test Setup Procedure on page 83.







2. Issue SET FEATURES to enable DIPM (WORD 79, bit 3 is set to 1) and verify that it is

successfully enabled.

3. Leave the device idle and wait for PMREQ_P primitives for 10 seconds.

4. If no PMREQ_P primitives have been received, issue a STANDBY IMMEDIATE command. Leave the device idle and wait for this primitive for another 10 seconds.


6. Verify that Partial wake sequence completion is within 10 microseconds after COMWAKE is transmitted by host. If this criteria is not fulfilled, test is marked as “FAILED”.




2. Check that the SET FEATURES command was executed successfully and DIPM is enabled (WORD 79, bit 3 is set to 1) for the device.

3. Verify that PMREQ_P primitives were issued by the device after it went idle.

4. Check for successful completion of COMWAKE sequence and COMWAKE response from

device is within a window of 10 microseconds upon receiving COMWAKE from host.

5. Check that the IDENTIFY (PACKET) DEVICE command completed successfully. Observable Results: (See section Observable Results on page 7.)



Possible Problems:


See section Possible Problems on page 9. IPM‐10: Slumber State Exit Latency (Device‐Initiated) Purpose: To validate that a Device and Host exit latency from partial state shall start within 10 milliseconds from a COMWAKE from the host. This test is executed 10 times. Note: The Host side testing is not supported by this MOI. Status: Informative Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: To determine if a device exit latency from the slumber state fails within the 10‐millisecond window from the COMWAKE receipt from the host. Test Setup: See section Appendix A: Test Setup Procedure on page 83.







2. Issue SET FEATURES to enable DIPM (WORD 79, bit 3 is set to 1) and verify that it is successfully enabled.

3. Leave the device idle and wait for PMREQ_S primitives for 10 seconds.

4. If no PMREQ_S primitives have been received, issue a STANDBY IMMEDIATE command.

Leave the device idle and wait for this primitive for another 10 seconds.


6. Verify that Slumber wake sequence completion is within 10 milliseconds after COMWAKE is transmitted by host. If this criterion is not fulfilled, test is marked as “FAILED”.

7. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI)

command. Post Processing: (See section Post Processing on page 7.)



enabled (WORD 79, bit 3 is set to 1) for the device.

3. Verify that PMREQ_S primitives were issued by the device after it went idle.

4. Check for successful completion of COMWAKE sequence and COMWAKE response from device is within a window of 10 milliseconds upon receiving COMWAKE from host.

5. Check that the IDENTIFY (PACKET) DEVICE command completed successfully.






IPM‐11: Speed Matching Upon Resume (Device‐Initiated) Purpose: To validate that a Device signaling speed on returning from power management state matches the speed prior to entering power management mode. This test is executed 10 times. Note: The Host side testing is not supported by this MOI. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: Determine when communication with a device and then waits for it to a request power management capability. If none is detected, issue STANDBY IMMEDIATE command. Next, interface speed is verified to be the same as initial connection speed. Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional).

2. Click the IPM-11 Test in the tool to activate this test. 3. Click the Start Tests Button. (This test is automatically executed 10 times)




2. Set interface speed to the lowest supported speed.


3. Issue SET FEATURES to enable DIPM and verify that it is successfully enabled. 4. Leave the device idle and wait for PMREQ_P primitives for 10 seconds. 5. If no PMREQ_P primitives have been received, issue a STANDBY IMMEDIATE command.

Leave the device idle and wait for this primitive for another 10 seconds. 6. Issue COMWAKE and wait for complete wake of device. 7. Verify that the interface speed matches the interface speed prior to entering Slumber

state. If this criterion is not fulfilled, test is marked as “FAILED”. 8. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI)

command. 9. The test is repeated with verification of receive of PMREQ_S primitive from device. 10. If the device supports multiple Serial ATA interface speed, this test is repeated with all

supported interface speeds. Post Processing: (See section Post Processing on page 7.)



enabled (WORD 79, bit 3 is set to 1) for the device.

3. Check that PMREQ_P primitives were issued by the device after it went idle. 4. Check for successful completion of COMWAKE sequence, and the interface speed at the

start of the test must match with the interface speed after the COMWAKE sequence.

5. Check that the IDENTIFY (PACKET) DEVICE command is completed successfully.

6. Perform similar verification for repeated portions within this test, where the PMREQ_S primitive is issued by the host.





Possible Problems: See section Possible Problems on page 9. DOF‐01: Asynchronous Notification Purpose: To validate that a device supports Asynchronous Notification feature to send a notification to the host that the devices requires attention. This feature should be enabled by the host before the device may set the N Bit to 1 in the Set Devices Bits FIS. This test will be executed 10 times. Note: This test is not applicable to ATA devices. Resource Requirements: See section Resource Requirements on page 6. Last Modification: July 29, 2009 Discussion: This test ensures that the Asynchronous Notification feature can be enabled, disabled, and verifies that the device emits the appropriate FIS messages when required. Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the DOF-01 Test in the tool to activate this test. 3. Click the Start Tests Button (This test is automatically executed 5 times).


analyze the Xgig trace result of this test (Optional). The DOF-01 Test does the following:

1. Power cycle the Device


2. Issue an IDENTIFY PACKET DEVICE (ATAPI) command and check to see if Asynchronous Notification is supported (WORD 78, bit 5 is set to 1),). If not, mark test as “N/A”.

3. Next, the test tool does the following:

• Check Asynchronous Notification Enabled (WORD 79, bit 5) in IDENTIFY PACKET DEVICE (ATAPI) is cleared to 0.

Enable Feature Test • Issue a SET FEATURES command (Sector Count = 05h, Features = 10h) to

enable device support for Asynchronous Notification on the device. • Verify that Asynchronous Notification is successfully enabled. If this criterion is

not fulfilled, test is marked as “FAILED”. If it is fulfilled, do the following: i. Prompt the user to manually press the EJECT button on the ATAPI device

to let the tray or the media out.

ii. Verify that a Set Devices Bits FIS with Interrupt ‘I’ bit set to 1 and Notification ‘N’ bit set to 1, is received. If this criterion is not fulfilled, test is marked as “FAILED”.

iii. Issue a GET EVENT/STATUS NOTIFICATION command to acknowledge

the notification.

iv. Prompt the user to manually push in the media or press the EJECT button to let the tray in.

v. Verify that a Set Devices Bits FIS with Interrupt ‘I’ bit set to 1 and

Notification ‘N’ bit set to 1, is received. If this criterion is not fulfilled, test is marked as “FAILED”.

vi. Issue a GET EVENT/STATUS NOTIFICATION command to acknowledge

the notification. Disable Feature Test: • Issue a SET FEATURES command (Sector Count = 05h, Features = 90h) to

disable device support for Asynchronous Notification on the device. • Verify that Asynchronous Notification is successfully disabled. If this criterion is

not fulfilled, test is marked as “FAILED”. If it is fulfilled, do the following:


i. Prompt the user to manually press the EJECT button on the ATAPI device to let the tray or the media out.

ii. Verify that a Set Devices Bits FIS is not be received. If this criterion is not


iii. Prompt the user to manually push in the media or press the EJECT button to let the tray in.

iv. Verify that a Set Devices Bits FIS is not received. If this criterion is not

fulfilled, test is marked as “FAILED”. Post Processing: (See section Post Processing on page 7.)

1. Within the trace, verify that Asynchronous Notification is supported as reflected in the IDENTIFY PACKET DEVICE data (WORD 78, bit 5 set to 1).

2. WORD 79, bit 5 should also be cleared to 0 to reflect that by default, Asynchronous Notification is disabled for the device.

3. Check that the SET FEATURES command was executed successfully and Asynchronous

Notification is enabled for the device. 4. Verify that Set Device Bits FIS were received respectively after user ejected and returned

the tray of the device. The Set Device Bits FIS should be received with the following criteria: • Interrupt ‘I’ bit = 1 • Notification ‘N’ bit = 1

5. Check that the GET EVENT/STATUS NOTIFICATION command is completed

successfully.

6. Check that the SET FEATURES command was executed successfully and Asynchronous Notification is disabled for the device.

7. Verify that Set Device Bits FIS were not received respectively after user ejected and

returned the tray of the device. Observable Results: (See section Observable Results on page 7.)




Possible Problems: See section Possible Problems on page 9. DOF‐02: Phy Speed Indicator Purpose: To validate that if a device claims support for multiple signaling speeds, then the Phy Speed Indicator, if supported, should be applied to all the speeds claimed by the device. Note: support for this feature is optional, and if WORD 77, bit 3 in IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command is 0, then that indicates that the device doesn’t support this feature. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: This test ensures that the optional Phy Speed Indicator feature is supported for all claimed speeds. Test Setup: See section Appendix A: Test Setup Procedure on page 83.


1. Enable Xgig tracing between Host and Device (Optional). 2. Click the DOF-02 Test in the tool to activate this test. 3. Click the Start Tests Button.


analyze the Xgig trace result of this test (Optional). The DOF-02 Test does the following:


1. Issue an IDENTIFY DEVICE (ATA) or IDENTIFY PACKET DEVICE (ATAPI) command to the device and determine the Supported Interface Speed Grades (WORD 76, bits 3:1).

2. Check the Negotiated Interface Speed (WORD 77, bits 3:1).

3. Check the current interface speed (MOI specific).

4. Verify that the current interface speed matches the negotiated interface speed. If this

criterion is not fulfilled, test is marked as “FAILED”.

5. If the device supports multiple Serial ATA interface speed, this test is repeated with all supported interface speeds.


1. Within the trace, check the Supported Interface Speed Grades as reflected in the IDENTIFY (PACKET) DEVICE data (WORD 76, bit 3:1).

2. Verify that the Negotiated Interface Speed (WORD 77, bits 3:1) matches with the current interface speed.

3. Perform similar verification for repeated portions within this test, where each different

supported speed grades were used. Observable Results: (See section Observable Results on page 7.)





Appendix A: Test Setup Procedure Purpose: Test set up and configuration for performing SATA‐IO UTD testing on a target device using the JDSU compliance Xgig Testing Platform and SATA Compliance Suite Testing Solution. Resource Requirements: See section Resource Requirements on page 6. Last Modification: June 15, 2009 Discussion: The test procedures use a HOST Emulator testing platform and follow the 1.4 testing specifications. Validation of test results is accomplished via on‐screen test results, review of log file test results, and validation of HOST/Device traces. Note: the software tool determines the SATA device type automatically before the tests are executed. As a result, the user must validate the device type before any tests are done. Test Setup:

1. Set up a host system (Running MS Windows) to support JDSU’s Compliance Test Suite Software. The system must be attached to a functional LAN. See Test Setup on page 5 for additional information.

2. Install the JDSU Compliance Test Suite software on the host system using the standard JDSU product installer. The following default path is where the compliance application will be installed:

c:\Program Files\JDSU\Xgig SATA CTS

3. Attach the JDSU Xgig Test Platform to the LAN and from the host system, verify connectivity to/from the LAN.

4. Connect the DUT to one of the ports on the JDSU Xgig Test Platform using the

SAS/SATA Mini horse tail cable. 5. Connect the DUT device power connector to a standard external power supply

connector and power up the DUT, or connect the power controller unit to the DUT and the controlling host via USB (See Appendix B for additional information on setting up the power controller).


6. As a supplemental testing component, the Xgig Analyzer application should be installed on the host system and traces captured during each testing phase to validate each test case.

Test Procedure: 1. Start the JDSU Compliance Test Suite Software application by opening a command

prompt window and typing: c:\Program Files\JDSU\Xgig SATA CTS\tester.exe

Once the application has started the following window will be displayed as shown in Figure 0‐1 below.

Figure 0‐1: JDSU Compliance Testing Suite Main Window


2. Once the window above is shown, click the Setup button. A new dialog window will be displayed as shown in Figure 0‐2 below. Use this window to enter and select Xgig network configuration/target information.

Figure 0‐2: Setup Dialog Window

Enter the IP address of the Xgig system and then select the blade number, and finally the port number where the target device is attached. Then, click the OK button to save this configuration information. As confirmation of your configuration, the Tester Info section of the main window is updated.

3. Next, click the Discover button to automatically determine the type of SATA device connected the Xgig system. If a valid device is found, the device model information is displayed in the Target Information section on the main window.

Note: You must discover a target device before any tests can be executed. If you try to start the tests before the target discovery is made, a dialog message window will be displayed as shown in Figure 0‐3.


Figure 0‐3: Discover Dialog Message

4. Click the Start button to start the compliance test cycle. Test progress will be

displayed in the test result panel.

Observable Results:

• The test results will be shown in the test result pane. Also, the test result file will capture the overall test status and each iteration results.

Appendix B – Setting up the LabJack Device To use the LabJack device to control power to the SATA target device, follow the steps below: Note: You should only attempt to use a power supply that has been designed to accept a power toggle switch using the wiring specified below. If you attempt to use a power unit that has not been designed with a power switch in mind, you risk causing serious damage to the LabJack device and other components. Also serious injury to individuals or fire can result if care is not taken and/or connecting the LabJack to inappropriate power supply units. To Setup the LabJack:

• Install the JDSU Compliance Application using the standard product installer

• Process to next section below “LabJack Connections”

LabJack Connections

Using Figure 5 as a guide, do the following:

• Using a standard USB cable, connect the host end to the JDSU Compliance host system

and connect the other end to the LabJack device. Once this connection is made, the USB LED on the LabJack should illuminate.


• Connect the BLACK power control cable to the SGND terminal post on the LabJack.

• Connect the GREEN power control cable to one of the FIO terminal posts, this terminal location should match the selection within the JDSU Compliance GUI configuration.

• Plug the Power Supply into a house outlet.

• The JDSU Compliance Application should now be able to control the power supply to the target device.

CTS Host Computer

Standard Power Supply

Power Plug

Target DeviceBlack

GreenFI07

SGND

Figure 4: LabJack Setup Diagram

sata digital device moi jdsu utd1.4 1.00

Documents