SAS Verification Test Descriptionscdn.teledynelecroy.com/files/manuals/sas_verification_test_descriptions_v5.70.pdfProtocol Solutions Group . 3385 Scott Blvd., Santa Clara, CA 95054

Protocol Solutions Group 3385 Scott Blvd., Santa Clara, CA 95054 Tel: +1/408.727.6600 Fax: +1/408.727.6622

SAS Verification Test Descriptions

August 2013

Table of Contents

SAS 2.0 Speed Negotiation Window 2 SAS Link Layer Test Suite 50 SAS Transport Layer Test Suite 142 SAS Application Layer 181 NACA Test 210

SAS 2.0 Speed Negotiation

Conformance Test Suite

Technical DocumentRevision 0.5

Working Draft

InterOperability Laboratory 121 Technology Drive, Suite 2University of New Hampshire Durham, NH 03824-3525

Phone: +1-603-862-5083Fax: +1-603-862-4181http://www.iol.unh.edu/

Copyright © 2011 University of New Hampshire InterOperability Laboratory

http://www.iol.unh.edu/

University of New HampshireInterOperability Laboratory

Table of ContentsMODIFICATION RECORD................................................................................................3ACKNOWLEDGEMENTS.................................................................................................4INTRODUCTION................................................................................................................5

OVERVIEW....................................................................................................................5TEST ORGANIZATION.....................................................................................................6REFERENCES....................................................................................................................7GROUP 1: Speed Negotiation Window Three.....................................................................8

OVERVIEW....................................................................................................................8Test 5.7.1.1: Support for SNW-3................................................................................9Test 5.7.1.2: SNTT: Total Time................................................................................11Test 5.7.1.3: SNNT: Remainder Time......................................................................13Test 5.7.1.4: Rate Change Delay Time.....................................................................15Test 5.7.1.5: Phy Capabilities Bits – Start Bit..........................................................17Test 5.7.1.6: Phy Capabilities Bits – TX SSC Type..................................................19Test 5.7.1.7: Phy Capabilities Bits – Reserved Bits.................................................21Test 5.7.1.8: Phy Capabilities Bits – G1 WITHOUTs SSC......................................23Test 5.7.1.9: Phy Capabilities Bits – G1 WITH SSC...............................................25Test 5.7.1.10: Phy Capabilities Bits – G2 WITHOUT SSC.....................................26Test 5.7.1.11: Phy Capabilities Bits – G2 WITH SSC..............................................28Test 5.7.1.12: Phy Capabilities Bits – G3 WITHOUT SSC.....................................29Test 5.7.1.13: Phy Capabilities Bits – G3 WITH SSC.............................................30Test 5.7.1.14: Phy Capabilities Bits – Reserved Bits...............................................31Test 5.7.1.15: Phy Capabilities – Parity Bit..............................................................33Test 5.7.1.16: Receive Bad Parity.............................................................................35Test 5.7.1.17: No Common Speeds..........................................................................37

GROUP 2: Train Speed Negotiation Window...................................................................39OVERVIEW..................................................................................................................39

Test 5.7.2.1: TRAIN Pattern.....................................................................................40Test 5.7.2.2: TRAIN_DONE Pattern........................................................................42Test 5.7.2.3: Negotiate to 6G, SSC...........................................................................44Test 5.7.2.4: Negotiate to 6G, No SSC.....................................................................46Test 5.7.2.5: Negotiate to 6G, Fail SSC....................................................................48

UNH-IOL SAS 2.0 Speed Negotiation2 of 49


MODIFICATION RECORDDate Revision Comments

06-25-2007 0.1 Initial version

06-29-2007 0.2 Fixed References, Title, minor typographical changes.

07-20-2007 0.3 Added to discussions on selected tests. Expanded on procedures for all tests.

08-01-2007 0.4 Updated to reflect SAS2r11 Standard. Added several tests to Group 1. Adjusted Purpose and Discussion sections on tests in Group 1.

05/31/11 0.5 Fixed values in test 6.7.1.3

8/5/2011 0.6 Updated References



ACKNOWLEDGEMENTSThe University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite:

Michael Davidson University of New HampshireMichael Klempa University of New Hampshire



INTRODUCTIONOVERVIEW

The University of New Hampshire's InterOperability Laboratory (IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. This particular suite of tests has been developed to help implementers evaluate the functionality of their Serial Attached SCSI (SAS) products. Specifically, this test suite is directed at verifying 6.0 Gbps Speed Negotiation in SAS Targets, Initiators, and Expanders.

These tests are designed to determine if a SAS product conforms to the specifications defined in T10/Project 2124-D/Rev 07 – SAS Protocol Layer (SPL). Successful completion of all tests contained in this suite does not guarantee that the tested device will successfully operate with other SAS products. However, when combined with satisfactory operation in the IOL’s interoperability test bed, these tests provide a reasonable level of confidence that the Device Under Test (DUT) will function properly in many SAS environments.



TEST ORGANIZATIONThis document organizes tests by group based on related test methodology or goals. Each group begins with a brief set of comments pertaining to all tests within that group. This is followed by a series of description blocks; each block describes a single test. The format of the description block is as follows:Test Label: The Test Label is a period-delimited list composed of the group number and test

number within the group. That is, Test Label Test 1.2 refers to the 2nd test in the 1st group of this test suite. The Test Label is immediately followed by a brief test name.

Purpose: The Purpose is a short statement describing what the test attempts to achieve. It is usually phrased as a simple assertion of the feature or capability to be tested.

References: The References section lists cross-references to specifications and documentation that may aid in the evaluation of the test and any results it generates.

Resource Requirements: The Resource Requirements must be met before the test can be performed. This includes basic equipment and devices to be tested.

Modification Record: The Modification Record is a record all changes and alterations to the specific test throughout the life of the document.

Discussion: The Discussion is a general discussion of the test and relevant section of the specification, including any assumptions made in the design or implementation of the test as well as known limitations.

Test Setup: The Test Setup section describes the configuration of all devices prior to the start of the test. Different parts of the procedure may involve configuration steps that deviate from what is given in the test setup. If a value is not provided for a protocol parameter, then the protocol's default is used.

Procedure: The Procedure contains the step-by-step instructions for carrying out the test. These steps might range from enabling interfaces, disconnecting devices from the network, using a test station to capture and/or transmit data, device configuration, and miscellaneous other test-related tasks.

Observable Results: The Observable Results section enumerates the specific test results that may be evaluated by the tester in order to determine and outcome for the test (e.g. PASS, FAIL). The section also indicates how each result should be interpreted. The determination of a PASS or FAIL for each test is usually based on how the observed test results compare with the results described in this section.

Possible Problems: This section contains a description of known issues with the test procedure which may affect test results in some cases.



REFERENCESThe following documents are referenced in this suite:

● T10/Project 2124-D/Rev 07 – SAS Protocol Layer (SPL)



GROUP 1: S p e e d Nego t ia t i o n W i n d o w ThreeOVERVIEW

The following tests cover Speed Negotiation Window 3 (SNW-3).



Test 5.7.1.1: Support for SNW-3Purpose

To verify the DUT's support for SNW-3.References

● 5.7.4.2.2 SAS SPL● 5.7.4.2.3.3 SAS SPL

Resource Requirements● A Protocol Generator/Analyzer capable of transmitting and receiving SAS OOB signals

and SAS 2.0 Speed Negotiation.Modification Record

● 06-25-2007: Initial Draft (Michael Davidson).● 06-29-2007: Fixed references, changed title numbering (Michael Davidson).● 07-20-2007: Expanded procedure (Michael Davidson).● 08-5-2011: Updated references (Joshua Beaudet)

DiscussionIf a phy supports SNW-3, then the phy:

a) transmits a 32-bit phy capabilities value describing the capabilities of they phy.b) receives a 32-bit phy capabilities value from the attached phy. If the attached phy

does not support SNW-3, they phy capabilities bits are all set to zero (i.e., D.C. Idle).

If a phy does not support SNW-3, then a phy:a) transmits D.C. Idle.b) ignores any SNW-3 phy capabilities bits received.

Test Setup● The DUT and the Testing Station are physically connected the the DUT is powered off.

Procedure1. Power on the DUT.2. The testing station is instructed to transmit COMINIT/COMRESET to the DUT.3. The DUT is expected to respond with COMINIT/COMRESET.4. The testing station is instructed to transmit COMSAS to the DUT.5. The DUT is expected to respond with COMSAS.6. Upon reception of COMSAS from the DUT, the Testing station is instructed to transmit

D.C. Idle for one RCDT. The DUT is expected to do the same. 7. Following RCDT, the testing station is instructed to transmit ALIGN(0) primitives at 1.5

Gbps for one SNTT. If the DUT supports 1.5 Gbps signaling, it is expected to do the same. If the DUT does not support 1.5 Gbps signaling, it should continue to transmit D.C. Idle.

8. The Testing station is then instructed to transmit D.C. Idle for one RCDT. If the DUT supports 3.0 Gbps. The DUT is expected to do the same.

9. Following RCDT, the testing station is instructed to transmit ALIGN(1) primitives at 3.0 Gbps for one SNTT. If the DUT supports 3.0 Gbps signaling, it is expected to the same.

10. The Testing Station is then instructed to transmit D.C. Idle for one RCDT. The DUT is expected to do the same.



11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating support for all speeds and SSC settings. The DUT is expected to transmit it's Phy Capabilities Bits.

Observable Results● Verify that following the last ALIGN (1) primitive transmitted during SNW-2 by the

DUT, there is 500.00 µs of D.C. Idle transmitted by the DUT followed by a COMWAKE signal.

Possible Problems● If the DUT does not support 3.0 Gbps signaling, then it will not participate in SNW-2. If

this is the case, an alternative method of timing the first COMWAKE signal during SNW-3 will have to be found.



Test 5.7.1.2: SNTT: Total TimePurpose

To verify that the DUT properly formats it's SNTT.References

● 5.7.4.2.2 SAS SPL● 5.7.4.2.3.3 SAS SPL








The first bit of the phy capabilities value is the START bit and shall be transmitted as a one. Each of the remaining 31 bits are a one or a zero.Test Setup

● The DUT and the Testing Station are physically connected the the DUT is powered off.Procedure

1. Power on the DUT.2. The testing station is instructed to transmit COMINIT/COMRESET to the DUT.3. The DUT is expected to respond with COMINIT/COMRESET.4. The testing station is instructed to transmit COMSAS to the DUT.5. The DUT is expected to respond with COMSAS.6. Upon reception of COMSAS from the DUT, the Testing station is instructed to transmit









Observable ResultsVerify that the time between the first COMWAKE signal transmitted in SNW-3 and the

next transmitted dword to be approximately 609.23 µs. Possible Problems

● None.



Test 5.7.1.3: SNNT: Remainder TimePurpose


● 5.7.4.2.2 SAS SPL● 5.7.4.2.3.3 SAS SPL



● 06-25-2007: Initial Draft (Michael Davidson).● 06-29-2007: Fixed references, changed title numbering (Michael Davidson).● 07-20-2007: Expanded procedure (Michael Davidson).● 05-31-2011: Fixed values in Observable Results (Joshua Beaudet)● 08-5-2011: Updated references (Joshua Beaudet)





The first bit of the phy capabilities value is the START bit and shall be transmitted as a one. Each of the remaining 31 bits are a one or a zero. Assuming the PARITY bit of the of the 32-bit phy capabilities value is set, there should be a minimum of 62294.8 µs of idle transmitted before the start of the next RCDT.Test Setup





8. The Testing station is then instructed to transmit D.C. Idle for one RCDT. If the DUT



supports 3.0 Gbps. The DUT is expected to do the same.9. Following RCDT, the testing station is instructed to transmit ALIGN(1) primitives at 3.0

Gbps for one SNTT. If the DUT supports 3.0 Gbps signaling, it is expected to the same. 10. The Testing Station is then instructed to transmit D.C. Idle for one RCDT. The DUT is

expected to do the same. 11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating

support for all speeds and SSC settings. The DUT is expected to transmit it's Phy Capabilities Bits.

Observable Results● Verify that following the last COMWAKE signal transmitted during SNW-3 by the DUT,

there is at least 562 µs of D.C. Idle transmitted by the DUT. Possible Problems

● None.



Test 5.7.1.4: Rate Change Delay TimePurpose


● 5.7.4.2.2 SAS SPL● 5.7.4.2.3.3 SAS SPL








The transmitter shall:a) transmit D.C. Idle for an RCDT.b) transmit 32 phy capabilities bits.c) transmit D.C. Idle for the remainder of SNTT.











Observable Results● Verify that prior to the transmission of the START bit of the of the phy capabilities bits

in SNW-3, at least 500 µs of D.C. Idle is transmitted. Possible Problems

● None.



Test 5.7.1.5: Phy Capabilities Bits – Start BitPurpose

To verify that bit 0 of the phy capabilities bits is set to one.References

● 5.7.4.2.3.3 SAS SPLResource Requirements

● A Protocol Generator/Analyzer capable of transmitting and receiving SAS OOB signals and SAS 2.0 Speed Negotiation.

Modification Record● 06-25-2007: Initial Draft (Michael Davidson).● 06-29-2007: Fixed references, changed title numbering (Michael Davidson).● 07-20-2007: Expanded procedure (Michael Davidson).● 08-01-2007: Removed irrelevant information from the discussion. Corrected

title/discussion for new capabilities naming conventions (Michael Davidson).● 08-5-2011: Updated references (Joshua Beaudet)

DiscussionThe START bit shall be set to one. The phy's receiver shall use this bit to establish the

timing for the subsequent bits. Test Setup









Observable Results● Verify that prior to the transmission of the START bit of the of the phy capabilities bits



in SNW-3, at least 500 µs of D.C. Idle is transmitted. Possible Problems

● None.



Test 5.7.1.6: Phy Capabilities Bits – TX SSC TypePurpose

To verify that bit 1 of the phy capabilities bits correctly reflects the method of Spread Spectrum Clocking employed by the DUT.References





DiscussionA TX SSC TYPE bit set to one indicates that the phy's transmitter uses center-spreading

SSC when the SSC is enabled. A TX SSC TYPE bit set to zero indicates that the phy's transmitter uses down-spreading SSC when SSC is enabled, or that the phy does not support SSC.Test Setup











Observable Results● If the DUT employs center-spreading SSC when SSC is enabled, verify that 1.446 µs

after the beginning of the first COMWAKE signal transmitted during SNW-3, a second COMWAKE signal is transmitted. Otherwise, verify that the DUT transmits at least 1.446 µs of D.C. Idle following the first COMWAKE signal transmitted during SNW-3.

Possible Problems● The method of SSC employed by the DUT will have to be determined by a lower level

PHY test.



Test 5.7.1.7: Phy Capabilities Bits – Reserved BitsPurpose

To verify that bits 2 and 3 of the phy capabilities bits are set to zero.References





DiscussionBits 2 and 3 of the phy capabilities bits are reserved and shall be set to zero.









Observable Results● Verify that from 2.933 µs from the beginning of the first COMWAKE signal transmitted

as part of SNW-3 to 5.866 µs from the beginning of the first COMWAKE signal



transmitted as part of SNW-3, there are no COMWAKE signals transmitted.Possible Problems

● None.



Test 5.7.1.8: Phy Capabilities Bits – G1 WITHOUTs SSCPurpose

To verify the contents of the DUT's Phy Capabilities G1 WITHOUT SSC bit.References





DiscussionA G1 WITHOUT SSC bit set to one indicated that the phy supports G1 (i.e., 1,5 Gbps)

without SSC. A G1 WITHOUT SSC bit set to zero indicates that the phy does not support G1 without SSC. If the phy supports SNW-1 and supports SNW-3, then the G1 WITHOUT SSC bit shall be set to one.Test Setup











Observable Results● If the DUT participated in SNW-1, then verify that 11.733 µs from the beginning of the

first COMWAKE signal transmitted as part of SNW-3, a COMWAKE signal is transmitted, indicating support for G1 WITHOUT SSC .

Possible Problems● None.



Test 5.7.1.9: Phy Capabilities Bits – G1 WITH SSCPurpose

To verify the contents of the DUT's Phy Capabilities G1 WITH SSC bit.References



Modification Record● 08-01-2007: Initial Draft (Michael Davidson).● 08-5-2011: Updated references (Joshua Beaudet)

DiscussionA G1 WITH SSC bit set to one indicated that the phy supports G2 (i.e., 1.5 Gbps) with

SSC. A G1 WITH SSC bit set to zero indicates that the phy does not support G1 with SSC. This is an informative test and applies only if the DUT supports SSC signaling.Test Setup









Observable Results● Verify the contents of the G1 WITHOUT SSC bit from the DUT's Phy Capabilities bits.

Possible Problems● This is an informative test.



Test 5.7.1.10: Phy Capabilities Bits – G2 WITHOUT SSCPurpose






DiscussionA G2 WITHOUT SSC bit set to one indicated that the phy supports G2 (i.e., 3,0 Gbps)

without SSC. A G2 WITHOUT SSC bit set to zero indicates that the phy does not support G2 without SSC. If the phy supports SNW-2 and supports SNW-3, then the G2 WITHOUT SSC bit shall be set to one.Test Setup











Observable Results● If the DUT participated in SNW-2, then verify that 14.666 µs from the beginning of the

first COMWAKE signal transmitted as part of SNW-3, a COMWAKE signal is transmitted, indicating support for G2 WITHOUT SSC .









DiscussionA G2 WITH SSC bit set to one indicated that the phy supports G2 (i.e., 3.0 Gbps) with

SSC. A G2 WITH SSC bit set to zero indicates that the phy does not support G2 with SSC. This is an informative test and applies only if the DUT supports SSC signaling.Test Setup













Test 5.7.1.12: Phy Capabilities Bits – G3 WITHOUT SSCPurpose





DiscussionA G3 WITHOUT SSC bit set to one indicated that the phy supports G3 (i.e., 6.0 Gbps)

without SSC. A G3 WITHOUT SSC bit set to zero indicates that the phy does not support G3 without SSC. This is an informative test and applies only if the DUT supports 6.0 Gbps signaling.Test Setup


















DiscussionA G3 WITH SSC bit set to one indicated that the phy supports G3 (i.e., 6.0 Gbps)

without SSC. A G3 WITH SSC bit set to zero indicates that the phy does not support G3 without SSC. This is an informative test and applies only if the DUT supports 6.0 Gbps signaling.Test Setup









Observable Results● Verify the contents of the G3 WITH SSC bit from the DUT's Phy Capabilities bits.




Test 5.7.1.14: Phy Capabilities Bits – Reserved BitsPurpose

To verify that the Phy Capabilities Bits 14 through 30 are set to zero. References





DiscussionTable 88 defines the SNW-3 phy capabilities. For each bit defined as reserved, the phy

shall transmit a zero (i.e., D.C. Idle) and shall ignore the received value. Byte 1, bits 1 and 0; and byte 2 are reserved. Test Setup









Observable Results



● Verify that 20.5324 µs from the beginning of the first COMWAKE signal transmitted in SNW-3, that there is at least 23.4656 µs of D.C. Idle.




Test 5.7.1.15: Phy Capabilities – Parity BitPurpose

To verify that the Phy Capabilities Bit 31, the Parity Bit, is correctly set.References



Modification Record● 06-25-2007: Initial Draft (Michael Davidson).● 06-29-2007: Fixed references, changed title numbering (Michael Davidson).● 07-20-2007: Expanded procedure (Michael Davidson).● 08-01-2007: Removed irrelevant information from discussion, provided observable

results (Michael Davidson).● 08-5-2011: Updated references (Joshua Beaudet)

DiscussionThe PARITY bit provides for error detection of all the SNW-3 phy capabilities bits. The

PARITY bit shall be set to one or zero such that the total number of SNW-3 phy capabilities bits that are set to one is even including the START bit and the PARITY bit. If the Parity bit received is incorrect based upon the received bits, then the parity is bad and the phy shall consider a phy reset problem.Test Setup








11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating support for all speeds and SSC settings. The DUT is expected to transmit it's Phy



Capabilities Bits.Observable Results

● If an odd number of Phy Capabilities Bits (excluding parity) has been transmitted, ensure that the parity bit has been set. If an even number of Phy Capabilities Bits (excluding parity) has been transmitted, ensure that the parity bit is not set.




Test 5.7.1.16: Receive Bad ParityPurpose

To verify that the DUT properly handles reception of an improperly set parity bit during SNW-3.References




title/discussion for new capabilities naming conventions.● 08-5-2011: Updated references (Joshua Beaudet)

DiscussionThe PARITY bit provides for error detection of all the SNW-3 phy capabilities bits. The

PARITY bit shall be set to one or zero such that the total number of SNW-3 phy capabilities bits that are set to one is even including the START bit and the PARITY bit. If the Parity bit received is incorrect based upon the received bits, then the parity is bad and the phy shall consider a phy reset problem.Test Setup








11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating



support for all speeds and SSC settings. The Testing Station is instructed to transmit an incorrect parity bit. The DUT is expected to transmit it's Phy Capabilities Bits.

Observable Results● The DUT should wait 1 Hot-plug timeout period and then transmit COMINIT to the

testing station. Possible Problems

● None.



Test 5.7.1.17: No Common SpeedsPurpose

To verify that the DUT behaves properly when it does not share any common speeds with the link partner.References



Modification Record● 06-25-2007: Initial Draft (Michael Davidson).● 06-29-2007: Fixed references, changed title numbering (Michael Davidson).● 07-20-2007: Expanded procedure (Michael Davidson).● 08-01-2007: Updated for new standard release (Michael Davidson).● 08-5-2011: Updated references (Joshua Beaudet)

DiscussionIf a phy participates in a valid SNW-3 and parity is good, then the phy shall participate in

a Train-SNW utilizing the highest commonly settings based on the outgoing and incoming SNW-3 settings bits.

They phy shall consider SNW-3 to be valid if it supports SNW-3 and receive at least one phy capabilities bit set to one. If the phy does not support SNW-3 or does not receive at least one phy capabilities bit set one tone, it shall consider SNW-3 to be invalid. Test Setup








11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating no



support for any speeds or SSC settings. The DUT is expected to transmit it's Phy Capabilities Bits.

Observable Results● The DUT should wait 1 Hot-plug timeout period and then transmit COMINIT to the

testing station. Possible Problems

● None.



GROUP 2: Train S p e e d Nego t ia t i o n W i n d o wOVERVIEW

The following tests cover the Train Speed Negotiation Window.



Test 5.7.2.1: TRAIN PatternPurpose

To verify that the DUT sends the proper TRAIN pattern.References



Modification Record● 06-25-2007: Initial Draft (Michael Davidson).● 06-29-2007: Fixed references, changed title numbering (Michael Davidson).● 07-20-2007: Expanded procedure (Michael Davidson).● 08-5-2011: Updated references (Joshua Beaudet)

DiscussionThe Train-SNW utilizes TRAIN and TRAIN_DONE primitives to create training

patterns. There are two training patterns:a) the TRAIN pattern; andb) the TRAIN_DONE pattern.

The TRAIN pattern consists of:a) TRAIN; andb) 58 dwords set to 0000_0000h that are transmitted scrambled and 8b10b encoded.

The phy shall start transmitting TRAIN patterns at the end of RCDT. The first TRAIN pattern may have either starting disparity. The Number of TRAIN patters transmitted is determined by the time required for the phy's receiver to complete training. The phy shall transmit at least one TRAIN pattern.Test Setup











12. The Testing Station is instructed to transmit D.C. Idle for one RCDT. The DUT is expected to do the same.

13. The Testing Station is instructed to then transmit properly formatted TRAIN patterns at the highest mutually speed. The DUT is expected to do the same.

Observable Results● Verify that the DUT first transmits properly formatted TRAIN patterns at the highest

mutually speed. A properly formatted TRAIN pattern consists of:○ TRAIN; and○ 58 dwords set to 0000_0000h that are transmitted scrambled and 8b10b encoded.




Test 5.7.2.2: TRAIN_DONE PatternPurpose

To verify that the DUT sends the proper TRAIN_DONE pattern.References




DiscussionThe Train-SNW utilizes TRAIN and TRAIN_DONE primitives to create training

patterns. There are two training patterns:a) the TRAIN pattern; andb) the TRAIN_DONE pattern.

The TRAIN_DONE pattern consists of:a) TRAIN_DONE; andb) 58 dwords set to 0000_0000h that are transmitted scrambled and 8b10b encoded.

The phy shall start transmitting TRAIN patterns at the end of RCDT. The first TRAIN pattern may have either starting disparity. The Number of TRAIN patters transmitted is determined by the time required for the phy's receiver to complete training. The phy shall transmit at least one TRAIN pattern.

If the phy's receiver is trained and acquires synchronization before TLT, then the phy shall stop transmitting TRAIN patters and start transmitting TRAIN_DONE patters. The Phy shall transmit a minimum of four TRAIN_DONE patterns.Test Setup





8. The Testing station is then instructed to transmit D.C. Idle for one RCDT. If the DUT



supports 3.0 Gbps. The DUT is expected to do the same.9. Following RCDT, the testing station is instructed to transmit ALIGN(1) primitives at 3.0

Gbps for one SNTT. If the DUT supports 3.0 Gbps signaling, it is expected to the same. 10. The Testing Station is then instructed to transmit D.C. Idle for one RCDT. The DUT is

expected to do the same. 11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating

support for all speeds and SSC settings. The DUT is expected to transmit it's Phy Capabilities Bits.



14. Upon successful reception of a properly formatted TRAIN pattern from the DUT, the testing station is instructed to transmit a properly formatted TRAIN_DONE pattern to the DUT for the remainder MTT. The DUT is expected to do the same upon successful reception of a TRAIN pattern from the testing station.

Observable Results● After transmitting at least one TRAIN pattern, the DUT should then transmit four

properly formatted TRAIN_DONE patterns to the testing station.● A properly formatted TRAIN_DONE pattern consists of:

○ TRAIN_DONE; and○ 58 dwords set to 0000_0000h that are transmitted scrambled and 8b10b encoded.




Test 5.7.2.3: Negotiate to 6G, SSCPurpose

To verify that the DUT negotiates to 6G signaling with no SSC.References




DiscussionActual Training Time starts after RCDT and ends when receiver dword synchronization

is obtained. The phy transmits the TRAIN pattern starting after RCDT. A minimum of one TRAIN pattern shall be transmitted. When Actual Training Time ends, the phy transitions to transmitting TRAIN_DONE patterns. If Actual Training Time does not end before Training Lock Time, then the phy does not transition to transmitting the TRAIN_DONE pattern.

The phy transitions to transmitting Link Layer dwords after transmitting a minimum of four TRAIN_DONE patterns and receiving one TRAIN_DONE pattern. This represents the valid end of Train-SNW and the beginning of normal link layer operation. If a phy has not transmitted at least four TRAIN_DONE patterns and received at least one TRAIN_DONE within Maximum Training Time, then the Train-SNW is invalid. This test only applies to devices that support 6.0 Gbps signaling with SSC.Test Setup










11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating support for all speeds. The Testing Station is instructed to indicate that it does not support 6.0 Gbps signaling without SSC. The DUT is expected to transmit it's Phy Capabilities Bits.




Observable Results● Verify that the DUT transmits at least one TRAIN pattern and at least four

TRAIN_DONE patterns at 6G with SSC before MTT has expired. Possible Problems

● Lower level testing will have to be used to verify that the DUT enabled SSC properly.



Test 5.7.2.4: Negotiate to 6G, No SSCPurpose







The phy transitions to transmitting Link Layer dwords after transmitting a minimum of four TRAIN_DONE patterns and receiving one TRAIN_DONE pattern. This represents the valid end of Train-SNW and the beginning of normal link layer operation. If a phy has not transmitted at least four TRAIN_DONE patterns and received at least one TRAIN_DONE within Maximum Training Time, then the Train-SNW is invalid. This test only applies to devices that support 6.0 Gbps signaling.Test Setup










11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating support for all speeds. The Testing Station is instructed to indicate that it does not support 6.0 Gbps signaling with SSC. The DUT is expected to transmit it's Phy Capabilities Bits.





TRAIN_DONE patterns at 6G without any SSC before MTT has expired. Possible Problems

● Lower level testing will have to be used to verify that the DUT did not enable SSC.



Test 5.7.2.5: Negotiate to 6G, Fail SSCPurpose







The phy transitions to transmitting Link Layer dwords after transmitting a minimum of four TRAIN_DONE patterns and receiving one TRAIN_DONE pattern. This represents the valid end of Train-SNW and the beginning of normal link layer operation. If a phy has not transmitted at least four TRAIN_DONE patterns and received at least one TRAIN_DONE within Maximum Training Time, then the Train-SNW is invalid.

If a Train-SNW is invalid and there are additional, untried, commonly settings exchanged during SNW-3, then a new Train-SNW shall be performed at the next highest, untried, commonly capability. This test only applies to devices that support 6.0 Gbps signaling.Test Setup










11. The Testing Station is the instructed to transmit its Phy Capabilities bits indicating support for all speeds. The Testing Station is instructed to indicate that it supports all speeds and SSC settings. The DUT is expected to transmit it's Phy Capabilities Bits.


13. The Testing Station is instructed to then transmit properly formatted TRAIN patterns at the highest mutually speed (6.0 Gbps, SSC). The DUT is expected to do the same.

14. Upon successful reception of a properly formatted TRAIN pattern from the DUT, the testing station is instructed to not transmit a TRAIN_DONE pattern. The DUT is expected to receive the properly formatted TRAIN pattern and being transmitting TRAIN_DONE patterns.

15. Upon expiration of the MTWT timer, the Testing station is instructed to stop transmitting TRAIN patterns and begin Transmitting D.C. Idle for one RCDT. The DUT is expected to do the same.

16. After RCDT, the testing station is instructed to transmit properly formatted TRAIN patters at the next highest mutually speed (6.0 Gbps, No SSC). The DUT is expected to do the same.

17. Upon successful reception of a properly formatted TRAIN pattern from the DUT, the testing station is instructed to transmit TRAIN_DONE patterns. The DUT is expected to do the same upon reception of a properly formatted TRAIN pattern received from the testing station.


TRAIN_DONE patterns at 6G with SSC before MTT has expired. Verify that the DUT waits one RCDT and participates in the second Train-SNW with the testing station.

● Verify that the DUT transmits at least one TRAIN pattern and at least four TRAIN_DONE patterns at 6G with no SSC before MTT has expired.

Possible Problems● Lower level testing will have to be used to verify that the DUT enabled SSC properly.


SERIAL ATTACHED SCSI (SAS) CONSORTIUM

Clause 6

SAS SPL Link Layer Test Suite Version 1.3

Technical Document

Last Updated: 6 September 2011

Serial Attached SCSI Consortium 121 Technology Drive, Suite 2 InterOperability Laboratory Durham, NH 03824 University of New Hampshire Phone: (603) 862-3582 Fax: (603) 862-4181 http://www.iol.unh.edu/consortiums/sas

© 2011 University of New Hampshire InterOperability Laboratory

http://www.iol.unh.edu/consortiums/sas

The University of New Hampshire InterOperability Laboratory TABLE OF CONTENTS

TABLE OF CONTENTS........................................................................................2

MODIFICATION RECORD ..................................................................................5

ACKNOWLEDGMENTS .......................................................................................6

INTRODUCTION....................................................................................................7

REFERENCES.........................................................................................................9

GROUP 1: LINK LAYER TESTS FOR TARGETS ..........................................10 TEST 6.1.1 - LINK RESET – REPEAT PHY SEQUENCE IF NO IDENTIFY RECEIVED.. 11 TEST 6.1.2 - LINK RESET – IGNORE ADDITIONAL IDENTIFY RECEIVED.................. 12 TEST 6.1.3 - LINK RESET – HARD_RESET RECEIVED .................................................... 13 TEST 6.1.4 - CONNECTIONS – OPEN_ACCEPT ................................................................. 14 TEST 6.1.5 - CONNECTIONS – 2 SOAF RECEIVED ........................................................... 15 TEST 6.1.6 - CONNECTIONS - OPEN_REJECT CONNECTION RATE NOT SUPPORTED................................................................................................................................................... 16 TEST 6.1.7 - CONNECTIONS - OPEN_REJECT PROTOCOL NOT SUPPORTED............. 17 TEST 6.1.8 - CONNECTIONS - OPEN_REJECT WRONG DESTINATION........................ 18 TEST 6.1.9 - CONNECTIONS - OPEN_REJECT RETRY ..................................................... 19 TEST 6.1.10 - SSP_FRAMES – INTERLOCKED FRAME.................................................... 20 TEST 6.1.11 - SSP_FRAMES - NO ACK FOR INTERLOCKED FRAME............................ 21 TEST 6.1.12 - SSP_FRAMES – MULTIPLE ACKS................................................................ 22 TEST 6.1.13 - SSP FRAMES - RRDY ..................................................................................... 23 TEST 6.1.14 - CLOSING SSP CONNECTIONS – DONE (NORMAL) .................................. 24 TEST 6.1.15 - CLOSING SSP CONNECTIONS – DONE (ACK/NAK TIMEOUT) ............. 25 TEST 6.1.16 - CLOSING SSP CONNECTIONS – DONE (CREDIT TIMEOUT) ................. 26 TEST 6.1.17 - CLOSING SSP CONNECTIONS – CLOSE (NORMAL)................................ 27 TEST 6.1.18 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY TESTING STATION .................................................................................................................................. 28 TEST 6.1.19 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY DUT ................ 29 TEST 6.1.20 - CONNECTIONS THROUGH EXPANDERS – OPEN SSP TARGET ............ 30 TEST 6.1.21 - BREAK – OPENTIMEOUT TIMER SSP TARGET ........................................ 31 TEST 6.1.22 - CLOSING SSP CONNECTIONS – CLOSE (CLEAR AFFILIATION)............ 32 TEST 6.1.23 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 0) .......................... 33 TEST 6.1.24 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 1) .......................... 34 TEST 6.1.25 - LINK RESET – HARD_RESET RECIVED AFTER IDENTIFY..................... 35 TEST 6.1.26 - SSP_FRAMES – INTERLOCKED FRAME / NAK ......................................... 36

GROUP 2: LINK LAYER TESTS FOR INITIATORS .....................................37 TEST 6.2.1 - LINK RESET – REPEAT PHY SEQUENCE IF NO IDENTIFY RECEIVED.. 38 TEST 6.2.2 - LINK RESET – IGNORE ADDITIONAL IDENTIFY RECEIVED.................. 39

Serial Attached SCSI Consortium 2 Clause 6 SAS SPL Link Layer Test Suite v1.3

TEST 6.2.3 - LINK RESET – HARD_RESET RECEIVED .................................................... 40

The University of New Hampshire InterOperability Laboratory

TEST 6.2.4 - LINK RESET – SMP INITIATOR TO PERFORM DISCOVER ....................... 41 TEST 6.2.5 - LINK RESET – EDGE EXPANDER TRANSMITS OPEN_REJECT............... 42 TEST 6.2.6 - CONNECTIONS – OPEN_ACCEPT ................................................................. 43 TEST 6.2.7 - CONNECTIONS – 2 DIFFERENT SOAF RECEIVED..................................... 44 TEST 6.2.8 - CONNECTIONS - OPEN_REJECT CONNECTION RATE NOT SUPPORTED................................................................................................................................................... 45 TEST 6.2.9 - CONNECTIONS - OPEN_REJECT PROTOCOL NOT SUPPORTED............. 46 TEST 6.2.10 - CONNECTIONS - OPEN_REJECT WRONG DESTINATION...................... 47 TEST 6.2.11 - CONNECTIONS - OPEN_REJECT RETRY ................................................... 48 TEST 6.2.12 - SSP_FRAMES – MULTIPLE ACKS ................................................................ 49 TEST 6.2.13 - SSP FRAMES - RRDY ..................................................................................... 50 TEST 6.2.14 - COSING SSP CONNECTIONS – DONE (NORMAL)..................................... 51 TEST 6.2.15 - CLOSING SSP CONNECTIONS – DONE (ACK/NAK TIMEOUT) ............. 52 TEST 6.2.16 - CLOSING SSP CONNECTIONS – DONE (CREDIT TIMEOUT) ................. 53 TEST 6.2.17 - CLOSING SSP CONNECTIONS – CLOSE (NORMAL)................................ 54 TEST 6.2.18 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY TESTING STATION .................................................................................................................................. 55 TEST 6.2.19 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY DUT ................ 56 TEST 6.2.20 - CONNECTIONS THROUGH EXPANDER – OPEN SSP INITIATOR .......... 57 TEST 6.2.21 - CONNECTIONS THROUGH EXPANDERS – OPEN SMP INITIATOR ...... 58 TEST 6.2.22 - CLOSING SSP CONNECTIONS – CLOSE (CLEAR AFFILIATION)............ 59 TEST 6.2.23 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 0) .......................... 60 TEST 6.2.24 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 1) .......................... 61

GROUP 3: LINK LAYER TESTS FOR EXPANDERS.....................................62 TEST 6.3.1 - LINK RESET – REPEAT PHY SEQUENCE IF NOT IDENTIFY RECEIVED 63 TEST 6.3.2 - IGNORE ADDITONAL IDENTIFY RECEIVED .............................................. 64 TEST 6.3.3 - LINK RESET – HARD_RESET RECEIVED .................................................... 65 TEST 6.3.4 - CONNECTIONS – OPEN_ACCEPT ................................................................. 66 TEST 6.3.5 - CONNECTIONS – 2 SOAF RECEIVED ........................................................... 67 TEST 6.3.6 - CONNECTIONS - OPEN_REJECT NO DESTINATION ................................. 68 TEST 6.3.7 - CONNECTIONS - OPEN_REJECT BAD DESTINATION............................... 69 TEST 6.3.8 - CONNECTIONS – OPEN STP TARGET........................................................... 70 TEST 6.3.9 - CONNECTIONS – OPEN REJECT (STP RESOURCES BUSY) ..................... 71 TEST 6.3.10 - CONNECTIONS – SATA_HOLD .................................................................... 72 TEST 6.3.11 - CONNECTIONS – SATA_RIP ......................................................................... 73 TEST 6.3.12 - BREAK – OPENTIMEOUT TIMER STP TARGET........................................ 74 TEST 6.3.13 - BREAK – CONNECTION REQUEST NOT TRANSMITTED....................... 75 TEST 6.3.14 - BREAK – CONNECTION REQUEST TRANSMITTED................................ 76 TEST 6.3.15 - AIP –TRANSMITTED ...................................................................................... 77 TEST 6.3.16 - AIP –OPEN RECEIVED HIGHER PRIORITY................................................ 78 TEST 6.3.17 - AIP –OPEN RECEIVED LOWER PRIORITY ................................................ 79 TEST 6.3.18 - AWT TIMER –ARBITRATION WAIT TIME .................................................. 80 TEST 6.3.19 - AWT TIMER – RESET TO ZERO.................................................................... 81



TEST 6.3.20 - AWT TIMER – ARBITRATION FAIRNESS ................................................... 82 TEST 6.3.21 - OPEN_REJECT – PATHWAY BLOCKED....................................................... 83 TEST 6.3.22 - SMP_REQUEST – PROPER RESPONSE FORMAT ...................................... 84 TEST 6.3.23 - SMP_REQUEST – CLOSE............................................................................... 85 TEST 6.3.25 - CLOSING SSP CONNECTIONS – CLOSE (CLEAR AFFILIATION)............ 87 TEST 6.3.26 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 0) .......................... 88 TEST 6.3.27 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 1) .......................... 89 TEST 6.3.28 - LINK RESET – HARD_RESET RECIVED AFTER IDENTIFY..................... 90 TEST 6.3.29 - SSP_FRAMES – INTERLOCKED FRAME / NAK ......................................... 91



MODIFICATION RECORD [1]September 7, 2004 (Version 0.1) DRAFT RELEASE

David Woolf: Initial draft release [2]April 14, 2005 (Version 0.12) DRAFT RELEASE

David Woolf: added STP Operations tests [3]July 11, 2005 (Version 0.13) DRAFT RELEASE

David Woolf: minor edits [4]August 18, 2005 (Version 0.14) DRAFT RELEASE Leon Cyril: minor edits [5]September 22, 2005 (Version 1.0) DRAFT RELEASE Leon Cyril: added discussion for all tests. [6]June 5, 2006 (Version 1.1) FINAL RELEASE David Woolf: Modified tests 7.3.4 and 7.3.5. [7]July 10, 2006 (Version 1.11FINAL RELEASE Michael Davidson: Added Tests 7.3.25 – 7.3.29, Removed RCC References [8]October 9, 2007 (Version 1.2) FINAL RELEASE Michael Davidson: Updated all references [9]July 26, 2011 (Version 1.3) FINAL RELEASE Joshua Beaudet: Updated all references

Serial Attached SCSI Consortium 5 Clause 7 SAS Link Layer Test Suite v1.3

The University of New Hampshire InterOperability Laboratory ACKNOWLEDGMENTS

The University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite. Kurtis Kofler UNH InterOperability Laboratory (UNH-IOL) David Woolf UNH InterOperability Laboratory (UNH-IOL) Leon Cyril UNH InterOperability Laboratory (UNH-IOL) Michael Davidson UNH InterOperability Laboratory (UNH-IOL)



INTRODUCTION The University of New Hampshire’s InterOperability Laboratory (IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. This particular suite of tests has been developed in junction with CATC to help implementers evaluate the functionality of their Serial Attached SCSI (SAS) products. Specifically this Test Suite is directed at verifying the Link layer of SAS Targets, Initiators, and Expanders. These tests are designed to determine if a SAS product conforms to specifications defined in ISO/IEC 14776-150, Serial Attached SCSI (SAS) standard T10/1562-D, Revision 5 (hereafter referred to as the “SAS SPL”). Successful completion of all tests contained in this suite does not guarantee that the tested device will successfully operate with other SAS products. However, when combined with satisfactory operation in the IOL’s interoperability test bed, these tests provide a reasonable level of confidence that the Device Under Test (DUT) will function properly in many SAS environments. The tests contained in this document are organized in order to simplify the identification of information related to a test, and to facilitate in the actual testing process. Tests are separated into groups, primarily in order to reduce setup time in the lab environment, however the different groups typically also tend to focus on specific aspects of device functionality. A three-number, dot-notated naming system is used to catalog the tests, where the first number always indicates the specific clause of the reference standard on which the test suite is based. The second and third numbers indicate the test’s group number and test number within that group, respectively. This format allows for the addition of future tests in the appropriate groups without requiring the renumbering of the subsequent tests. 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. Last Modification This specifies the date of the last modification to this test. 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 (next). 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. 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. 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.



REFERENCES The following document is referenced in this text:

[1] T10/Project 1601-DT/Rev 8 – Serial Attached SCSI 1.1 – (SAS – 1.1)



GROUP 1: LINK LAYER TESTS FOR TARGETS Overview:

This group of tests verifies the Link Layer specifications of the SAS physical layer defined in Clause 6 of the SAS SPL, for Targets.



Test 6.1.1 - LINK RESET – REPEAT PHY SEQUENCE IF NO IDENTIFY RECEIVED Purpose: To determine that the DUT will repeat the phy reset sequence if an Identify frame is not received within 1 ms of completing a phy reset sequence. References:

[1] 6.10 SAS SPL [2] 6.8.2 SAS SPL [3] 4.4.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 25, 2011 Discussion: After the phy reset sequence has been completed indicating the physical link is using SAS rather than SATA, each phy transmits either: a) an IDENTIFY address frame [2]; or b) a HARD_RESET. Each phy receives an IDENTIFY address frame or a HARD_RESET from the phy to which it is attached. The combination of a phy reset sequence, an optional hard reset sequence, and an identification sequence is called a link reset sequence [3]. If a device does not receive a valid IDENTIFY address frame within 1 ms of phy reset sequence completion, it shall restart the phy reset sequence. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:

1. The Testing Station is instructed to transmit COMINT to start a Phy Reset sequence with the DUT. 2. The Testing Station is instructed to complete a Phy Reset sequence with the DUT. 3. Once the phy reset sequence between the DUT and the Testing Station are complete, the Testing

Station is instructed to transmit valid SAS primitives or SAS Idle. The Testing Station is instructed to not transmit an Identify Address Frame.

Observable Results: Verify that 1 ms after the DUT completed a phy Reset Sequence with the DUT, the DUT initiated another phy reset sequence by transmitting COMINIT. Possible Problems: None.



Test 6.1.2 - LINK RESET – IGNORE ADDITIONAL IDENTIFY RECEIVED Purpose: To determine that the DUT will ignore an Identify frame received after a valid Identify has already been received. References:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 25, 2011 Discussion: After the phy reset sequence has been completed indicating the physical link is using SAS rather than SATA, each phy transmits either: a) an IDENTIFY address frame [2]; or b) a HARD_RESET. Each phy receives an IDENTIFY address frame or a HARD_RESET from the phy to which it is attached. The combination of a phy reset sequence, an optional hard reset sequence, and an identification sequence is called a link reset sequence [3]. If a device receives an additional IDENTIFY address frame after receiving the first one, without an intervening phy reset sequence, it shall ignore the additional IDENTIFY address frame. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:

1. The Testing Station is instructed to transmit COMINT to start a phy Reset sequence with the DUT. 2. The Testing Station is instructed to complete a phy Reset sequence with the DUT. 3. Once the phy reset sequence between the DUT and the Testing Station are complete, the Testing

Station is instructed to transmit valid SAS primitives or SAS Idle. The Testing Station is instructed to transmit 2 valid Identify Address Frames each with a different SAS address.

Observable Results: Verify that the DUT ignores the second received Identify Address Frame and does not transmit COMINIT. Also, verify that the DUT does not attempt to open a connection to the address in the second Identify Address frame. Possible Problems: None



Test 6.1.3 - LINK RESET – HARD_RESET RECEIVED Purpose: To determine that the DUT properly handles a received HARD_RESET. References:

[1] 6.2.5.3 SAS SPL [2] 6.10.1 SAS SPL [3] 4.4 SAS SPL [4] 4.4.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 25, 2011 Discussion: HARD_RESET is used to force a phy to generate a hard reset to its port. This primitive is only valid after the phy reset sequence without an intervening identification sequence [3] and shall be ignored at other times. If a phy receives a HARD_RESET, it shall be considered a reset event and cause a hard reset [4] of the port containing that phy. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


Station is instructed to transmit 6 consecutive HARD_RESET primitives. This must occur before the Identify sequence is complete.

Observable Results: Verify that the DUT transmits COMINIT upon receiving the HARD_RESET primitives from the Testing Station. Possible Problems: None



Test 6.1.4 - CONNECTIONS – OPEN_ACCEPT Purpose: To determine that the DUT properly transmits RRDY after receiving OPEN_ACCEPT. References:

[1] 6.13.2.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 25, 2011 Discussion: The OPEN address frame is used to request that a connection be opened. AIP, OPEN_ACCEPT and OPEN_REJECT are the responses to an OPEN address frame. An OPEN_ACCEPT indicates that the connection request was accepted. This is sent by the destination phy. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a target the Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.

2. The Testing Station is instructed to transmit an Open Address frame to the DUT. Wait for the DUT to transmit OPEN_ACCEPT and RRDY.

Observable Results: Verify that the DUT transmitted RRDY no more than 1 ms after transmitted OPEN_ACCEPT. Possible Problems: None



Test 6.1.5 - CONNECTIONS – 2 SOAF RECEIVED Purpose: To determine that the DUT properly handles received 2 SOAF primitives. References:

[1] 6.8.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 25, 2011 Discussion: A complete OPEN ADDRESS frame will start with an SOAF primitive and end with an EOAF primitive. A SAS device must be capable of detecting an OPEN ADDRESS frame in a stream of SAS primitives. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to transmit the following to the DUT a. SOAF primitive b. the first 4 dwords of an OpenAddress frame c. complete Open Address frame starting with SOAF and using the SAS address of the DUT.

3. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_ACCEPT. Possible Problems: None



Test 6.1.6 - CONNECTIONS - OPEN_REJECT CONNECTION RATE NOT SUPPORTED Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8.1 SAS SPL [2] 6.8.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (CONNECTION RATE NOT SUPPORTED) occurs when the requested connection rate is not supported on some physical link on the pathway between the source phy and destination phy. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to transmit an OpenAddress frame to the DUT with an invalid connection rate.

3. Wait for the DUT to transmit OPEN_REJECT (Connection rate not supported).

Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Connection rate not supported). Possible Problems: None



Test 6.1.7 - CONNECTIONS - OPEN_REJECT PROTOCOL NOT SUPPORTED Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (PROTOCOL NOT SUPPORTED) occurs when the device with destination SAS address exists but the destination device does not support the requested initiator/target role, protocol, initiator connection tag, or features. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to transmit an OpenAddress frame to the DUT with an invalid initiator or target role.

3. Wait for the DUT to transmit OPEN_REJECT (Protocol not supported). Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Protocol not supported). Possible Problems: None



Test 6.1.8 - CONNECTIONS - OPEN_REJECT WRONG DESTINATION Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (WRONG DESTINATION) occurs when the destination SAS address does not match the SAS address of the SAS port to which the connection request was delivered. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to transmit an OpenAddress frame to the DUT with an incorrect destination SAS Address.

3. Wait for the DUT to transmit OPEN_REJECT (Wrong Destination). Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Wrong Destination). Possible Problems: None



Test 6.1.9 - CONNECTIONS - OPEN_REJECT RETRY Purpose: To determine that the DUT handles extra connection requests properly. References:

[1] 6.8.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (RETRY) occurs when the device with destination SAS address exists but is not able to accept connections. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to continuously transmit OpenAddress frames to the DUT with a correct destination SAS Address.

3. Wait for the DUT to transmit OPEN_REJECT (Retry). Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Retry). This item may not be testable for some devices. Possible Problems: None



Test 6.1.10 - SSP_FRAMES – INTERLOCKED FRAME Purpose: To determine that the DUT handles interlocked frames properly. References:

[1] 6.17.3 SAS SPL [2] 6.16.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: Before transmitting an interlocked frame, an SSP phy shall wait for all SSP frames to be acknowledged withACK or NAK, even if credit is available. After transmitting an interlocked frame, an SSP phy shall not transmit another SSP frame until it has been acknowledged with ACK or NAK, even if credit is available. Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to targets.

Test Procedure:


2. The Testing Station is instructed to open a SSP connection to the DUT and transmit a SCSI_INQUIRY command.

3. Wait for the DUT to transmit ACK followed by SCSI Response. Observable Results: Verify that upon receiving the INQUIRY command, the DUT transmitted ACK before transmitting any other frame to the Testing Station. Possible Problems: None



Test 6.1.11 - SSP_FRAMES - NO ACK FOR INTERLOCKED FRAME Purpose: To determine that the DUT responds properly when no ACK or NAK is received after transmitting an interlocked frame. References:

[1] 6.17.3 SAS SPL [2] 6.16.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: Before transmitting an interlocked frame, an SSP phy shall wait for all SSP frames to be acknowledged with ACK or NAK, even if credit is available. After transmitting an interlocked frame, an SSP phy shall not transmit another SSP frame until it has been acknowledged with ACK or NAK, even if credit is available. Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to targets.

Test Procedure:


2. The Testing Station is instructed to open a SSP connection to the DUT and transmit a SCSI_INQUIRY command.

3. Wait for the DUT to transmit ACK followed by SCSI Response. 4. The Testing Station is instructed to not transmit ACK or NAK to the SCSI Response frame. 5. The Testing Station is instructed to transmit a second SCSI_INQUIRY command with a different TAG

than the first SCSI INQUIRY command. Observable Results: Verify that the DUT aborts the first INQUIRY command with DONE (ACK/NAK TIMEOUT) after the ACK/NAK timeout of 1 ms. Possible Problems: None



Test 6.1.12 - SSP_FRAMES – MULTIPLE ACKS Purpose: To determine that the DUT properly transmits ACK within 1 ms of receiving a frame requiring an ACK response. References:

[1] 6.17.3 SAS SPL [2] 6.16.5 SAS SPL [3] 6.17.8.11 SAS SPL

Resource Requirements: SAS Protocol Analyzer, SAS Initiator, SAS Target, Software capable of generating SCSI traffic from the SAS Initiator. In order to minimize physical layer problems, the Initiator, Target, and Analyzer should be connected with near-ideal channels. Last Modification: July 26, 2011 Discussion: Receiving SSP phys shall acknowledge SSP frames within 1 ms if not discarded as described in [3] with either a positive acknowledgement (ACK) or a negative acknowledgement (NAK). ACK means the SSP frame was received into a frame buffer without errors. NAK (CRC ERROR) means the SSP frame was received with a CRC error, an invalid dword, or an ERROR primitive. Test Setup: The SAS Initiator and Target are connected through the SAS Analyzer.

Test Procedure:

1. Using the generation software, cause the SAS Initiator to begin a series of 1000 64 kB READ operations on the SAS Target. Capture this on the SAS Analyzer.

Observable Results: If the DUT is an initiator, search the Analyzer capture of the target transmissions for the DONE (ACK/NAK TIMEOUT) primitive. If the DUT is a target, search the Analyzer capture of the initiator transmissions for the DONE (ACK/NAK TIMEOUT) primitive. If any of these primitives are found, it indicates that the DUT did not transmit ACK within the 1 ms necessary after receiving frame requiring ACK or NAK. Possible Problems: None



Test 6.1.13 - SSP FRAMES - RRDY Purpose: To determine that the DUT properly grants credit to transit frames using RRDY. References:

[1] 6.17.8.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: An SSP phy uses RRDY to grant credit for permission for the other SSP phy in the connection to transmit frames. Each RRDY increments credit by one frame. Frame transmission decrements credit by one frame. Credit of zero frames is established at the beginning of each connection. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT. 3. Wait for the DUT to transmit OPEN_ACCEPT and RRDY.

Observable Results: Verify that the DUT transmitted RRDY when an SSP connection was opened. Possible Problems: None



Test 6.1.14 - CLOSING SSP CONNECTIONS – DONE (NORMAL) Purpose: To determine that the DUT properly responds when DONE is received. References:

[1] 6.17.8.8 SAS SPL [2] 6.2.7.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: DONE shall be exchanged prior to closing an SSP connection [2]. There are several versions of the DONE primitive indicating additional information about why the SSP connection is being closed: DONE (NORMAL) specifies normal completion; the transmitter has no more SSP frames to transmit. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the Testing Station. 3. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. 4. The Testing Station is instructed to transmit DONE (NORMAL).

Observable Results: Verify that the DUT transmitted DONE (NORMAL) within 1 ms of receiving DONE (NORMAL) from the Testing Station. Possible Problems: None



Test 6.1.15 - CLOSING SSP CONNECTIONS – DONE (ACK/NAK TIMEOUT) Purpose: To determine that the DUT properly responds when ACK or NAK has not been received for a transmitted frame. References:

[1] 6.17.8.7 SAS SPL [2] 6.2.7.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: DONE shall be exchanged prior to closing an SSP connection [2]. There are several versions of the DONE primitive indicating additional information about why the SSP connection is being closed: DONE (ACK/NAK TIMEOUT) specifies that the transmitter transmitted an SSP frame but did not receive the corresponding ACK or NAK within 1 ms. As a result, the ACK/NAK count is not balanced and the transmitter is going to transmit a BREAK in 1 ms unless the recipient replies with DONE and the connection is closed. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the Testing Station. 3. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. The Testing Station is instructed to

transmit a SCSI INQUIRY command to the DUT, then close the connection. 4. Wait for the DUT to open an SSP Connection to the Testing Station. Allow the DUT to transmit a

SCSI Response. The Testing Station is instructed to not transmit ACK or NAK. Observable Results: Verify that the DUT transmitted DONE (ACK/NAK TIMEOUT) within 1 ms of transmitting the Command or Response frame. Possible Problems: None



Test 6.1.16 - CLOSING SSP CONNECTIONS – DONE (CREDIT TIMEOUT) Purpose: To determine that the DUT properly responds when RRDY has not been received for an impending transaction. References:

[1] 6.17.8 SAS SPL [2] 6.2.7.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: DONE shall be exchanged prior to closing an SSP connection [2]. There are several versions of the DONE primitive indicating additional information about why the SSP connection is being closed: DONE (CREDIT TIMEOUT) specifies that the transmitter still has SSP frames to transmit but did not receive an RRDY granting frame credit within 1 ms, or the transmitter has received a CREDIT_BLOCKED and has consumed all RRDYs received. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT. 3. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. The Testing Station is instructed to

transmit a SCSI INQUIRY command to the DUT, then close the connection. 4. Wait for the DUT to open an SSP connection to the Testing Station. The Testing Station is instructed

to not transmit RRDY to grant credit for the DUT to transmit a SCSI Response to the Testing Station. Observable Results: Verify that the DUT transmitted DONE (CREDIT TIMEOUT) within 1 ms of opening the SSP connection. Possible Problems: None



Test 6.1.17 - CLOSING SSP CONNECTIONS – CLOSE (NORMAL) Purpose: To determine that the DUT properly responds when CLOSE (NORMAL) is received. References:

[1] 6.13.7 SAS SPL [2] 6.17.8.1 SAS SPL [3] 6.18.6 SAS SPL [4] 6.19.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: CLOSE is used to close a connection of any protocol. See [2] for details on closing SSP connections, [3] for details on closing STP connections, and [4] for details on closing SMP connections. After transmitting CLOSE, the source phy shall initialize a Close Timeout timer to 1 ms and start the Close Timeout timer. Once an SSP phy has both transmitted and received DONE, it shall close the connection by transmitting CLOSE (NORMAL). Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT. Wait for the DUT to transmit OPEN_ACCEPT. The Testing Station is instructed to transmit a CLOSE (NORMAL) primitive to the DUT.

Observable Results: Verify that the DUT transmitted CLOSE (NORMAL) within 1 ms of receiving CLOSE (NORMAL) from the Testing Station. Possible Problems: None



Test 6.1.18 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY TESTING STATION Purpose: To determine that the DUT properly responds when BREAK is received. References:

[1] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: BREAK may be used to abort a connection request. The source phy shall transmit a BREAK after the Open Timeout timer expires or if it chooses to abort its request for any other reason. After transmitting BREAK, the source phy shall initialize a Break Timeout timer to 1 ms and start the Break Timeout timer. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to transmit an OpenAddress frame to the DUT, followed by BREAK. Observable Results: Verify that the DUT transmitted BREAK or BREAK_REPLY within 1 ms of receiving BREAK from the Testing Station. Possible Problems: None



Test 6.1.19 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY DUT Purpose: To determine that the DUT properly sources BREAK when required. References:

[1] 6.13.7 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: In addition to aborting a connection request, BREAK may also be used to break a connection, in cases where CLOSE is not available. After transmitting BREAK, the originating phy shall ignore all incoming dwords except for BREAKs. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:



transmit a SCSI INQUIRY command to the DUT, then close the connection. 4. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit a SCSI

Response to the Testing Station. 5. When the DUT transmits CLOSE (NORMAL) to close the connection, the Testing Station is instructed

to not transmit CLOSE (NORMAL) in response. Observable Results: Verify that the DUT transmitted BREAK within 1 ms of transmitting CLOSE (NORMAL) to the Testing Station. Possible problems: None



Test 6.1.20 - CONNECTIONS THROUGH EXPANDERS – OPEN SSP TARGET Purpose: To determine that the DUT, can properly open a connection through an expander to transmit data or status. References:

[1] 6.13.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: A connection is opened between a SAS initiator port and a SAS target port before communication begins. A connection is established between one SAS initiator phy in the SAS initiator port and one SAS target phy in the SAS target port. SSP initiator ports open SSP connections to transmit SCSI commands, task management functions, or transfer data. SSP target ports open SSP connections to transfer data or transmit status. SMP initiator ports open SMP connections to transmit SMP requests and receive SMP responses. STP initiator ports and STP target ports open STP connections to transmit SATA frames. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a target the Testing Station is instructed to transmit an Identify Address frame indicating that it is an Edge Expander.

2. The Testing Station is instructed to open an SSP connection to the DUT from another address, imitating a SAS Initiator.

3. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. The Testing Station is instructed to transmit a SCSI INQUIRY command to the DUT, then close the connection.

4. Wait for the DUT to open an SSP connection to the Testing Station to the same address that sourced the SCSI INQUIRY command.

5. Before transmitting OPEN_ACCEPT the Testing Station is instructed to transmit AIP(NORMAL) followed by AIP(WAITING ON DEVICE)

6. Allow the DUT to transmit a SCSI Data frame to the Testing Station. 7. When the DUT transmits CLOSE (NORMAL) to close the connection, the Testing Station is instructed

to transmit CLOSE (NORMAL) in response. 8. Wait for the DUT to open an SSP connection to the Testing Station to the same address that sourced

the SCSI INQUIRY command. Allow the DUT to transmit a SCSI Response frame to the Testing Station.

9. When the DUT transmits CLOSE (NORMAL) to close the connection, the Testing Station is instructed to transmit CLOSE (NORMAL) in response.

Observable Results: Verify that the DUT successfully transmitted both SCSI Response and Data frames. Possible Problems: None



Test 6.1.21 - BREAK – OPENTIMEOUT TIMER SSP TARGET Purpose: To determine that the DUT, an SSP target transmits BREAK after the OpenTimeout Timer expires. References:

[1] 6.13.2.1 SAS SPL [2] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: To make a connection request, the source port shall transmit an OPEN address frame through an available phy. The source phy shall transmit idle dwords after the OPEN address frame until it receives a response or aborts the connection request with BREAK. After transmitting an OPEN address frame, the source phy shall initialize and start a 1 ms Open Timeout timer. If the Open Timeout timer expires before a connection response is received, the source phy may assume the destination port does not exist and shall transmit BREAK to abort the connection request [2]. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a target the Testing Station is instructed to transmit an Identify Address frame indicating that it is an Edge Expander.

2. The Testing Station is instructed to open an SSP connection to the DUT from another address, imitating a SAS Initiator.

3. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. The Testing Station is instructed to transmit a SCSI INQUIRY command to the DUT, then close the connection.

4. Wait for the DUT to open an SSP connection to the Testing Station to the same address that sourced the SCSI INQUIRY command.

5. The Testing Station is instructed to wait for the DUT to transmit an OpenAddress frame for an SSP connection. The Testing Station is instructed to not respond to the OpenAddress frame with OPEN_ACCEPT or OPEN_REJECT.

Observable Results: Verify that 1 ms after transmitting the OpenAddress frame, the DUT transmitted BREAK. Possible Problems: None



Test 6.1.22 - CLOSING SSP CONNECTIONS – CLOSE (CLEAR AFFILIATION) Purpose – To determine that the DUT properly responds when CLOSE (CLEAR AFFILIATION) is received. Reference:

[1] 6.2.6.5 SAS SPL [2] 6.13.6 SAS SPL [3] 6.17.8 SAS SPL [4] 6.18.7 SAS SPL [5] 6.19.5 SAS SPL [6] 6.18.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: CLOSE is used to close a connection of any protocol. See [3] for details on closing SSP connections, [4] for details on closing STP connections, and [5] for details on closing SMP connections. After transmitting CLOSE (CLEAR AFFILIATION), the source phy shall initialize a Close Timeout timer to 1 ms and start the Close Timeout timer. Once an SSP phy has both transmitted and received DONE, it shall close the connection by transmitting CLOSE (NORMAL). CLOSE (CLEAR AFFILIATION) closes an open STP connection and clears the affiliation [1][6]. CLOSE (CLEAR AFFILIATION) is processed the same as CLOSE (NORMAL) if: a) the connection is not an STP connection;

b) the connection is an STP connection, but affiliations are not implemented by the STP target port; or c) the connection is an STP connection, but an affiliation is not present.

Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to targets. Test Procedure:


4. The Testing Station is instructed to open an SSP connection to the DUT. Wait for the DUT to transmit OPEN_ACCEPT. The Testing Station is instructed to transmit a CLOSE (CLEAR AFFILIATION) primitive to the DUT.

Observable Results: Verify that the DUT transmitted CLOSE (NORMAL) within 1 ms of receiving CLOSE (CLEAR AFFILIATION) from the Testing Station. Possible Problems: None



Test 6.1.23 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 0) Purpose – To determine that the DUT properly responds when CLOSE (RESERVED 0) is received. Reference:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: CLOSE is used to close a connection of any protocol. See [3] for details on closing SSP connections, [4] for details on closing STP connections, and [5] for details on closing SMP connections. After transmitting CLOSE (RESERVED 0), the source phy shall initialize a Close Timeout timer to 1 ms and start the Close Timeout timer. Once an SSP phy has both transmitted and received DONE, it shall close the connection by transmitting CLOSE (NORMAL). CLOSE (RESERVED 0) closes an open STP connection and clears the affiliation [1][6]. CLOSE (RESERVED 0) is processed the same as CLOSE (NORMAL) if: a) the connection is not an STP connection;




2. The Testing Station is instructed to open an SSP connection to the DUT. Wait for the DUT to transmit OPEN_ACCEPT. The Testing Station is instructed to transmit a CLOSE (RESERVED 0) primitive to the DUT.

Observable Results: Verify that the DUT transmitted CLOSE (NORMAL) within 1 ms of receiving CLOSE (RESERVED 0) from the Testing Station. Possible Problems: None













Test 6.1.25 - LINK RESET – HARD_RESET RECIVED AFTER IDENTIFY Purpose: To determine that the DUT properly handles a received HARD_RESET. References:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: HARD_RESET is used to force a phy to generate a hard reset to its port. This primitive is only valid after the phy reset sequence without an intervening identification sequence [3] and shall be ignored at other times. If a phy receives a HARD_RESET, it shall be considered a reset event and cause a hard reset [4] of the port containing that phy. Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to targets. Test Procedure:


Station is instructed to transmit 6 consecutive HARD_RESET primitives. This must occur after the Identify sequence is complete.

Observable Results: Verify that the DUT does not transmit COMINIT upon receiving the HARD_RESET primitives from the Testing Station. Possible Problems: None



Test 6.1.26 - SSP_FRAMES – INTERLOCKED FRAME / NAK Purpose: To determine that the DUT handles interlocked frames with CRC errors properly. References:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: Before transmitting an interlocked frame, an SSP phy shall wait for all SSP frames to be acknowledged with ACK or NAK, even if credit is available. After transmitting an interlocked frame, an SSP phy shall not transmit another SSP frame until it has been acknowledged with ACK or NAK, even if credit is available. A receiving SSP phy shall respond to a SSP frame with NAK (CRC ERROR) if the SSP frame was received with a bad CRC. Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to targets. Test Procedure:


2. The Testing Station is instructed to open a SSP connection to the DUT and transmit a SCSI_INQUIRY command with an invalid CRC.

3. Wait for the DUT to transmit NAK (CRC ERROR). Observable Results: Verify that upon receiving the INQUIRY command with an invalid CRC, the DUT transmitted NAK (CRC ERROR) before transmitting any other frame to the Testing Station. Possible Problems: None



GROUP 2: LINK LAYER TESTS FOR INITIATORS

Overview:

This group of tests verifies the Link Layer specifications of the SAS physical layer defined in Clause 6 of the SAS SPL, for Initiators.



Test 6.2.1 - LINK RESET – REPEAT PHY SEQUENCE IF NO IDENTIFY RECEIVED Purpose: To determine that the DUT will repeat the phy reset sequence if an Identify frame is not received within 1 ms of completing a phy reset sequence. References:

[1] 6.10.1 SAS SPL [2] 6.8.2 SAS SPL [3] 4.4.1 SAS SPL




Observable Results: Verify that 1 ms after the DUT completed a phy Reset Sequence with the Testing Station, the DUT initiated another phy reset sequence by transmitting COMINIT. Possible Problems: None



Test 6.2.2 - LINK RESET – IGNORE ADDITIONAL IDENTIFY RECEIVED Purpose: To determine that the DUT will ignore an Identify frame received after a valid Identify has already been received. References:





Observable Results: Verify that the DUT ignores the second received Identify Address Frame and does not transmit COMINIT. Also, verify that the DUT does not attempt to open a connection to the address in the second Identify Address frame. Possible Problems: None








Observable Results: Verify that the DUT transmits COMINIT upon receiving the HARD_RESET primitives from the Testing Station. Possible Problems: None



Test 6.2.4 - LINK RESET – SMP INITIATOR TO PERFORM DISCOVER Purpose: To determine that the DUT, which is an SMP Initiator, properly performs the discovery process. References:

[1] 4.6.7.4 SAS SPL [2] 8.4.3.4 SAS SPL [3] 8.4.3.10 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: Management application clients direct an SMP initiator port to request SMP functions from an SMP target port. If an expander device is attached, the management application client shall use the SMP REPORT GENERAL function [3] to determine how many phys are in the expander device and then use the SMP DISCOVER function [4] to determine what is attached to each expander phy (e.g., the device type, SAS address, and supported protocol(s)). Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


Station is instructed to transmit an Identify Address frame indicating that it is an Edge Expander. 4. The DUT is expected to transmit a SMP Request REPORT GENERAL, the Testing Station is

instructed to respond with SMP Response REPORT GENERAL indicating a phy Count of 1. The DUT is expected to transmit an SMP Request DISCOVER to the Testing Station with a phy ID of 0x00.

5. The Testing Station is instructed to transmit an SMP Request DISCOVER indicating the presence of an SSP Target.

Observable Results: Verify that the DUT transmits both an SMP Request REPORT GENERAL and an SMP Request DISCOVER to the Testing Station.

Possible Problems: None



Test 6.2.5 - LINK RESET – EDGE EXPANDER TRANSMITS OPEN_REJECT Purpose: To determine that the DUT, properly handles receiving OPEN_REJECT from an Edge Expander. References:

[1] 6.10 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: After completing the identification sequence on a phy and completing internal initialization, the ECM within an edge expander device shall be capable of routing connection requests through that phy. The expander device may return OPEN_REJECT (NO DESTINATION) until it is ready for connection requests. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


Station is instructed to transmit an Identify Address frame indicating that it is an Edge Expander. 4. The DUT is expected to transmit a SMP Request REPORT GENERAL, the Testing Station is

instructed to respond with SMP Response REPORT GENERAL indicating a phy Count of 1. The DUT is expected to transmit an SMP Request DISCOVER to the Testing Station with a phy ID of 0x00.

5. The Testing Station is instructed to transmit an SMP Request DISCOVER indicating the presence of an SSP Target.

Observable Results: Verify that the DUT retries the OPEN Address frame for the connection request. Also, verify that the DUT does not attempt phy Reset upon receiving the OPEN_REJECT primitive. Possible Problems: None




[1] 6.13.2.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: The OPEN address frame is used to request that a connection be opened. AIP, OPEN_ACCEPT and OPEN_REJECT are the responses to an OPEN address frame. An OPEN_ACCEPT indicates that the connection request was accepted. This is sent by the destination phy. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator the Testing Station is instructed to transmit an Identify Address frame indicating that it is a target.

2. Wait for the DUT to transmit an Open Address frame to the Testing Station. The Testing Station is instructed to transmit OPEN_ACCEPT followed by RRDY. Allow the DUT to transmit a frame and close the connection.

3. The Testing Station is instructed to transmit an Open Address frame to the DUT. Wait for the DUT to transmit OPEN_ACCEPT and RRDY.

Observable Results: Verify that the DUT transmitted RRDY no more than 1 ms after the Testing Station transmitted OPEN_ACCEPT. Possible Problems: None



Test 6.2.7 - CONNECTIONS – 2 DIFFERENT SOAF RECEIVED Purpose: To determine that the DUT properly handles received 2 SOAF primitives. References:

[1] 6.8 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: A complete OPEN ADDRESS frame will start with an SOAF primitive and end with an EOAF primitive. A SAS device must be capable of detecting an OPEN ADDRESS frame in a stream of SAS primitives. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to transmit the following to the DUT a. SOAF primitive b. the first 4 dwords of an OpenAddress frame c. complete Open Address frame starting with SOAF.

4. Wait for the DUT to transmit OPEN_ACCEPT and RRDY.

Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_ACCEPT. Possible Problems: None



Test 6.2.8 - CONNECTIONS - OPEN_REJECT CONNECTION RATE NOT SUPPORTED Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8 SAS SPL [2] 6.8.3 SAS SPL [3] Table 149 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (CONNECTION RATE NOT SUPPORTED) occurs when the requested connection rate is not supported on some physical link on the pathway between the source phy and destination phy. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to transmit an OpenAddress frame to the DUT with an invalid connection rate.

4. Wait for the DUT to transmit OPEN_REJECT (Connection rate not supported). Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Connection rate not supported). Possible Problems: None



Test 6.2.9 - CONNECTIONS - OPEN_REJECT PROTOCOL NOT SUPPORTED Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (PROTOCOL NOT SUPPORTED) occurs when the device with destination SAS address exists but the destination device does not support the requested initiator/target role, protocol, initiator connection tag, or features. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to transmit an OpenAddress frame to the DUT with an invalid initiator or target role.

4. Wait for the DUT to transmit OPEN_REJECT (Protocol not supported).

Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Protocol not supported). Possible Problems: None



Test 6.2.10 - CONNECTIONS - OPEN_REJECT WRONG DESTINATION Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (WRONG DESTINATION) occurs when the destination SAS address does not match the SAS address of the SAS port to which the connection request was delivered. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to transmit an OpenAddress frame to the DUT with an incorrect destination SAS Address.

4. Wait for the DUT to transmit OPEN_REJECT (Wrong Destination). Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Wrong Destination). Possible Problems: None



Test 6.2.11 - CONNECTIONS - OPEN_REJECT RETRY Purpose: To determine that the DUT handles extra connection requests properly. References:

[1] 6.8 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (RETRY) occurs when the device with destination SAS address exists but is not able to accept connections. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to continuously transmit OpenAddress frames to the DUT with a correct destination SAS Address.

4. Wait for the DUT to transmit OPEN_REJECT (Retry). Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Retry). This item may not be testable for some devices. Possible Problems: None



Test 6.2.12 - SSP_FRAMES – MULTIPLE ACKs Purpose: To determine that the DUT properly transmits ACK within 1 ms of receiving a frame requiring an ACK response. References:


Resource Requirements: SAS Protocol Analyzer, SAS Initiator, SAS Target, Software capable of generating SCSI traffic from the SAS Initiator. In order to minimize physical layer problems, the Initiator, Target, and Analyzer should be connected with near-ideal channels. Last Modification: July 26, 2011 Discussion: Receiving SSP phys shall acknowledge SSP frames within 1 ms if not discarded as described in [3] with either a positive acknowledgement (ACK) or a negative acknowledgement (NAK). ACK means the SSP frame was received into a frame buffer without errors. NAK (CRC ERROR) means the SSP frame was received with a CRC error, an invalid dword, or an ERROR primitive. Test Setup: The SAS Initiator and Target are connected through the SAS Analyzer.

Test Procedure:

1. Using the generation software, cause the SAS Initiator to begin a series of 1000 64 kB READ operations on the SAS Target. Capture this on the SAS Analyzer.

Observable Results: Search the Analyzer capture of the target transmissions for the DONE (ACK/NAK TIMEOUT) primitive. If any of these primitives are found, it indicates that the DUT did not transmit ACK within the 1 ms necessary after receiving frame requiring ACK or NAK. Possible Problems: None



Test 6.2.13 - SSP FRAMES - RRDY Purpose: To determine that the DUT properly grants credit to transit frames using RRDY. References:

[1] 6.17.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: An SSP phy uses RRDY to grant credit for permission for the other SSP phy in the connection to transmit frames. Each RRDY increments credit by one frame. Frame transmission decrements credit by one frame. Credit of zero frames is established at the beginning of each connection. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


2. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit a SCSI Command to the Testing Station, then close the connection.

3. The Testing Station is instructed to transmit an OpenAddress frames to the DUT with a correct destination SAS Address.

4. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. Observable Results: Verify that the DUT transmitted RRDY when an SSP connection was opened. Possible Problems: None



Test 6.2.14 - COSING SSP CONNECTIONS – DONE (NORMAL) Purpose: To determine that the DUT properly responds when DONE is received. References:

[1] 6.17.8.1 SAS SPL [2] 6.2.7.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: DONE shall be exchanged prior to closing an SSP connection [2]. There are several versions of the DONE primitive indicating additional information about why the SSP connection is being closed: DONE (NORMAL) specifies normal completion; the transmitter has no more SSP frames to transmit. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to transmit an OpenAddress frames to the DUT with a correct destination SAS Address.

4. Wait for the DUT to transmit OPEN_ACCEPT and RRDY. 5. The Testing Station is instructed to transmit DONE (NORMAL).

Observable Results: Verify that the DUT transmitted DONE (NORMAL) within 1 ms of receiving DONE (NORMAL) from the Testing Station. Possible Problems: None



Test 6.2.15 - CLOSING SSP CONNECTIONS – DONE (ACK/NAK TIMEOUT) Purpose: To determine that the DUT properly responds when ACK or NAK has not been received for a transmitted frame. References:

[1] 6.17.8.1 SAS SPL [2] 6.2.7.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: DONE shall be exchanged prior to closing an SSP connection [2]. There are several versions of the DONE primitive indicating additional information about why the SSP connection is being closed: DONE (ACK/NAK TIMEOUT) specifies that the transmitter transmitted an SSP frame but did not receive the corresponding ACK or NAK within 1 ms. As a result, the ACK/NAK count is not balanced and the transmitter is going to transmit a BREAK in 1 ms unless the recipient replies with DONE and the connection is closed. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


2. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit a SCSI Command to the Testing Station. The Testing Station is instructed to not transmit ACK or NAK.

Observable Results: Verify that the DUT transmitted DONE (ACK/NAK TIMEOUT) within 1 ms of transmitting the Command or Response frame. Possible Problems: None



Test 6.2.16 - CLOSING SSP CONNECTIONS – DONE (CREDIT TIMEOUT) Purpose: To determine that the DUT properly responds when RRDY has not been received for an impending transaction. References:

[1] 6.17.8.1 SAS SPL [2] 6.2.7.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: DONE shall be exchanged prior to closing an SSP connection [2]. There are several versions of the DONE primitive indicating additional information about why the SSP connection is being closed: DONE (CREDIT TIMEOUT) specifies that the transmitter still has SSP frames to transmit but did not receive an RRDY granting frame credit within 1ms, or the transmitter has received a CREDIT_BLOCKED and has consumed all RRDYs received. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


2. Wait for the DUT to open an SSP connection to the Testing Station. The Testing Station is instructed to not transmit RRDY to grant credit for the DUT to transmit a SCSI Command to the Testing Station.

Observable Results: Verify that the DUT transmitted DONE (CREDIT TIMEOUT) within 1 ms of opening the SSP connection. Possible Problems: None



Test 6.2.17 - CLOSING SSP CONNECTIONS – CLOSE (NORMAL) Purpose: To determine that the DUT properly responds when CLOSE (NORMAL) is received. References:

[1] 6.17.8.1 SAS SPL [2] 6.13.7 SAS SPL [3] 6.18.6 SAS SPL [4] 6.19.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: CLOSE is used to close a connection of any protocol. See [1] for details on closing SSP connections, [3] for details on closing STP connections and [4] for details on closing SMP connections. After transmitting CLOSE, the source phy shall initialize a Close Timeout timer to 1 ms and start the Close Timeout timer. Once an SSP phy has both transmitted and received DONE, it shall close the connection by transmitting CLOSE (NORMAL). Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to transmit an OpenAddress frame to the DUT. Wait for OPEN_ACCEPT from the DUT, then transmit CLOSE (NORMAL)

Observable Results: Verify that the DUT transmitted CLOSE (NORMAL) within 1 ms of receiving CLOSE (NORMAL) from the Testing Station. Possible Problems: None



Test 6.2.18 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY TESTING STATION Purpose: To determine that the DUT properly responds when BREAK is received. References:

[1] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: BREAK may be used to abort a connection request. The source phy shall transmit a BREAK after the Open Timeout timer expires or if it chooses to abort its request for any other reason. After transmitting BREAK, the source phy shall initialize a Break Timeout timer to 1 ms and start the Break Timeout timer. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:



3. The Testing Station is instructed to transmit an OpenAddress frame to the DUT, followed by BREAK.

Observable Results: Verify that the DUT transmitted BREAK or BREAK_REPLY within 1 ms of receiving BREAK from the Testing Station. Possible Problems: None



Test 6.2.19 - CLOSING SSP CONNECTIONS – BREAK SOURCED BY DUT Purpose: To determine that the DUT properly sources BREAK when required. References:

[1] 6.13.7 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: In addition to aborting a connection request, BREAK may also be used to break a connection, in cases where CLOSE is not available. After transmitting BREAK, the originating phy shall ignore all incoming dwords except for BREAKs. Test Setup: The DUT and the Testing Station are physically connected. Test Procedure:


2. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit a SCSI Command to the Testing Station.

3. When the DUT transmits CLOSE (NORMAL) to close the connection, the Testing Station is instructed to not transmit CLOSE (NORMAL) in response.

Observable Results: Verify that the DUT transmitted BREAK within 1 ms of transmitting CLOSE (NORMAL) to the Testing Station. Possible Problems: None



Test 6.2.20 - CONNECTIONS THROUGH EXPANDER – OPEN SSP INITIATOR Purpose: To determine that the DUT, an SSP Initiator, can properly open a connection through an expander to transmit data or command frames. References:

[1] 6.13.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: A connection is opened between a SAS initiator port and a SAS target port before communication begins. A connection is established between one SAS initiator phy in the SAS initiator port and one SAS target phy in the SAS target port. SSP initiator ports open SSP connections to transmit SCSI commands, task management functions, or transfer data. SMP initiator ports open SMP connections to transmit SMP requests and receive SMP responses. STP initiator ports and STP target ports open STP connections to transmit SATA frames. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator the Testing Station is instructed to transmit an Identify Address frame indicating that it is an Edge Expander.

2. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a REPORT_GENERAL SMP Request. The Testing Station is instructed to respond on the same connection with a REPORT_GENERAL SMP Response indicating that there are 2 attached phys. One of these phys will simulate an attached SSP target. The other phy will represent the phy that the DUT is attached to. When the response is complete close the connection.

3. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a DISCOVER SMP Request. The Testing Station is instructed to respond on the same connection with a DISCOVER SMP Response providing a SAS address of one attached SSP phy. Close the connection.

4. Wait for the DUT to open an SSP connection to the Testing Station to the same address that was provided by the Testing Station in the DISCOVER

5. Before transmitting OPEN_ACCEPT the Testing Station is instructed to transmit AIP(NORMAL) followed by AIP(WAITING ON DEVICE)

6. Allow the DUT to transmit a SCSI Command frame to the Testing Station. 7. When the DUT transmits CLOSE (NORMAL) to close the connection, the Testing Station is

instructed to transmit CLOSE (NORMAL) in response. Observable Results: Verify that the DUT successfully transmitted the SCSI Command frame. Possible Problems: None



Test 6.2.21 - CONNECTIONS THROUGH EXPANDERS – OPEN SMP INITIATOR Purpose: To determine that the DUT, an SMP Initiator, can properly open a connection through an expander to transmit an SMP Request. References:

[1] 6.13.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: A connection is opened between a SAS initiator port and a SAS target port before communication begins. A connection is established between one SAS initiator phy in the SAS initiator port and one SAS target phy in the SAS target port. SSP initiator ports open SSP connections to transmit SCSI commands, task management functions, or transfer data. SMP initiator ports open SMP connections to transmit SMP requests and receive SMP responses. STP initiator ports and STP target ports open STP connections to transmit SATA frames. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator the Testing Station is instructed to transmit an Identify Address frame indicating that it is an Fanout Expander.

2. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a REPORT_GENERAL SMP Request. The Testing Station is instructed to respond on the same connection with a REPORT_GENERAL SMP Response indicating that there is 1 attached phy. Close the connection.

3. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a DISCOVER SMP Request. The Testing Station is instructed to respond on the same connection with a DISCOVER SMP Response providing a SAS address of one attached SMP phy. Close the connection.

4. Wait for the DUT to open an SMP connection to the Testing Station to the same address that was provided by the Testing Station in the DISCOVER

5. Before transmitting OPEN_ACCEPT the DUT should transmit AIP(NORMAL) followed by AIP(WAITING ON DEVICE)

6. Allow the DUT to transmit an SMP Request to the Testing Station. 7. When the DUT transmits CLOSE (NORMAL) to close the connection, the Testing Station is

instructed to transmit CLOSE (NORMAL) in response. Observable Results: Verify that the DUT successfully transmitted the SMP Request frame. Possible Problems: None



Test 6.2.22 - CLOSING SSP CONNECTIONS – CLOSE (CLEAR AFFILIATION) Purpose: To determine that the DUT, an SSP Initiator transmits BREAK after the OpenTimeout Timer expires. References:

[1] 6.13.2.1 SAS SPL [2] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: To make a connection request, the source port shall transmit an OPEN address frame through an available phy. The source phy shall transmit idle dwords after the OPEN address frame until it receives a response or aborts the connection request with BREAK. After transmitting an OPEN address frame, the source phy shall initialize and start a 1 ms Open Timeout timer. If the Open Timeout timer expires before a connection response is received, the source phy may assume the destination port does not exist and shall transmit BREAK to abort the connection request [2]. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator the Testing Station is instructed to transmit an Identify Address frame indicating that it is an Edge Expander.

2. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a REPORT_GENERAL SMP Request. The Testing Station is instructed to respond on the same connection with a REPORT_GENERAL SMP Response indicating that there are 2 attached phys. One of these phys will simulate an attached SSP target. The other phy will represent the phy that the DUT is attached to. When the response is complete close the connection.

3. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a DISCOVER SMP Request. The Testing Station is instructed to respond on the same connection with a DISCOVER SMP Response providing a SAS address of one attached SSP phy. Close the connection.

4. Wait for the DUT to open an SSP connection to the Testing Station to the same address that was provided by the Testing Station in the DISCOVER

5. The Testing Station is instructed to wait for the DUT to transmit an OpenAddress frame for an SSP connection. The Testing Station is instructed to not respond to the OpenAddress frame with OPEN_ACCEPT or OPEN_REJECT.

Observable Results: Verify that 1ms after transmitting the OpenAddress frame, the DUT transmitted BREAK. Possible Problems: None



Test 6.2.23 - CLOSING SSP CONNECTIONS - CLOSE (RESERVED 0) Purpose: To determine that the DUT, an SMP Initiator transmits BREAK after the OpenTimeout Timer expires. References:

[1] 6.13.2.1 SAS SPL [2] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: BREAK may be used to abort a connection request. The source phy shall transmit a BREAK after the Open Timeout timer expires or if it chooses to abort its request for any other reason. After transmitting BREAK, the source phy shall initialize a Break Timeout timer to 1 ms and start the Break Timeout timer. When a phy sourcing a BREAK is attached to an expander device, the BREAK response to the source phy is generated by the expander phy to which the source phy is attached, not the other SAS phy in the connection. If the expander device has transmitted a connection request to the destination, it shall also transmit BREAK to the destination. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator the Testing Station is instructed to transmit an Identify Address frame indicating that it is an Fanout Expander.

2. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a REPORT_GENERAL SMP Request. The Testing Station is instructed to respond on the same connection with a REPORT_GENERAL SMP Response indicating that there is 1 attached phy. Close the connection.

3. Wait for the DUT to open an SMP Connection to the Testing Station. Allow the DUT to transmit a DISCOVER SMP Request. The Testing Station is instructed to respond on the same connection with a DISCOVER SMP Response providing a SAS address of one attached SMP phy. Close the connection.

4. 7Wait for the DUT to open an SMP connection to the Testing Station to the same address that was provided by the Testing Station in the DISCOVER

5. The Testing Station is instructed to wait for the DUT to transmit an OpenAddress frame for an SMP connection. The Testing Station is instructed to not respond to the OpenAddress frame with OPEN_ACCEPT or OPEN_REJECT.

Observable Results: Verify that 1 ms after transmitting the OpenAddress frame, the DUT transmitted BREAK. Possible Problems: None




[1] 6.2.6.5 SAS SPL [2] 6.13.6 SAS SPL [3] 6.17.8.1 SAS SPL [4] 6.18.6 SAS SPL [5] 6.19.5 SAS SPL [6] 6.18.5 SAS SPL









GROUP 3: LINK LAYER TESTS FOR EXPANDERS

Overview:

This group of tests verifies the Link Layer specifications of the SAS physical layer defined in Clause 6 of the SAS SPL, for Expanders.



Test 6.3.1 - LINK RESET – REPEAT PHY SEQUENCE IF NOT IDENTIFY RECEIVED Purpose: To determine that the DUT will repeat the phy reset sequence if an Identify frame is not received within 1 ms of completing a phy reset sequence. References:



1. The Testing Station is instructed to transmit COMINT to start a phy Reset sequence with the DUT.

2. The Testing Station is instructed to complete a phy Reset sequence with the DUT. 3. Once the phy reset sequence between the DUT and the Testing Station are complete, the Testing


Observable Results:

• Verify that 1 ms after the DUT completed a phy Reset Sequence with the DUT, the DUT initiated another phy reset sequence by transmitting COMINIT.




Test 6.3.2 - IGNORE ADDITONAL IDENTIFY RECEIVED Purpose: To determine that the DUT will ignore an Identify frame received after a valid Identify has already been received. References:






Observable Results:

• Verify that the DUT ignores the second received Identify Address Frame and does not transmit COMINIT.

• Verify that the DUT does not attempt to open a connection to the address in the second Identify Address frame.










Observable Results:

• Verify that the DUT transmits COMINIT upon receiving the HARD_RESET primitives from the Testing Station.





[1] 6.19.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: The OPEN address frame is used to request that a connection be opened. AIP, OPEN_ACCEPT and OPEN_REJECT are the responses to an OPEN address frame. An OPEN_ACCEPT indicates that the connection request was accepted. This is sent by the destination phy. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander the Testing Station is instructed to transmit an Identify Address frame indicating that it is an SMP initiator.

2. The Testing Station is instructed to transmit an SMP Open Address frame to the DUT. Wait for the DUT to transmit OPEN_ACCEPT.

Observable Results:

• Verify that the DUT OPEN_ACCEPT within 1 ms of receiving the OPEN address frame. Possible Problems: None



Test 6.3.5 - CONNECTIONS – 2 SOAF RECEIVED Purpose: To determine that the DUT properly handles received 2 SOAF primitives. References:

[1] 6.19 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: A complete OPEN ADDRESS frame will start with an SOAF primitive and end with an EOAF primitive. A SAS device must be capable of detecting an OPEN ADDRESS frame in a stream of SAS primitives. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a expander the Testing Station is instructed to transmit an Identify Address frame indicating that it is an SMP Initiator.

2. The Testing Station is instructed to transmit the following to the DUT a. SOAF primitive b. the first 4 dwords of an SMP OpenAddress frame c. complete SMP Open Address frame starting with SOAF.

3. Wait for the DUT to transmit OPEN_ACCEPT.

Observable Results:

• Verify that the DUT responded to the received, complete Open Address frame with OPEN_ACCEPT. Possible Problems: None



Test 6.3.6 - CONNECTIONS - OPEN_REJECT NO DESTINATION Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8 SAS SPL [2] 8.4.3.12 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. . OPEN_REJECT (NO DESTINATION) occurs when:

• No such destination device; • the expander device determines the connection request would have to be routed to the same expander

port as the expander port through which the connection request arrived (e.g., the destination SAS address equals the source SAS address) and the expander device has not chosen to return OPEN_REJECT (BAD DESTINATION) or

• the SAS address is valid for an STP target port in an STP/SATA bridge, but the initial Register - Device to Host FIS has not been successfully received .

Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to SAS Expanders. Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander the Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.

2. The Testing Station is instructed to transmit an SMP OpenAddress frame to the DUT with an invalid destination address.

3. Wait for the DUT to transmit OPEN_REJECT (No Destination)

Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (No Destination). Possible Problems: None



Test 6.3.7 - CONNECTIONS - OPEN_REJECT BAD DESTINATION Purpose: To determine that the DUT handles errors in OpenAddress frames properly. References:

[1] 6.8 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (BAD DESTINATION) occurs when the destination SAS address does not match the SAS address of the SAS port to which the connection request was delivered. Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to SAS Expanders. Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander the Testing Station is instructed to transmit an Identify Address frame indicating that it is an SMP initiator.

2. The Testing Station is instructed to transmit an SMP OpenAddress frame to the DUT with the destination SAS address equal to the source SAS Address

3. Wait for the DUT to transmit OPEN_REJECT (Bad Destination)

Observable Results: Verify that the DUT responded to the received, complete Open Address frame with OPEN_REJECT (Bad Destination). Possible Problems: None



Test 6.3.8 - CONNECTIONS – OPEN STP TARGET Purpose: To determine that the DUT, an STP Target, can properly open a connection through an expander to transmit frames. References:

[1] 6.13.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: A connection is opened between a SAS initiator port and a SAS target port before communication begins. A connection is established between one SAS initiator phy in the SAS initiator port and one SAS target phy in the SAS target port. For STP connections, connections may be between the STP initiator port and an STP target port in an expander device attached to a SATA device. An STP target port in an expander device opens STP connections on behalf of SATA devices. Test Setup: The DUT and the Testing Station are physically connected. A SATA Target device is attached to the DUT.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence and an Identify sequence with the DUT. The Testing Station is instructed to indicate that it is an Edge Expander in the Identify sequence.

2. The Testing Station is instructed to simulate an SMP Initiator attached to the Edge Expander and open an SMP Connection to the DUT an transmit a REPORT_GENERAL SMP Request. The Testing Station is instructed to transmit a REPORT_GENERAL SMP Response.

3. The Testing Station is instructed to open an SMP Connection to the DUT and transmit a DISCOVER SMP Request to the DUT phy which is attached to the SATA Device Port. The Testing Station is instructed to transmit a DISCOVER SMP Response with this information.

4. The Testing Station is instructed to open an STP Connection to the DUT for the attached SATA Device Port and transmit an IDENTIFY DEVICE command, then close the connection.

5. The Testing Station is instructed to wait for the DUT to transmit an OpenAddress frame for an STP connection. The Testing Station is instructed to respond to the OpenAddress frame with OPEN_ACCEPT.

Observable Results: Verify that the DUT successfully transmitted the response to the IDENTIFY DEVICE command and completed with status OK. Possible Problems: None



Test 6.3.9 - CONNECTIONS – OPEN REJECT (STP RESOURCES BUSY) Purpose: To determine that the DUT, an expander acting as an STP Target properly uses OPEN REJECT (STP RESOURCES BUSY). References:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: OPEN_REJECT specifies that a connection request has been rejected and specifies the reason for the rejection. The result of some OPEN_REJECTs is to abandon (i.e., not retry) the connection request and the result of other OPEN_REJECTs is to retry the connection request. OPEN_REJECT (STP RESOURCES BUSY) occurs when a STP target port with destination SAS address exists but the STP target port has an affiliation with another STP initiator port or all of the available task file registers have been allocated to other STP initiator ports [3]. Process the same as OPEN_REJECT (WRONG DESTINATION) for non-STP connection requests. Test Setup: The DUT and the Testing Station are physically connected. A SATA disk drive is attached to the DUT.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander with an attached SATA device the Testing Station is instructed to transmit an Identify Address frame indicating that it is a SAS Initiator.

2. The Testing Station is instructed to open an SMP Connection to the DUT. The Testing Station is instructed to transmit a REPORT_GENERAL SMP Request to the DUT. The DUT should respond on the same connection with a REPORT_GENERAL SMP Response. Close the connection.

3. The Testing Station is instructed to open an SMP Connection to the DUT. The Testing Station is instructed to transmit a DISCOVER SMP Request to the DUT with the phy ID of the expander phy with the attached SATA device. The DUT should respond on the same connection with a DISCOVER SMP Response. Close the connection.

4. The Testing Station is instructed to transmit an STP OPEN ADDRESS frame to the DUT. The Testing Station is instructed to wait for OPEN_ACCEPT from the DUT.

5. The Testing Station is instructed to transmit a second STP OPEN ADDRESS frame to the DUT, from the same SAS source address.

Observable Results: Verify that the DUT transmits OPEN REJECT (STP RESOURCES BUSY) in response to the second received OPEN ADDRESS frame. If the DUT tracks all commands by the STP initiator ports’ SAS addresses, this item is not applicable. This item is only applicable if the DUT supports affiliations. Possible Problems: None



Test 6.3.10 - CONNECTIONS – SATA_HOLD Purpose: To determine that the DUT, an expander acting as an SATA Host properly uses SATA_HOLD. References:

[1] 6.18.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: Each STP port (i.e., STP initiator port and STP target port) and expander port through which the STP connection is routed shall implement the SATA flow control protocol on each physical link. The flow control primitives are not forwarded through expander devices like other dwords. When an STP port is receiving a frame and its buffer begins to fill up, it shall transmit SATA_HOLD. When an STP port is transmitting a frame and receives SATA_HOLD, it shall transmit no more than 20 data dwords for the frame and respond with SATA_HOLDA. Test Setup: The DUT and the Testing Station are physically connected. A SATA disk drive is attached to the DUT.

Test Procedure:





5. The Testing Station is instructed to begin transmission of a SATA FIS of IDENTFY DEVICE, but interrupt transmission of that FIS with SATA_HOLD primitves.

6. The Testing Station is instructed to wait for the DUT to transmit SATA_HOLDA, then complete transmission of the SATA FIS.

Observable Results: Verify that the DUT retransmits SATA_HOLD and the SATA_HOLDA Possible Problems: None



Test 6.3.11 - CONNECTIONS – SATA_RIP Purpose: To determine that the DUT, an expander acting as an SATA Host properly uses SATA_RIP. References:

[1] 6.18.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: The SATA_RIP primitive allows STP devices to indicate that frame reception is occurring. A device will source SATA_RIP after a device sources SATA_RRDY, indicating it is ready to receive a frame. SATA_RIP is an STP primitive which allows SAS devices to communicate with SATA devices. Test Setup: The DUT and the Testing Station are physically connected. A SATA disk drive is attached to the DUT.

Test Procedure:





5. Wait for the DUT to transmit SATA R_RDY. 6. The Testing Station is instructed to transmit SATA_XRDY, followed by an IDENTIFY DEVICE

command to the DUT. Wait for the attached SATA device to transmit SATA_RIP. Observable Results: Verify that the DUT forwards SATA_RIP from the attached SATA device. Possible Problems: None



Test 6.3.12 - BREAK – OPENTIMEOUT TIMER STP TARGET Purpose: To determine that the DUT, an STP Target transmits BREAK after the OpenTimeout Timer expires. References:

[1] 6.13.2.1 SAS SPL [2] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator, SATA Device Port Last Modification: July 26, 2011 Discussion: To make a connection request, the source port shall transmit an OPEN address frame through an available phy. The source phy shall transmit idle dwords after the OPEN address frame until it receives a response or aborts the connection request with BREAK. After transmitting an OPEN address frame, the source phy shall initialize and start a 1 ms Open Timeout timer. If the Open Timeout timer expires before a connection response is received, the source phy may assume the destination port does not exist and shall transmit BREAK to abort the connection request [2]. Test Setup: The DUT and the Testing Station are physically connected. The DUT is also connected to a SATA Device Port.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence and an Identify sequence with the DUT. The Testing Station is instructed to indicate that it is an Edge Expander in the Identify sequence.

2. The Testing Station is instructed to simulate an SMP Initiator attached to the Edge Expander and open an SMP Connection to the DUT an transmit a REPORT_GENERAL SMP Request. The Testing Station is instructed to transmit a REPORT_GENERAL SMP Response.

3. The Testing Station is instructed to open an SMP Connection to the DUT and transmit a DISCOVER SMP Request to the DUT phy which is attached to the SATA Device Port. The Testing Station is instructed to transmit a DISCOVER SMP Response with this information.

4. The Testing Station is instructed to open an STP Connection to the DUT for the attached SATA Device Port and transmit an IDENTIFY DEVICE command, then close the connection.

5. The Testing Station is instructed to wait for the DUT to transmit an OpenAddress frame for an STP connection. The Testing Station is instructed to not respond to the OpenAddress frame with OPEN_ACCEPT or OPEN_REJECT.

Observable Results: Verify that 1ms after transmitting the OpenAddress frame, the DUT transmitted BREAK. Possible Problems: None



Test 6.3.13 - BREAK – CONNECTION REQUEST NOT TRANSMITTED Purpose: To determine that the DUT, a SAS Expander responds to received BREAK properly. References:

[1] 6.13.2.1 SAS SPL [2] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: When a phy sourcing a BREAK is attached to an expander device, the BREAK response to the source phy is generated by the expander phy to which the source phy is attached, not the other SAS phy in the connection. If the expander device has transmitted a connection request to the destination, it shall also transmit BREAK to the destination. If the expander device has not transmitted a connection request to the destination, it shall not transmit BREAK to the destination. After transmitting BREAK back to the originating phy, the expander device shall ensure that an open response does not occur (i.e., the expander device shall not forward dwords from the destination any more). Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander with an attached target the Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.

2. The Testing Station is instructed to open an SMP Connection to the DUT and transmit a REPORT_GENERAL SMP Request. The DUT should transmit a REPORT_GENERAL SMP Response.

3. The Testing Station is instructed to open an SMP Connection to the DUT and transmit a DISCOVER SMP Request to the DUT phy which is attached to the SAS Target. The DUT should transmit a DISCOVER SMP Response with this information.

4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, followed by a BREAK, within 10 dwords.

Observable Results: Verify that the DUT does not transmit BREAK to the SAS Target unless it has already transmitted the SSP OpenAddress frame to the target. Verify that after transmitting BREAK back to the Testing Station, the DUT does not forward any dwords from the attached SAS Target to the Testing Station, such as an OPEN_ACCEPT frame. Possible Problems: None



Test 6.3.14 - BREAK – CONNECTION REQUEST TRANSMITTED Purpose: To determine that the DUT, a SAS Expander responds to received BREAK properly. References:

[1] 6.13.2.1 SAS SPL [2] 6.13.6 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: When a phy sourcing a BREAK is attached to an expander device, the BREAK response to the source phy is generated by the expander phy to which the source phy is attached, not the other SAS phy in the connection. If the expander device has transmitted a connection request to the destination, it shall also transmit BREAK to the destination. If the expander device has not transmitted a connection request to the destination, it shall not transmit BREAK to the destination. After transmitting BREAK back to the originating phy, the expander device shall ensure that an open response does not occur (i.e., the expander device shall not forward dwords from the destination any more). Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:


2. The Testing Station is instructed to open an SMP Connection to the DUT an transmit a REPORT_GENERAL SMP Request. The DUT should transmit a REPORT_GENERAL SMP Response.


4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT. Once OPEN_ACCEPT is received from the DUT, the Testing Station is instructed to transmit BREAK.

Observable Results: Verify that the DUT transmits BREAK to the SAS Target. Possible Problems: None



Test 6.3.15 - AIP –TRANSMITTED Purpose: To determine that the DUT, a SAS Expander properly transmits AIP References:

[1] 6.13.2.2 SAS SPL [2] 6.18.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: When an expander device is trying to open a connection to the selected destination port, it returns an AIP to the source phy. The source phy shall reinitialize and restart its Open Timeout timer when it receives an AIP. AIP is sent by an expander device while it is internally arbitrating for access to an expander port. Expander devices shall transmit no more than three consecutive AIPs without transmitting an idle dword. Expander devices may transmit three consecutive AIPs to provide better tolerance of errors. Expander devices shall transmit at least one AIP every 128 dwords while transmitting AIP (NORMAL), AIP (WAITING ON PARTIAL), or AIP (WAITING ON CONNECTION). Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:




4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT.

Observable Results: Verify that the DUT transmits AIP to the Testing Station upon receiving the connection request. The AIP must be transmitted within 128 dwords of the Open, and AIP must be sent at least every 128 dwords until the connection is established from the DUT to the attached SAS Target. Possible Problems: None



Test 6.3.16 - AIP –OPEN RECEIVED HIGHER PRIORITY Purpose: To determine that the DUT, a SAS Expander properly handles a received OPEN of higher priority after having transmitted AIP on a different physical link. References:

[1] 6.13.2.2 SAS SPL [2] 6.18.4 SAS SPL [3] 6.18.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: When an expander device is trying to open a connection to the selected destination port, it returns an AIP to the source phy. The source phy shall reinitialize and restart its Open Timeout timer when it receives an AIP. AIP is sent by an expander device while it is internally arbitrating for access to an expander port. Before an expander device transmits AIP, it may have transmitted an OPEN address frame on the same physical link. Arbitration fairness dictates which OPEN address frame wins [1]. After an expander device transmits an AIP, it shall not transmit an OPEN address frame unless it has higher arbitration priority than the incoming connection request. Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:




4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, and transmit a SCSI INQUIRY command. The Testing Station is instructed to close the connection.

5. The Testing Station is instructed to wait for an OpenAddress frame from the attached target. At this point the DUT must be transmitting AIP to the attached target. The Testing Station is instructed to transmit an OpenAddress to the attached target with a high priority, by setting AWT to 8000h.

Observable Results: Verify that the DUT transmits AIP to the attached target upon receiving the OpenAddress from the attached target. Verify that the DUT forwards the OpenAddress from the Testing Station to the attached target after having transmitted AIP to the attached target. Possible Problems: None



Test 6.3.17 - AIP –OPEN RECEIVED LOWER PRIORITY Purpose: To determine that the DUT, a SAS Expander properly handles a received OPEN of higher priority after having transmitted AIP on a different physical link. References:

[1] 6.13.2.2 SAS SPL [2] 6.18.5 SAS SPL [3] 6.18.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: When an expander device is trying to open a connection to the selected destination port, it returns an AIP to the source phy. The source phy shall reinitialize and restart its Open Timeout timer when it receives an AIP. AIP is sent by an expander device while it is internally arbitrating for access to an expander port. Before an expander device transmits AIP, it may have transmitted an OPEN address frame on the same physical link. Arbitration fairness dictates which OPEN address frame wins [3]. After an expander device transmits an AIP, it shall not transmit an OPEN address frame unless it has higher arbitration priority than the incoming connection request. Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:




4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, and transmit a SCSI INQUIRY command. The Testing Station is instructed to close the connection.

5. The Testing Station is instructed to wait for an OpenAddress frame from the attached target. At this point the DUT must be transmitting AIP to the attached target. The Testing Station is instructed to transmit an OpenAddress to the attached target with a low priority, by setting AWT to 0000h.

Observable Results: Verify that the DUT transmits AIP to the attached target upon receiving the OpenAddress from the attached target. Verify that the DUT does not forward the OpenAddress from the Testing Station to the attached target after having transmitted AIP to the attached target. Possible Problems: None



Test 6.3.18 - AWT TIMER –ARBITRATION WAIT TIME Purpose: To determine that the DUT, a SAS Expander, properly sets the AWT in an outgoing OpenAddress frame. References:

[1] 6.18.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: Each SAS port and expander port shall include an Arbitration Wait Time timer which counts the time from the moment when the port makes a connection request until the request is accepted or rejected. The expander port that receives an OPEN address frame shall set the Arbitration Wait Time timer to the value of the incoming ARBITRATION WAIT TIME field and start the Arbitration Wait Time timer as it arbitrates for internal access to the outgoing expander port. When the expander device transmits the OPEN address frame out another expander port, it shall set the outgoing ARBITRATION WAIT TIME field to the current value of the Arbitration Wait Time timer maintained by the incoming expander port. Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:




4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, with an AWT of 5FFFh.

Observable Results: Verify that the DUT transmits an OpenAddress frame for an SSP Connection to the attached SAS Target with an AWT of 5FFFh. Possible Problems: None



Test 6.3.19 - AWT TIMER – RESET TO ZERO Purpose: To determine that the DUT, a SAS Expander, properly sets the AWT in an outgoing OpenAddress frame. References:

[1] 6.18.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: Each SAS port and expander port shall include an Arbitration Wait Time timer which counts the time from the moment when the port makes a connection request until the request is accepted or rejected. A SAS port shall stop the Arbitration Wait Time timer and set it to zero when it receives one of the following connection responses: a) OPEN_ACCEPT; b) OPEN REJECT (PROTOCOL NOT SUPPORTED); c) OPEN_REJECT (STP RESOURCES BUSY); d) OPEN_REJECT (WRONG DESTINATION); or e) OPEN_REJECT (RETRY). Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:




4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, with an AWT of 5FFFh. The Testing Station is instructed to transmit a SCSI INQUIRY command to that attached target then close the connection.

5. Allow the attached target to open SSP connections through the DUT, to transmit Data and Response to the Testing Station.

6. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, with an AWT of 0.

Observable Results: Verify that the DUT transmits an OpenAddress frame for an SSP Connection to the attached SAS Target with an AWT of 0.



Test 6.3.20 - AWT TIMER – ARBITRATION FAIRNESS Purpose: To determine that the DUT, a SAS Expander, properly uses the AWT field in an OpenAddress frame to determine arbitration fairness. References:

[1] 6.18.2 SAS SPL [2] 6.8.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: Each SAS port and expander port shall include an Arbitration Wait Time timer which counts the time from the moment when the port makes a connection request until the request is accepted or rejected. SAS ports should set the Arbitration Wait Time timer to zero when they transmit the first OPEN address frame for the connection request. A SAS initiator port or SAS target port may be unfair by setting the ARBITRATION WAIT TIME field in the OPEN address frame (see 6.8.3) to a higher value than its Arbitration Wait Time timer indicates. However, unfair SAS ports shall not set the ARBITRATION WAIT TIME field to a value greater than or equal to 8000h; this limits the amount of unfairness and helps prevent livelocks. Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:




4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, with an AWT of 0FFFh. Immediately following, the Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, with an AWT of 5FFFh.

Observable Results: Verify that the DUT transmits an OpenAddress frame for an SSP Connection to the attached SAS Target with an AWT of 5FFFh.



Test 6.3.21 - OPEN_REJECT – PATHWAY BLOCKED Purpose: To determine that the DUT, a SAS Expander, properly increments the pathway blocked count. References:

[1] 6.18.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: Pathway recovery provides a means to abort connection requests in order to prevent deadlock using pathway recovery priority comparisons. The ECM shall instruct the arbitrating expander phy to reject the connection request by transmitting OPEN_REJECT (PATHWAY BLOCKED) when: a) the Partial Pathway Timeout timer expires; and b) the pathway recovery priority of the arbitrating expander phy (i.e., the expander phy requesting the connection) is less than or equal to the pathway recovery priority of any of the expander phys within the destination port that are sending phy Status (Blocked Partial Pathway) responses to the ECM. Test Setup: The DUT and the Testing Station are physically connected. The DUT is physically connected to a SAS Target.

Test Procedure:




4. The Testing Station is instructed to transmit an OpenAddress frame for an SSP Connection to the SAS Target attached to the DUT, transmit a SCSI INQUIRY command, then close the connection.

5. The target attached to the DUT is expected to transmit a connection request to the Testing Station though the DUT. The Testing Station is instructed to open an SMP Connection to the DUT and transmit a REPORT_GENERAL SMP Request. The DUT should transmit a REPORT_GENERAL SMP, then close the connection. Response. The SMP OPEN from the Testing Station is instructed to have a higher AWT than the OPEN from the attached target. Repeat this step 5 times.

Observable Results: Verify that the DUT transmits OPEN_REJECT (PATHWAY BLOCKED) to the attached target OPEN request. Verify that the DUT increments the PATHWAY BLOCKED count each time an OPEN request from the target is rejected. Possible Problems: None



Test 6.3.22 - SMP_REQUEST – PROPER RESPONSE FORMAT Purpose: To determine that the DUT, a SAS Expander, properly formats an SMP Response. References:

[1] 6.18.4 SAS SPL [2] 8.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: Inside an SMP connection, the source device transmits a single SMP_REQUEST frame and the destination device responds with a single SMP_RESPONSE frame [2]. By accepting an SMP connection, the destination device indicates it is ready to receive one SMP_REQUEST frame. After the source device transmits one SMP_REQUEST frame, it shall be ready to receive one SMP_RESPONSE frame. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander with an attached target the Testing Station is instructed to transmit an Identify Address frame indicating that it is an SMP Initiator.


Observable Results: Verify that the DUT transmits an SMP Response, which is formatted properly and it not waiting on an interlocked frame. Possible Problems: None



Test 6.3.23 - SMP_REQUEST – CLOSE Purpose: To determine that the DUT, a SAS Expander, properly closes an SMP Connection. References:

[1] 6.19.5 SAS SPL [2] 8.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: Inside an SMP connection, the source device transmits a single SMP_REQUEST frame and the destination device responds with a single SMP_RESPONSE frame [2]. After receiving the SMP_RESPONSE frame, the source device shall transmit a CLOSE (NORMAL) to close the connection. After transmitting the SMP_RESPONSE frame, the destination device shall reply with a CLOSE (NORMAL). Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander with an attached target the Testing Station is instructed to transmit an Identify Address frame indicating that it is an SMP Initiator.


3. The Testing Station is instructed to transmit CLOSE. Observable Results: Verify that the DUT transmits a CLOSE(NORMAL) after receiving CLOSE from the Testing Station. Possible Problems: None



Test 6.3.24 - SMP_REQUEST – PROPER REQUEST FORMAT Purpose: To determine that the DUT, a SAS Expander, properly formats an SMP Request. References:

[1] 6.19.5 SAS SPL [2] 8.4 SAS SPL [3] 6.5 SAS SPL [4] 6.19.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: July 26, 2011 Discussion: Inside an SMP connection, the source device transmits a single SMP_REQUEST frame and the destination device responds with a single SMP_RESPONSE frame [2]. Frames are surrounded by SOF and EOF. See 6.19.5 for error handling details. The last data dword after the SOF prior to the EOF always contains a CRC [3]. The SMP link layer state machine checks that the frame is not too short and that the CRC is valid [4]. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an expander with an attached target the Testing Station is instructed to transmit an Identify Address frame indicating that it is an Edge Expander, with an SMP Target.

2. The DUT should open an SMP Connection to the Testing Station and transmit a REPORT_GENERAL SMP Request. The Testing Station is instructed to transmit a REPORT_GENERAL SMP Response.

Observable Results: Verify if the DUT transmits an SMP Request, which is formatted properly and is not waiting on an interlocked frame. Possible Problems: None



Test 6.3.25 - CLOSING SSP CONNECTIONS – CLOSE (CLEAR AFFILIATION) Purpose – To determine that the DUT properly responds when CLOSE (CLEAR AFFILIATION) is received. Reference:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: CLOSE is used to close a connection of any protocol. See [3] for details on closing SSP connections, [4] for details on closing STP connections, and [5] for details on closing SMP connections. After transmitting CLOSE (CLEAR AFFILIATION), the source phy shall initialize a Close Timeout timer to 1 ms and start the Close Timeout timer. Once an SSP phy has both transmitted and received DONE, it shall close the connection by transmitting CLOSE (NORMAL). CLOSE (CLEAR AFFILIATION) closes an open STP connection and clears the affiliation [1][6]. CLOSE (CLEAR AFFILIATION) is processed the same as CLOSE (NORMAL) if: a) the connection is not an STP connection;




2. The Testing Station is instructed to open an SSP connection to the DUT. Wait for the DUT to transmit OPEN_ACCEPT. The Testing Station is instructed to transmit a CLOSE (CLEAR AFFILIATION) primitive to the DUT.

Observable Results: Verify that the DUT transmitted CLOSE (NORMAL) within 1 ms of receiving CLOSE (CLEAR AFFILIATION) from the Testing Station. Possible Problems: None























Test 6.3.28 - LINK RESET – HARD_RESET RECIVED AFTER IDENTIFY Purpose: To determine that the DUT properly handles a received HARD_RESET. References:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: HARD_RESET is used to force a phy to generate a hard reset to its port. This primitive is only valid after the phy reset sequence without an intervening identification sequence [3] and shall be ignored at other times. If a phy receives a HARD_RESET, it shall be considered a reset event and cause a hard reset [4] of the port containing that phy. Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to targets. Test Procedure:



Station is instructed to transmit 6 consecutive HARD_RESET primitives. This must occur after the Identify sequence is complete.

Observable Results: Verify that the DUT does not transmit COMINIT upon receiving the HARD_RESET primitives from the Testing Station. Possible Problems: None



Test 6.3.29 - SSP_FRAMES – INTERLOCKED FRAME / NAK Purpose: To determine that the DUT handles interlocked frames with CRC errors properly. References:


Resource Requirements: SAS Protocol Analyzer and Generator Last Modification: July 26, 2011 Discussion: Before transmitting an interlocked frame, an SSP phy shall wait for all SSP frames to be acknowledged with ACK or NAK, even if credit is available. After transmitting an interlocked frame, an SSP phy shall not transmit another SSP frame until it has been acknowledged with ACK or NAK, even if credit is available. A reciving SSP phy shall respond to a SSP frame with NAK (CRC ERROR) if the SSP frame was received with a bad CRC. Test Setup: The DUT and the Testing Station are physically connected. This test is only applicable to targets. Test Procedure:


2. The Testing Station is instructed to open a SSP connection to the DUT and transmit a SCSI_INQUIRY command with an invalid CRC.

3. Wait for the DUT to transmit NAK (CRC ERROR). Observable Results: Verify that upon receiving the INQUIRY command with an invalid CRC, the DUT transmitted NAK (CRC ERROR) before transmitting any other frame to the Testing Station. Possible Problems: None


SERIAL ATTACHED SCSI (SAS) CONSORTIUM

Clause 8

SAS SPL Transport Layer Test Suite Version 1.14

Technical Document

Last Updated: August 8, 2011

Serial Attached SCSI Consortium 121 Technology Drive, Suite 2 InterOperability Laboratory Durham, NH 03824 University of New Hampshire Phone: (603) 862-0701 Fax: (603) 862-4181 http://www.iol.unh.edu/consortiums/sas



The University of New Hampshire InterOperability Laboratory TABLE OF CONTENTS

MODIFICATION RECORD ..................................................................................3

ACKNOWLEDGMENTS .......................................................................................4

INTRODUCTION....................................................................................................5

REFERENCES.........................................................................................................7

GROUP 1: TRANSPORT LAYER TESTS FOR TARGETS ..............................8 TEST 9.1.1 - SSP FRAMES STRUCTURE – HASHED ADDRESS ........................................ 9 TEST 9.1.2 - SSP FRAMES STRUCTURE – INFORMATION UNIT ................................... 10 TEST 9.1.3 - SSP FRAMES STRUCTURE – NUMBER OF FILL BYTES ........................... 11 TEST 9.1.4 - SSP COMMAND IU – TAG ............................................................................... 12 TEST 9.1.5 - SSP COMMAND IU – TARGET PORT TRANSFER TAG............................... 13 TEST 9.1.6 - SSP DATA IU – NUMBER OF FILL BYES NON-ZERO ................................. 14 TEST 9.1.7 - SSP DATA IU – NUMBER OF FILL BYES ZERO ........................................... 15 TEST 9.1.8 - SSP DATA IU – DATA OFFSET......................................................................... 16 TEST 9.1.9 - SSP XFER_RDY IU – REQUESTED OFFSET ................................................. 17 TEST 9.1.10 - SSP XFER_RDY IU – REQUESTED OFFSET LARGE TRANSFER............ 18 TEST 9.1.11 - SSP XFER_RDY IU – MAXIMUM BURST SIZE .......................................... 19 TEST 9.1.12 - SSP XFER_RDY IU – WRITE DATA LENGTH ............................................. 20 TEST 9.1.13 - SSP RESPONSE IU – NO DATA PRESENT ................................................... 21 TEST 9.1.14 - SSP RESPONSE IU – SENSE DATA PRESENT............................................. 22 TEST 9.1.15 - SSP RESPONSE IU – SENSE/RESPONSE DATA NOT PRESENT............... 23 TEST 9.1.16 - SSP RESPONSE IU –RESPONSE DATA PRESENT ...................................... 24 TEST 9.1.17 - SSP ERROR HANDLING – INVALID LENGTH ........................................... 25 TEST 9.1.18 - SSP ERROR HANDLING – INVALID LUN ................................................... 26 TEST 9.1.19 - SSP ERROR HANDLING – NO ACK/NAK RECEIVED............................... 27 TEST 9.1.20 - SSP ERROR HANDLING – UNKNOWN TAG .............................................. 28

GROUP 2: TRANSPORT LAYER TESTS FOR INITIATIORS......................29 TEST 8.2.1 - SSP FRAMES STRUCTURE – HASHED ADDRESS ...................................... 30 TEST 9.2.2 - SSP FRAMES STRUCTURE – INFORMATION UNIT ................................... 31 TEST 9.2.3 - SSP FRAMES STRUCTURE – NUMBER OF FILL BYTES ........................... 32 TEST 9.2.4 - SSP COMMAND IU – TAG ............................................................................... 33 TEST 9.2.5 - SSP COMMAND IU – TARGET PORT TRANSFER TAG............................... 34 TEST 9.2.6 - SSP DATA IU – TPT TAG FIRST BURST DATA.............................................. 35 TEST 9.2.7 - SSP DATA IU – TPT TAG NON-DATA ............................................................. 36 TEST 9.2.8 - SSP RESPONSE IU – DATAPRES RESERVED ............................................... 37 TEST 9.2.9 - SSP ERROR HANDLING – EXTRA RESPONSE FRAME RECEIVED......... 38

Serial Attached SCSI Consortium Group 2 Clause 8 SAS SPL Transport Layer Test Suite v1.15


MODIFICATION RECORD [1]September 7, 2004 (Version 0.1) DRAFT RELEASE

David Woolf: Initial draft release [2]April 14, 2005 (Version 0.12) DRAFT RELEASE

David Woolf: added STP Operations tests [3]July 11, 2005 (Version 0.13) DRAFT RELEASE

David Woolf: minor edits [4]August 29, 2005 (Version 0.14) DRAFT RELEASE Leon Cyril: minor edits [5]October 2, 2005 (Version 1.0) FINAL RELEASE Leon Cyril: added discussion for all tests. [6]December 6, 2005 (Version 1.1) FINAL RELEASE David Woolf: updated References and tests 9.2.8 and 9.2.8 [7]January 17, 2006 (Version 1.11) FINAL RELEASE David Woolf: fixed ‘Purpose’ sections of Tests 9.1.9 – 9.1.12 [8]August 15, 2006 (Version 1.12) FINAL RELEASE Michael Davidson: Removed Research Computing Center References [9]January, 2007 (Version 1.13) FINAL RELEASE Michael Davidson and David Woolf: Corrected tests 9.2.8 and 9.2.9 [10]June 18, 2007 (Version 1.14) FINAL RELEASE Michael Davidson and David Woolf: Corrected tests 9.2.6 and 9.2.7 [11]August 8, 2011 (Version 1.15) FINAL RELEASE Joshua Beaudet: Updated all references

Serial Attached SCSI Consortium 3 Clause 9 SAS Transport Layer Test Suite v1.14

The University of New Hampshire InterOperability Laboratory ACKNOWLEDGMENTS

The University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite. Leon Cyril UNH InterOperability Laboratory (UNH-IOL) Michael Davidson UNH InterOperability Laboratory (UNH-IOL) Kurtis Kofler UNH InterOperability Laboratory (UNH-IOL) David Woolf UNH InterOperability Laboratory (UNH-IOL)



INTRODUCTION The University of New Hampshire’s InterOperability Laboratory (IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. This particular suite of tests has been developed in junction with CATC to help implementers evaluate the functionality of their Serial Attached SCSI (SAS) products. Specifically this Test Suite is directed at verifying the Transport layer of SAS Targets and Initiators. These tests are designed to determine if a SAS product conforms to specifications defined in ISO/IEC 14776-150, Serial Attached SCSI (SAS) standard T10/1562-D, Revision 5 (hereafter referred to as the “SAS SPL”). Successful completion of all tests contained in this suite does not guarantee that the tested device will successfully operate with other SAS products. However, when combined with satisfactory operation in the IOL’s interoperability test bed, these tests provide a reasonable level of confidence that the Device Under Test (DUT) will function properly in many SAS environments. The tests contained in this document are organized in order to simplify the identification of information related to a test, and to facilitate in the actual testing process. Tests are separated into groups, primarily in order to reduce setup time in the lab environment, however the different groups typically also tend to focus on specific aspects of device functionality. A three-number, dot-notated naming system is used to catalog the tests, where the first number always indicates the specific clause of the reference standard on which the test suite is based. The second and third numbers indicate the test’s group number and test number within that group, respectively. This format allows for the addition of future tests in the appropriate groups without requiring the renumbering of the subsequent tests. 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 subclauses 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. Last Modification This specifies the date of the last modification to this test. 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 (next). 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. 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. 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.



REFERENCES The following document is referenced in this text:

[1] T10/Project 2124-D/Rev 7 – Information Technology SAS Protocol Layer – (SAS SPL)



GROUP 1: TRANSPORT LAYER TESTS FOR TARGETS

Overview:

This group of tests verifies the Transport Layer specifications of the SAS protocol defined in Clause 8 of the SAS SPL, for Targets.



Test 8.1.1 - SSP FRAMES STRUCTURE – HASHED ADDRESS Purpose: To determine that the DUT properly calculated a hashed destination SAS address based on the sas address provided in a received Identify Frame. References:

[1] 4.2.5 SAS SPL [2] Annex C SAS SPL [3] Annex D SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: August 8, 2011 Discussion: SSP frames include a hashed version of the SAS address to provide an additional level of verification of proper frame routing. The code used for the hashing algorithm is a cyclic binary Bose, Chaudhuri, and Hocquenghem (BCH) (63, 39, 9) code. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a target The Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator. The SAS address provided in the Identify Frame should be 7FFFFFFFFFFFFFFFh.


transmit a SCSI INQUIRY command to the DUT, then close the connection. 4. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit a SCSI

Response to the Testing Station.

Observable Results: In each case verify that the DUT transmitted an SSP frame (command or response) with a hashed destination SAS address of 000000h. Possible Problems: None



Test 8.1.2 - SSP FRAMES STRUCTURE – INFORMATION UNIT Purpose: To determine that the DUT does not transmit an SSP frame with an Information Unit exceeding 1024 bytes. References:

[1] 8.2.1 SAS SPL [2] Table 117 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: August 8, 2011 Discussion: [2] defines the SSP frame format. The INFORMATION UNIT field contains the information unit, the format of which is defined by the FRAME TYPE field. The maximum size of the INFORMATION UNIT field is 1 024 bytes, making the maximum size of the frame 1052 bytes (1024 bytes of data + 24 bytes of header + 4 bytes of CRC). Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a target The Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.

2. The Testing Station is instructed to open an SSP connection to the DUT. The Testing Station is instructed to transmit a Test Unit Ready command to the DUT, then close the connection.

3. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit a SCSI Response to the Testing Station. The Testing Station is instructed to repeat this 100 times.

Observable Results: If the DUT is an initiator, verify that the Information Unit in the SSP Command frame is between 28 and 284 bytes long. If the DUT is a target, verify that the Information Unit in the SSP Response frame is between 24 and 1024 bytes long. Possible Problems: None



Test 8.1.3 - SSP FRAMES STRUCTURE – NUMBER OF FILL BYTES Purpose: To determine that the DUT properly sets the NUMBER OF FILL BYTES field. References:

[1] 8.2.1 SAS SPL [2] 8.2.2.4 SAS SPL [3] 8.2.2.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: Table 117 defines the SSP frame format. The NUMBER OF FILL BYTES field specifies the number of fill bytes between the INFORMATION UNIT field and the CRC field. The NUMBER OF FILL BYTES field shall be set to zero for all frame types except DATA frames as specified in [2] and RESPONSE frames as specified in [3]. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a target The Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.

2. The Testing Station is instructed to open an SSP connection to the DUT. The Testing Station is instructed to transmit a READ command to the DUT.

3. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit DATA and SCSI Response to the Testing Station.

Observable Results: If the DUT is a target, verify that the NUMBER OF FILL BYTES field in the SSP Response frame is set to 0. Possible Problems: None



Test 8.1.4 - SSP COMMAND IU – TAG Purpose: To determine that the DUT properly sets the TAG field. References:

[1] 8.2.1 SAS SPL [2] 6.13 SAS SPL [3] 9.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target with 2 LUNs within the same SSP Target Port. If the DUT is an initiator, it will need to have software capable of generating SCSI traffic. Last Modification: August 8, 2011 Discussion: Table 117 defines the SSP frame format. The TAG field contains a value that allows the SSP initiator port to establish a context for commands and task management functions. For COMMAND frames and TASK frames, the SSP initiator port shall set the TAG field to a value that is unique for the I_T nexus established by the connection (see 6.13). An SSP initiator port shall not reuse the same tag when transmitting COMMAND frames or TASK frames to different LUNs in the same SSP target port. An SSP initiator port may reuse a tag when transmitting frames to different SSP target ports. The TAG field in a COMMAND frame contains the task tag defined in SAM-3. The TAG field in a TASK frame does not correspond to a SAM-3 task tag, but corresponds to an SAM-3 association (see 9.2.1). The tag space used in the TAG fields is shared across COMMAND frames and TASK frames (e.g., if a tag is used for a COMMAND frame, it is not also used for a concurrent TASK frame). Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:

1. Power on the DUT. 2. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify

sequence with the DUT. Since the DUT is a target The Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.

3. The Testing Station is instructed to open an SSP connection to the DUT. The Testing Station is instructed to transmit a READ command to the DUT.

4. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit DATA and SCSI Response to the Testing Station.

5. The Testing Station is instructed to open an SSP connection to the DUT. The Testing Station is instructed to transmit a WRITE command to the DUT.

6. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit XFER_RDY, then The Testing Station is instructed to transmit a SSP DATA frame. Allow the DUT to transmit a SCSI Response to the Testing Station.

Observable Results: If the DUT is a target, verify that the TAG in the XFER_RDY, DATA and RESPONSE frames matched the TAG of the COMMAND frames which they corresponded to. Possible Problems: None



Test 8.1.5 - SSP COMMAND IU – TARGET PORT TRANSFER TAG Purpose: To determine that the DUT properly sets the TARGET PORT TRANSFER TAG field. References:


Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target with 2 LUNs within the same SSP Target Port. If the DUT is an initiator, it will need to have software capable of generating SCSI traffic. Last Modification: August 8, 2011 Discussion: [2] defines the SSP frame format. The TARGET PORT TRANSFER TAG field provides an optional method for an SSP target port to establish the write data context when receiving a write DATA frame (i.e., determine the command to which the write data corresponds). Unlike the TAG field, which was assigned by the SSP initiator port, the TARGET PORT TRANSFER TAG field in a write DATA frame contains a value assigned by the SSP target port that was delivered to the SSP initiator port in the XFER_RDY frame requesting the write data. Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:


sequence with the DUT. Since the DUT is a target The Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.

3. The Testing Station is instructed to open an SSP connection to the DUT. The Testing Station is instructed to transmit a WRITE BUFFER command to the DUT.


5. The Testing Station is instructed to open a second SSP connection to the DUT. The Testing Station is instructed to transmit a WRITE BUFFER command to the DUT do a different LUN than the first WRITE_BUFFER command .


Observable Results: SSP Targets have the option of setting the TARGET PORT TRANSFER TAG field to any value when transmitting a frame. In an XFER_RDY frame the Target Port Transfer Tag should be unique for the L_Q portion of the I_T_L_Q nexus. Possible Problems: None



Test 8.1.6 - SSP DATA IU – NUMBER OF FILL BYTES NON-ZERO Purpose: To determine that the DUT, an SSP Target port, properly sets the NUMBER OF FILL BYTES field when transmitting DATA frames. References:

[1] 8.2.2.4 SAS SPL [2] 8.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: An SSP target port shall set the NUMBER OF FILL BYTES field to zero in the frame header [2] in all read DATA frames for a command except the last read DATA frame for that command. The SSP target port may set the NUMBER OF FILL BYTES field to a non-zero value in the last read DATA frame for a command (i.e., only the last read DATA frame for a command may contain data with a length that is not a multiple of four). Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is a target The Testing Station is instructed to transmit an Identify Address frame indicating that it is a SAS Initiator.

2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI READ or READ_BUFFER command for 1539 bytes. Close the connection

3. Allow the DUT to open an SSP connection to the Testing Station and transmit DATA frames and a SCSI response frame to the received command.

Observable Results: Verify that if the DUT sets the NUMBER OF FILL BYTES field to a non-zero value in a DATA frame, the DUT does not transmit any further DATA frames for that command. Possible Problems: None



Test 8.1.7 - SSP DATA IU – NUMBER OF FILL BYTES ZERO Purpose: To determine that the DUT, an SSP Target port, properly sets the NUMBER OF FILL BYTES field when transmitting DATA frames. References:

[1] 8.2.2.4 SAS SPL [2] 8.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: An SSP target port shall set the NUMBER OF FILL BYTES field to zero in the frame header [2] in all read DATA frames for a command except the last read DATA frame for that command. The SSP target port may set the NUMBER OF FILL BYTES field to a non-zero value in the last read DATA frame for a command (i.e., only the last read DATA frame for a command may contain data with a length that is not a multiple of four). Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI READ or READ_BUFFER command for 1539 bytes. Close the connection


Observable Results: Verify that if the DUT sets the NUMBER OF FILL BYTES field to zero in a DATA frame, the DUT continues to transmit DATA frames for that command. Possible Problems: None



Test 8.1.8 - SSP DATA IU – DATA OFFSET Purpose: To determine that the DUT, an SSP Target port, properly sets the DATA OFFSET field when transmitting DATA frames. References:

[1] 8.2.2.4 SAS SPL [2] 8.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: The DATA OFFSET field in the frame header [2] contains the application client buffer offset as described by SAM-3. The data offset shall be a multiple of four (i.e., each DATA frame shall transfer data beginning on a dword boundary). The initial read DATA frame for a given command shall set the DATA OFFSET field to zero. If any additional read DATA frames are required, the DATA OFFSET field shall be set to the value of the previous read DATA frame’s data offset plus the previous read DATA frame’s data length. The initial write DATA frame for a given command shall set the DATA OFFSET field to zero. If any additional write DATA frames are required, the DATA OFFSET field shall be set to the value of the previous write DATA frame’s data offset plus the previous write DATA frame’s data length. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI READ_BUFFER command for 3836 bytes. Close the connection


Observable Results: Verify that if the DUT sets the DATA OFFSET field to zero in the first DATA frame, then sets the DATA OFFSET field in subsequent DATA frames to the value of the previous frames DATA OFFSET field plus the data length of the previous frame. Possible Problems: None



Test 8.1.9 - SSP XFER_RDY IU – REQUESTED OFFSET Purpose: To determine that the DUT, an SSP Target port, properly sets the REQUESTED OFFSET field when transmitting XFER_RDY frames. References:

[1] 8.2.2.3 SAS SPL [2] 9.2.7.2.1 SAS SPL [3] 8.2.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: The REQUESTED OFFSET field contains the application client buffer offset of the segment of write data the SSP initiator port may transmit to the logical unit (using DATA frames). The requested offset shall be a multiple of four (i.e., each DATA frame shall begin transferring data on a dword boundary). The REQUESTED OFFSET field shall be zero for the first XFER_RDY frame of a command unless:

• the ENABLE FIRST BURST field in the COMMAND frame [3] was set to one; and • the FIRST BURST SIZE field in the Disconnect-Reconnect mode page [2] is not set to zero. • If the ENABLE FIRST BURST field in the COMMAND frame [3] was set to one, then in the initial

XFER_RDY frame for the command, the SSP target port shall set the REQUESTED OFFSET field to the value indicated by the FIRST BURST SIZE field in the Disconnect-Reconnect mode page [2]. If any additional XFER_RDY frames are required, the REQUESTED OFFSET field shall be set to the value of the previous XFER_RDY frame’s REQUESTED OFFSET field plus the value of the previous XFER_RDY frame’s WRITE DATA LENGTH field.

Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:


sequence with the DUT. Since the DUT is a target The Testing Station is instructed to transmit an Identify Address frame indicating that it is a SAS Initiator.

3. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI MODE SENSE command for the Disconnect-Reconnect Mode Page. Close the connection

4. Allow the DUT to open an SSP connection to the Testing Station and transmit DATA frame with the Mode Page Block Descriptor and a SCSI response frame to the received MODE SENSE command.

5. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI WRITE command for 2048 bytes. Close the connection

6. Allow the DUT to open an SSP connection to the Testing Station and transmit XFER_RDY, DATA, SCSI response frame to the received command.

Observable Results: Verify that the DUT sets the REQUESTED OFFSET field to zero in the first XFER_RDY frame unless the First Burst Size field in the Disconnect Reconnect Mode Page is not zero. If the First Burst Size field in the Disconnect Reconnect Mode Page is not zero then the REQUESTED OFFSET field should be set to 512 times the value in the First Burst Size field. Possible Problems: None



Test 8.1.10 - SSP XFER_RDY IU – REQUESTED OFFSET LARGE TRANSFER Purpose: To determine that the DUT, an SSP Target port, properly sets the REQUESTED OFFSET field when transmitting multiple XFER_RDY frames. References:


Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: The REQUESTED OFFSET field contains the application client buffer offset of the segment of write data the SSP initiator port may transmit to the logical unit (using DATA frames). The requested offset shall be a multiple of four (i.e., each DATA frame shall begin transferring data on a dword boundary). The REQUESTED OFFSET field shall be zero for the first XFER_RDY frame of a command unless: a) the ENABLE FIRST BURST field in the COMMAND frame [3] was set to one; and b) the FIRST BURST SIZE field in the Disconnect-Reconnect mode page [2] is not set to zero. If the ENABLE FIRST BURST field in the COMMAND frame [3] was set to one, then in the initial XFER_RDY frame for the command, the SSP target port shall set the REQUESTED OFFSET field to the value indicated by the FIRST BURST SIZE field in the Disconnect-Reconnect mode page [2]. If any additional XFER_RDY frames are required, the REQUESTED OFFSET field shall be set to the value of the previous XFER_RDY frame’s REQUESTED OFFSET field plus the value of the previous XFER_RDY frame’s WRITE DATA LENGTH field. Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:




4. Allow the DUT to open an SSP connection to the Testing Station and transmit XFER_RDY, SCSI response frame to the received command.

Observable Results: Verify that for each XFER_RDY frame, the DUT sets the REQUESTED OFFSET field to the REQUESTED OFFSET value of the previous XFER_RDY frame plus the WRITE DATA LENGTH field of the previous XFER_RDY frame. Possible Problems: None



Test 8.1.11 - SSP XFER_RDY IU – MAXIMUM BURST SIZE Purpose: To determine that the DUT, an SSP Target port, properly sets the WRITE DATA LENGTH field when transmitting XFER_RDY frames. References:

[1] 8.2.2.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: The WRITE DATA LENGTH field contains the number of bytes of write data the SSP initiator port may transmit to the logical unit (using DATA frames) from the application client buffer starting at the requested offset. The SSP target port shall set the WRITE DATA LENGTH field to a value greater than or equal to 00000001h. If the value in the MAXIMUM BURST SIZE field in the Disconnect-Reconnect mode page is not zero, the SSP target port shall set the WRITE DATA LENGTH field to a value less than or equal to the value in the MAXIMUM BURST SIZE field Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:






6. Allow the DUT to open an SSP connection to the Testing Station and transmit XFER_RDY, DATA, and SCSI response frame to the received command.

Observable Results: Verify that the DUT sets the WRITE DATA LENGTH field to a value less than or equal to the value in the MAXIMUM BURST SIZE field in the Disconnect Reconnect Mode Page. If the DUT sets MAXIMUM BURST SIZE to Zero, this would indicate that it can accept any WRITE DATA LENGTH, and this item is not testable. Possible Problems: None



Test 8.1.12 - SSP XFER_RDY IU – WRITE DATA LENGTH Purpose: To determine that the DUT, an SSP Target port, properly sets the WRITE DATA LENGTH field when transmitting XFER_RDY frames. References:

[1] 8.2.2.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If an SSP target port transmits a XFER_RDY frame containing a WRITE DATA LENGTH field that is not divisible by four, the SSP target port shall not transmit any subsequent XFER_RDY frames for that command (i.e., only the last XFER_RDY for a command may request a non-dword multiple write data length). Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:





5. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI WRITE_BUFFER command for 2051 bytes. Close the connection

6. Allow the DUT to open an SSP connection to the Testing Station and transmit XFER_RDY, DATA, SCSI response frame to the received command.

Observable Results: Verify that if the DUT sets the WRITE DATA LENGTH field not a value that is not divisible by four, that this is the last XFER_RDY frame for a command. Possible Problems: None



Test 8.1.13 - SSP RESPONSE IU – NO DATA PRESENT Purpose: To determine that the DUT, an SSP Target port, properly sets the DATAPRES field to NO_DATA if a command completes without sense data to return. References:

[1] 8.2.2.5.1 SAS SPL [2] Table 126SAS SPL [3] 8.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: [2] defines the response IU. The RESPONSE frame is sent by an SSP target port to deliver SCSI status (e.g., GOOD or CHECK CONDITION) and sense data, or to deliver SSP-specific status (e.g., illegal frame format). The maximum size of the RESPONSE frame is the maximum size of any IU in an SSP frame [3]. The SSP target port shall return a RESPONSE frame with the DATAPRES field set to NO_DATA if a command completes without response data or sense data to return. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI Test Unit Ready command to the DUT. This should not be the first command received by the DUT since power on. Close the connection

3. Allow the DUT to open an SSP connection to the Testing Station and transmit a SCSI response frame to the received command.

Observable Results: Verify that if the DUT sets the DATAPRES field to NO_DATA if the command completes without sense data to return when the command finishes with status GOOD. Possible Problems: None



Test 8.1.14 - SSP RESPONSE IU – SENSE DATA PRESENT Purpose: To determine that the DUT, an SSP Target port, properly sets the DATAPRES field to SENSE_DATA if a command completes with sense data to return. References:

[1] 8.2.2.5.1 SAS SPL [2] Table 126SAS SPL [3] 8.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: [2] defines the response IU. The RESPONSE frame is sent by an SSP target port to deliver SCSI status (e.g., GOOD or CHECK CONDITION) and sense data, or to deliver SSP-specific status (e.g., illegal frame format). The maximum size of the RESPONSE frame is the maximum size of any IU in an SSP frame [3]. The SSP target port shall return a RESPONSE frame with the DATAPRES field set to SENSE_DATA if a command completes with sense data to return (e.g., CHECK CONDITION status). Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:



3. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI Test Unit Ready command to the DUT. This should be the first command received by the DUT since power on. Close the connection


Observable Results: Verify that the DUT sets the DATAPRES field to SENSE_DATA and the command completes with sense data to return when the command finishes with status CHECK CONDITION. Possible Problems: None



Test 8.1.15 - SSP RESPONSE IU – SENSE/RESPONSE DATA NOT PRESENT Purpose: To determine that the DUT, an SSP Target port, properly sets the SENSE DATA LENGTH, SENSE DATA, RESPONSE DATA LENGTH, and RESPONSE DATA fields if a command completes without sense data to return. References:

[1] 8.2.2.5.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If the DATAPRES field is set to NO_DATA, then:

• the SSP target port shall set the STATUS field to the status code for a command that has ended (see SAM-3 for a list of status codes);

• the SSP target port shall set the SENSE DATA LENGTH field to zero and the RESPONSE DATA LENGTH field to zero;

• the SSP target port shall not include the SENSE DATA field and the RESPONSE DATA field. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI Test Unit Ready command to the DUT. This should not be the first command received by the DUT since power on. Close the connection


Observable Results: Verify that if the DUT sets the DATAPRES field to NO_DATA if the command completes without sense data to return when the command finishes with status GOOD. The SENSE DATA LENGTH and RESPONSE DATA LENGTH fields shall be set to 0. The SENSE DATA and RESPONSE DATA fields should not be present. Possible Problems: None



Test 8.1.16 - SSP RESPONSE IU –RESPONSE DATA PRESENT Purpose: To determine that the DUT, an SSP Target port, properly sets the RESPONSE DATA fields if a command completes with response data to return. References:

[1] 8.2.2.5.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If the DATAPRES field is set to RESPONSE_DATA, then:

• the SSP target port shall set the STATUS field to zero and the SENSE DATA LENGTH field to zero; • the SSP target port shall not include the SENSE DATA field; • the SSP target port shall set the RESPONSE DATA LENGTH field to 00000004h. Other lengths are

reserved for future standardization; and • the SSP target port shall include the RESPONSE DATA field.

Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a TASK MANAGEMENT command with an Invalid LUN.

3. Allow the DUT to open an SSP connection and transmit a SCSI response frame to the received command and data.

Observable Results: Verify that if the DUT sets the DATAPRES field to RESPONSE_DATA. The SENSE DATA LENGTH should be set to zero. The RESPONSE DATA LENGTH field shall be set to 4 and the RESPONSE DATA field should be present. Possible Problems: None



Test 8.1.17 - SSP ERROR HANDLING – INVALID LENGTH Purpose: To determine that the DUT, an SSP Target port properly handles a command received which is too short to contain a valid CDB. References:

[1] 8.2.5.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If an SSP target port receives a COMMAND frame and:

• the frame is too short to contain a LUN field; • the frame is too short to contain a CDB; or • the ADDITIONAL CDB LENGTH field specifies that the frame should be a different length,

the ST_TTS state machine returns a RESPONSE frame with the DATAPRES field set to RESPONSE_DATA and the RESPONSE CODE field set to INVALID FRAME. This test verifies that an appropriate RESPONSE frame is sent when a frame is too short to contain a valid CDB. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI INQUIRY command with a too short CDB. Close the connection

3. Allow the DUT to open an SSP connection and transmit a SCSI response frame to the received command and data.

Observable Results: Verify if the DUT sets the DATAPRES field to RESPONSE_DATA and the RESPONSE CODE field to INVALD FRAME. Possible Problems: None



Test 8.1.18 - SSP ERROR HANDLING – INVALID LUN Purpose: To determine that the DUT, an SSP Target port, properly handles a TASK frame received with an invalid LUN. References:

[1] 8.2.2.2 SAS SPL [2] 8.2.6.3.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If an SSP target port receives a TASK frame with an unknown logical unit number, the ST_TFR state machine returns a RESPONSE frame with the DATAPRES field set to RESPONSE_DATA and the RESPONSE CODE field set to INVALID LOGICAL UNIT NUMBER [2]. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a TASK frame of function LOGICAL UNIT RESET with an invalid LUN. Close the connection

3. Allow the DUT to open an SSP connection and transmit a SCSI response frame to the received TASK frame.

Observable Results: Verify that the DUT sets the DATAPRES field to RESPONSE_DATA and the RESPONSE CODE field to INVALD LOGICAL UNIT. Possible Problems: None



Test 8.1.19 - SSP ERROR HANDLING – NO ACK/NAK RECEIVED Purpose: To determine that the DUT, an SSP Target port, responds properly when no acknowledgement is received for a transmitted RESPONSE frame. References:

[1] 8.2.4.7 SAS SPL [2] 6.17.8.6.5 SAS SPL [3] 8.2.6.3.3 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If an SSP target port transmits a RESPONSE frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken):

1. the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) [2];and 2. the ST_TTS state machine retransmits, in a new connection, the RESPONSE frame with the

RETRANSMIT bit set to one [3]. Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:




4. Allow the DUT to open an SSP connection to the Testing Station and transmit XFER_RDY. 5. The Testing Station is instructed to open a connection to the DUT and transmit 2 512 byte data frames.

Close the connection. 6. Allow the DUT to open an SSP connection and transmit a SCSI RESPONSE frame to the received

command and data. The Testing Station is instructed to not transmit ACK or NAK to the RESPONSE frame.

Observable Results: Verify that if the DUT retransmits the RESPONSE frame with the RETRANSMIT bit set to 1.




Test 8.1.20 - SSP ERROR HANDLING – UNKNOWN TAG Purpose: To determine that the DUT, an SSP Target port, responds properly when a DATA frame is received with an unknown tag. References:

[1] 8.2.5.1 SAS SPL [2] 8.2.6.3.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If the frame type is DATA, and the tag does not match a tag for an outstanding command performing write operations, then this state machine shall discard the frame. If the frame type is DATA, and the tag matches a tag for an outstanding command performing write operations without first burst data enabled or for which no Transmission Complete (Xfer_Rdy Delivered) message has been received from an ST_TTS state machine, then this state machine shall discard the frame. If the frame type is DATA and a target port transfer tag was assigned in an XFER_RDY frame for the request, then this state machine shall check the target port transfer tag. If the target port transfer tag does not specify a valid state machine, then this state machine shall discard the frame. Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on.

Test Procedure:




4. Allow the DUT to open an SSP connection to the Testing Station and transmit XFER_RDY. 5. The Testing Station is instructed to open a connection to the DUT and transmit 3 512 byte DATA

frames. One of the DATA frames should have a TAG different than the TAG of the WRITE command. Close the connection.

6. Allow the DUT to open an SSP connection and transmit a SCSI RESPONSE frame to the received command and data.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command completed with GOOD status and that the DUT discarded the DATA frame with an unknown TAG. Possible Problems: None



GROUP 2: TRANSPORT LAYER TESTS FOR INITIATIORS Overview:

This group of tests verifies the Transport Layer specifications of the SAS protocol defined in Clause 8 of the SAS SPL, for Initiators.



Test 8.2.1 - SSP FRAMES STRUCTURE – HASHED ADDRESS Purpose: To determine that the DUT properly calculated a hashed destination SAS address based on the sas address provided in a received Identify Frame. References:

[1] 4.2.5 SAS SPL [2] Annex C SAS SPL [3] Annex D SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. Last Modification: August 8, 2011 Discussion: SSP frames include a hashed version of the SAS address to provide an additional level of verification of proper frame routing. The code used for the hashing algorithm is a cyclic binary Bose, Chaudhuri, and Hocquenghem (BCH) (63, 39, 9) code. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator The Testing Station is instructed to transmit an Identify Address frame indicating that it is a target. The SAS address provided in the Identify Frame should be 7FFFFFFFFFFFFFFFh.

2. Wait for the DUT to open an SSP connection to the Testing Station. Allow the DUT to transmit a SCSI Command to the Testing Station.

Observable Results: In each case verify that the DUT transmitted an SSP frame (command or response) with a hashed destination SAS address of 000000h. Possible Problems: None



Test 8.2.2 - SSP FRAMES STRUCTURE – INFORMATION UNIT Purpose: To determine that the DUT does not transmit an SSP frame with an Information Unit exceeding 1024 bytes. References:


Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. If the DUT is a SAS Intiator, software capable of generating SCSI commands. Last Modification: August 8, 2011 Discussion: Table 117 defines the SSP frame format. The INFORMATION UNIT field contains the information unit, the format of which is defined by the FRAME TYPE field. The maximum size of the INFORMATION UNIT field is 1 024 bytes, making the maximum size of the frame 1052 bytes (1024 bytes of data + 24 bytes of header + 4 bytes of CRC). Test Setup: The DUT and the Testing Station are physically connected. The SAS Initiator DUT is attached to the SAS Target through a SAS Protocol analyzer.

Test Procedure:

1. Wait for the DUT to open an SSP connection to the attached SAS Target. Allow the DUT to transmit a SCSI commands to the target. The DUT should transmit at least 50 commands.

2. The target should respond to each received command with SCSI Response with status GOOD.

Observable Results: Verify that the Information Unit in the SSP Command frame is between 28 and 284 bytes long. Possible Problems: None



Test 8.2.3 - SSP FRAMES STRUCTURE – NUMBER OF FILL BYTES Purpose: To determine that the DUT properly sets the NUMBER OF FILL BYTES field. References:

[1] 8.2.1 SAS SPL [2] Table 117 SAS SPL [3] 8.2.2.4 SAS SPL [4] 8.2.2.5 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target. If the DUT is a SAS Initiator, software capable of generating SCSI commands. Last Modification: August 8, 2011 Discussion: [2] defines the SSP frame format. The NUMBER OF FILL BYTES field specifies the number of fill bytes between the INFORMATION UNIT field and the CRC field. The NUMBER OF FILL BYTES field shall be set to zero for all frame types except DATA frames as specified in [3] and RESPONSE frames as specified in [4]. Test Setup: The DUT and the Testing Station are physically connected. The SAS Initiator DUT is attached to the SAS Target through a SAS Protocol analyzer.

Test Procedure:

1. Wait for the DUT to open an SSP connection to the attached SAS target. Allow the DUT to transmit a SCSI WRITE command to the Testing Station. The target should respond with XFER_RDY and wait for the DUT to transmit DATA frames.

Observable Results: Verify that the NUMBER OF FILL BYTES field in the SSP Command frame is set to 0. Possible Problems: None



Test 8.2.4 - SSP COMMAND IU – TAG Purpose: To determine that the DUT properly sets the TAG field. References:

[1] 8.2.1 SAS SPL [2] Table 117 SAS SPL [3] 6.13 SAS SPL [4] 9.2.1 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target with 2 LUNs within the same SSP Target Port. If the DUT is an initiator, it will need to have software capable of generating SCSI traffic. Last Modification: August 8, 2011 Discussion: [2] defines the SSP frame format. The TAG field contains a value that allows the SSP initiator port to establish a context for commands and task management functions. For COMMAND frames and TASK frames, the SSP initiator port shall set the TAG field to a value that is unique for the I_T nexus established by the connection [3]. An SSP initiator port shall not reuse the same tag when transmitting COMMAND frames or TASK frames to different LUNs in the same SSP target port. An SSP initiator port may reuse a tag when transmitting frames to different SSP target ports. The TAG field in a COMMAND frame contains the task tag defined in SAM-3. The TAG field in a TASK frame does not correspond to a SAM-3 task tag, but corresponds to an SAM-3 association [4]. The tag space used in the TAG fields is shared across COMMAND frames and TASK frames (e.g., if a tag is used for a COMMAND frame, it is not also used for a concurrent TASK frame). Test Setup: The DUT and the Testing Station are physically connected. The SAS Initiator DUT is attached to the SAS Target through a SAS Protocol analyzer.

Test Procedure:

1. Allow the DUT to open a connection to the attached SAS Target. Observe commands from the DUT to each LUN on the target.

Observable Results: If the DUT is an initiator, verify that the TAG field is unique for commands to different LUNs on the SSP target port. Possible Problems: None



Test 8.2.5 - SSP COMMAND IU – TARGET PORT TRANSFER TAG Purpose: To determine that the DUT properly sets the TARGET PORT TRANSFER TAG field. References:

[1] 8.2.1 SAS SPL [2] 8.2.2.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. SAS Target with 2 LUNs within the same SSP Target Port. If the DUT is an initiator, it will need to have software capable of generating SCSI traffic. Last Modification: August 8, 2011 Discussion: SSP initiator ports shall set the TARGET PORT TRANSFER TAG field as follows:

• For each write DATA frame that is sent in response to an XFER_RDY frame, the SSP initiator port shall set the TARGET PORT TRANSFER TAG field to the value that was in the corresponding XFER_RDY frame;

• For each write DATA frame that is sent containing first burst data [2], the SSP initiator port shall set the TARGET PORT TRANSFER TAG field to FFFFh; and

• For frames other than write DATA frames, the SSP initiator port shall set the TARGET PORT TRANSFER TAG field to FFFFh.

Test Setup: The DUT and the Testing Station are physically connected. The SAS Initiator DUT is attached to the SAS Target through a SAS Protocol analyzer.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator, the Testing Station is instructed to transmit an Identify Address frame indicating that it is a target.

2. Allow the DUT to open a connection to the Testing Station and transmit a WRITE command. The Testing Station is instructed to transmit XFER_RDY in response, with a Target Port Transfer Tag of 5555h.

Observable Results: If the DUT is an initiator, verify that the TARGET PORT TRANSFER TAG field is the same in all DATA frames as the TARGET PORT TRANSFER TAG offered by the Testing Station in the XFER_RDY frame. Possible Problems: None



Test 8.2.6 - SSP DATA IU – TPT TAG FIRST BURST DATA Purpose: To determine that the DUT, a SAS Initiator, properly sets the TARGET PORT TRANSFER TAG field when sending First Burst Data. References:

[1] 8.2.1 SAS SPL [2] 8.2.2.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. The DUT will need to have software capable of generating SCSI traffic. Last Modification: August 8, 2011 Discussion: SSP initiator ports shall set the TARGET PORT TRANSFER TAG field as follows:


• For each write DATA frame that is sent containing first burst data (see 8.2.2.4), the SSP initiator port shall set the TARGET PORT TRANSFER TAG field to FFFFh; and

• For frames other than write DATA frames, the SSP initiator port shall set the TARGET PORT TRANSFER TAG field to FFFFh


Test Procedure:

1. Allow the DUT to open a connection to the attached SAS target and transmit a WRITE command with First Burst data. The Testing Station is instructed to transmit XFER_RDY in response.

Observable Results: Verify that the TARGET PORT TRANSFER TAG field is set to FFFFh in all First Burst DATA frames sent by the DUT. Possible Problems: None



Test 8.2.7 - SSP DATA IU – TPT TAG NON-DATA Purpose: To determine that the DUT, a SAS Initiator, properly sets the TARGET PORT TRANSFER TAG field when sending frames other than DATA frames. References:

[1] 8.2.1 SAS SPL [2] 8.2.2.4 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. The DUT will need to have software capable of generating SCSI traffic. Last Modification: August 8, 2011 Discussion: SSP initiator ports shall set the TARGET PORT TRANSFER TAG field as follows:


• For each write DATA frame that is sent containing first burst data [2], the SSP initiator port shall set the TARGET PORT TRANSFER TAG field to FFFFh; and

• For frames other than write DATA frames, the SSP initiator port shall set the TARGET PORT TRANSFER TAG field to FFFFh


Test Procedure:

1. Allow the DUT to open a connection to the attached SAS Target and transmit a READ command.

Observable Results: Verify that the TARGET PORT TRANSFER TAG field is set to FFFFh in all non-DATA frames sent by the DUT. Possible Problems: None



Test 8.2.8 - SSP RESPONSE IU – DATAPRES RESERVED Purpose: To determine that the DUT, an SSP Initiator, properly handles a response frame received with a reserved value in the DATA PRES field. References:

[1] 6.17.8.7 SAS SPL [2] 8.2.2.5.1 SAS SPL [3] Table 126 SAS SPL [4] 8.2.1 SAS SPL [5] 8.2.4.2 SAS SPL

Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: [3] defines the response IU. The RESPONSE frame is sent by an SSP target port to deliver SCSI status (e.g., GOOD or CHECK CONDITION) and sense data, or to deliver SSP-specific status (e.g., illegal frame format). The maximum size of the RESPONSE frame is the maximum size of any IU in an SSP frame [4]. If the DATAPRES field is set to a reserved value, then the SSP initiator port shall discard the RESPONSE frame. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator The Testing Station is instructed to transmit an Identify Address frame indicating that it is a target.

2. Allow the DUT to open a connection to the Testing Station and transmit an INQUIRY command. Close the connection.

3. The Testing Station is instructed to transmit DATA and RESPONSE to the command from the DUT. The Testing Station is instructed to set the DATAPRES field in the Response frame to 11b, a reserved value.

Observable Results: Verify that the DUT discards the response frame that is received with a reserved value in the DATAPRES field. The DUT should ACK this frame. The DUT should retry the INQUIRY command. Possible Problems: To determine whether the DUT has discarded the received RESPONSE frame, it is first necessary to perform the test with a valid INQUIRY RESPONSE with a valid DATAPRES field. This way the DUTs ‘normal’ behavior can be observed. It is important to note the number of times the DUT transmits each command, to what LUNs the command is transmitted to, and what type of INQUIRY data is requested. After this information is know the test can be performed with the incorrect value in the DATAPRES field and it can be determined properly whether the DUT retried the command or not.



Test 8.2.9 - SSP ERROR HANDLING – EXTRA RESPONSE FRAME RECEIVED Purpose: To determine that the DUT, an SSP Initiator port, responds properly when a RESPONSE frame is improperly retransmitted. References:


Resource Requirements: SAS Protocol Analyzer and Generator. Last Modification: August 8, 2011 Discussion: If an SSP initiator port receives a RESPONSE frame with a RETRANSMIT bit set to one, and it has previously received a RESPONSE frame for the same I_T_L_Q nexus, the ST_TFR state machine discards the extra RESPONSE frame [2]. If the ST_TFR state machine and the ST_TTS state machine have not previously received the RESPONSE frame, they consider the RESPONSE frame to be the valid RESPONSE frame. Test Setup: The DUT and the Testing Station are physically connected.

Test Procedure:

1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify sequence with the DUT. Since the DUT is an initiator The Testing Station is instructed to transmit an Identify Address frame indicating that it is a SAS Target.

2. Allow the DUT to open an SSP connection to the Testing Station and transmit a SCSI INQUIRY command.

3. The Testing Station is instructed to open a connection to the DUT and transmit DATA and 2 RESPONSE frames to the DUT. The second response frame should have the retransmit bit set to close the connection.

Observable Results: Verify that the DUT discards the response frame that is received with retransmit bit set. The DUT should ACK this frame. When discarding the frame the DUT not retry or transmit a TASK MANAGEMENT function. Possible Problems: To determine whether the DUT has discarded the received RESPONSE frame, it is first necessary to perform the test with a single valid INQUIRY RESPONSE with the retransmit bit set to 0. This way the DUTs ‘normal’ behavior can be observed. It is important to note the number of times the DUT transmits each command, to what LUNs the command is transmitted to, and what type of INQUIRY data is requested. After this information is know the test can be performed with 2 RESPONSE frames, one with the Retransmit bit set. It can then be determined whether the DUT performed properly or not.


SERIAL ATTACHED SCSI(SAS) CONSORTIUM

Clause 10SAS Application Layer Test Suite

Version 1.02

Technical Document

Last Updated: 2 April 2012 4/2/12

Serial Attached SCSI Consortium 121 Technology Drive, Suite 2InterOperability Laboratory Durham, NH 03824University of New Hampshire Phone: (603) 862-0090




The University of New HampshireInterOperability Laboratory TABLE OF CONTENTS

TABLE OF CONTENTS.......................................................................................2MODIFICATION RECORD..................................................................................3ACKNOWLEDGMENTS.......................................................................................4INTRODUCTION...................................................................................................5REFERENCES........................................................................................................7GROUP 1: APPLICATION LAYER TESTS FOR TARGETS...........................8

TEST 10.1.1 - SCSI CDB – TEST UNIT READY.......................................................................9TEST 10.1.2 - SCSI CDB – INQUIRY.......................................................................................10TEST 10.1.3 - SCSI CDB – START STOP.................................................................................11TEST 10.1.4 - SCSI CDB – MODE SENSE..............................................................................12TEST 10.1.5 - SCSI CDB – MODE SELECT............................................................................13TEST 10.1.6 - SCSI CDB – READ CAPACITY........................................................................14TEST 10.1.7 - SCSI CDB – WRITE...........................................................................................15TEST 10.1.8 - SCSI CDB – READ.............................................................................................16TEST 10.1.9 - SCSI CDB – LOG SENSE..................................................................................17

GROUP 2: APPLICATION LAYER TESTS FOR EXPANDERS...................18TEST 10.2.1 - STP OPERATIONS – IDENTIFY DEVICE.......................................................19TEST 10.2.2 - STP OPERATIONS – SET FEATURES.............................................................20TEST 10.2.3 - STP OPERATIONS – IDLE................................................................................21TEST 10.2.4 - STP OPERATIONS – SET MULTIPLE MODE.................................................22TEST 10.2.5 - STP OPERATIONS – WRITE SECTORS..........................................................23TEST 10.2.6 - STP OPERATIONS – READ SECTORS...........................................................24TEST 10.2.7 - STP OPERATIONS – WRITE MULTIPLE........................................................25TEST 10.2.8 - STP OPERATIONS – READ MULTIPLE..........................................................26TEST 10.2.9 - STP OPERATIONS – WRITE DMA..................................................................27TEST 10.2.10 - STP OPERATIONS – READ DMA..................................................................28

Serial Attached SCSI Consortium Group 2 Clause 10 SAS Application Layer Test Suite v1.01

The University of New HampshireInterOperability Laboratory

MODIFICATION RECORD

[1]September 7, 2004 (Version 0.1) DRAFT RELEASE David Woolf: Initial draft release

[2]April 14, 2005 (Version 0.12) DRAFT RELEASE David Woolf: added STP Operations tests

[3]July 11, 2005 (Version 0.13) DRAFT RELEASE David Woolf: minor edits

[4]September 18, 2005 (Version 0.14) DRAFT RELEASE Leon Cyril: minor edits

[5]October 9, 2005 (Version 1.0) DRAFT RELEASE Leon Cyril: added discussion for all tests.

[6]August 15, 2005 (Version 1.01) DRAFT RELEASE Michael Davidson: Removed Research Computing Center References

[7]March 30, 2012 (Version 1.02) DRAFT RELEASE David Woolf: Added to Possible Problems section in test 10.1.5

Serial Attached SCSI Consortium 3 Clause 10 SAS Application Layer Test Suite v1.02

The University of New HampshireInterOperability LaboratoryACKNOWLEDGMENTS

The University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite.

Kurtis Kofler UNH InterOperability Laboratory (UNH-IOL)David Woolf UNH InterOperability Laboratory (UNH-IOL)Leon Cyril UNH InterOperability Laboratory (UNH-IOL)



INTRODUCTION

The University of New Hampshire’s InterOperability Laboratory (IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. This particular suite of tests has been developed in junction with CATC to help implementers evaluate the functionality of their Serial Attached SCSI (SAS) products. Specifically this Test Suite is directed at verifying the Link layer of SAS Targets, Initiators, and Expanders.

These tests are designed to determine if a SAS product conforms to specifications defined in ISO/IEC 14776-150, Serial Attached SCSI (SAS) standard T10/1562-D, Revision 5 (hereafter referred to as the “SAS Standard”). Successful completion of all tests contained in this suite does not guarantee that the tested device will successfully operate with other SAS products. However, when combined with satisfactory operation in the IOL’s interoperability test bed, these tests provide a reasonable level of confidence that the Device Under Test (DUT) will function properly in many SAS environments.

The tests contained in this document are organized in order to simplify the identification of information related to a test, and to facilitate in the actual testing process. Tests are separated into groups, primarily in order to reduce setup time in the lab environment, however the different groups typically also tend to focus on specific aspects of device functionality. A three-number, dot-notated naming system is used to catalog the tests, where the first number always indicates the specific clause of the reference standard on which the test suite is based. The second and third numbers indicate the test’s group number and test number within that group, respectively. This format allows for the addition of future tests in the appropriate groups without requiring the renumbering of the subsequent tests.

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:

PurposeThe purpose is a brief statement outlining what the test attempts to achieve. The test is

written at the functional level.

ReferencesThis 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 RequirementsThe 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.

Last ModificationThis specifies the date of the last modification to this test.

Test SetupThe 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 (next).

ProcedureThe 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.

Observable ResultsThis 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.

Possible ProblemsThis 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.



REFERENCES

The following document is referenced in this text:

[1] T10/Project 1601-DT/Rev 8 – Serial Attached SCSI 1.1 – (SAS – 1.1)[2] T10/Project 1416-D/Rev 23 – SCSI Primary Commands 3 – (SPC – 3)[3] T10/Project 1417-D/Rev 16 – SCSI Block Commands 2 – (SBC – 2)



GROUP 1: APPLICATION LAYER TESTS FOR TARGETS

Overview:This group of tests verifies the specifications of the SCSI and ATA protocols used over SAS defined in SPC3, SBC2, and ATA/ATAPI 5/6, for targets.



Test 10.1.1 - SCSI CDB – TEST UNIT READY

Purpose: To determine that the DUT, an SSP Target port, properly handles a Test Unit Ready command.

References: [1] SCSI Primary Commands-3 6.33[2] SCSI Primary Commands-3 Table 184

Resource Requirements: SAS Protocol Analyzer and Generator.

Last Modification: September 28, 2005

Discussion: The TEST UNIT READY command [2] provides a means to check if the logical unit is ready. This is not a request for a self-test. If the logical unit is able to accept an appropriate medium-access command without returning CHECK CONDITION status, this command shall return a GOOD status. If the logical unit is unable to become operational or is in a state such that an application client action (e.g., START UNIT command) is required to make the logical unit ready, the command shall be terminated with CHECK CONDITION status, with the sense key set to NOT READY.


Test Procedure:1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify


2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI TEST UNIT READY command to the DUT. Close the connection

3. Allow the DUT to open an SSP connection and transmit a SCSI RESPONSE frame to the received command.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command completed with GOOD status.




Test 10.1.2 - SCSI CDB – INQUIRY

Purpose: To determine that the DUT, an SSP Target port, properly handles an INQUIRY command.

References: [1] 6.4 SCSI Primary Commands-3[2] Table 80 SCSI Primary Commands-3[3] 6.4.2 SCSI Primary Commands-3



Discussion: The INQUIRY command [2] requests that information regarding the logical unit and SCSI target device be sent to the application client. In response to an INQUIRY command received by an incorrect logical unit, the SCSI target device shall return the INQUIRY data with the peripheral qualifier set to the value defined in [3]. The INQUIRY command shall return CHECK CONDITION status only when the device server is unable to return the requested INQUIRY data.




2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI INQUIRY command to the DUT with the EVPD and PAGE CODE fields set to zero. Close the connection

3. Allow the DUT to open an SSP connection and transmit DATA, containing standard INQUIRY data, and RESPONSE frames to the received command.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command is completed with GOOD status. Verify that the INQUIRY DATA is consistent with the device type and is formatted according to [2]




Test 10.1.3 - SCSI CDB – START STOP

Purpose: To determine that the DUT, an SSP Target port, properly handles a START STOP command.

References: [1] 5.19 SCSI Block Commands-2[2] Table 48 SCSI Block Commands-2[3] 4.15 SCSI Block Commands-2



Discussion: The START STOP UNIT command [2] requests that the device server change the power condition of the logical unit [3] or load or eject the medium. This includes specifying that the device server enable or disable the direct-access block device for medium access operations by controlling power conditions and timers.




2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI START STOP command to the DUT. Close the connection

3. Allow the DUT to open an SSP connection and transmit a RESPONSE frame to the received command.





Test 10.1.4 - SCSI CDB – MODE SENSE

Purpose: To determine that the DUT, an SSP Target port, properly handles a MODE SENSE command.

References: [1] SPC-3 6.9 SCSI Primary Commands-3[2] 7.4.2 SCSI Primary Commands-3[3] Table 246 SCSI Primary Commands-3[4] Table 97 SCSI Primary Commands-3



Discussion: The MODE SENSE(6) command [4] provides a means for a device server to report parameters to an application client. It is a complementary command to the MODE SELECT(6) command. Device servers that implement the MODE SENSE(6) command shall also implement the MODE SELECT(6) command. An application client may request any one or all of the supported mode pages from the device server. If an application client issues a MODE SENSE command with a page code or subpage code value not implemented by the logical unit, the command shall be terminated with CHECK CONDITION status, with the sense key set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN CDB.




2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI MODE SENSE(6) command to the DUT with the PAGE CODE field set 02h and the SUBPAGE CODE set to 00h. This will request the Disconnect-Reconnect Mode Page. Close the connection

3. Allow the DUT to open an SSP connection and transmit DATA, containing standard Disconnect Reconnect Mode Parameters, and RESPONSE frames to the received command.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command completed with GOOD status. Verify that the Mode Parameters returned by the DUT are formatted according to [3] of SPC-3.




Test 10.1.5 - SCSI CDB – MODE SELECT

Purpose: To determine that the DUT, an SSP Target port, properly handles a MODE SELECT command.

References: [1] 3 6.7 SCSI Primary Commands-3[2] Table 94 SCSI Primary Commands-3


Last Modification: March 30, 2012

Discussion: The MODE SELECT(6) command [2] provides a means for the application client to specify medium, logical unit, or peripheral device parameters to the device server. Device servers that implement the MODE SELECT(6) command shall also implement the MODE SENSE(6) command. Application clients should issue MODE SENSE(6) prior to each MODE SELECT(6) to determine supported mode pages, page lengths, and other parameters.

Test Setup: The DUT and the Testing Station are physically connected. The DUT is not powered on .

Test Procedure:1. Power on the DUT.2. The Testing Station is instructed to start and complete a phy Reset sequence followed by an Identify


3. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI MODE SENSE(6) command to the DUT with the PAGE CODE field set 02h and the SUBPAGE CODE set to 00h. This will request the Disconnect-Reconnect Mode Page. Close the connection

4. Allow the DUT to open an SSP connection and transmit DATA, containing standard Disconnect Reconnect Mode Parameters, and RESPONSE frames to the received command.

5. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI MODE SELECT(6) command to the DUT with the PF bit set to 1, the SP bit set to 1. Close the connection.

6. Allow the DUT to open an SSP connection to transmit an XFER_RDY frame. 7. The Testing Station is instructed to open an SSP connection to the DUT and transmit a DATA frame to

the DUT containing Mode Parameters for the Disconnect Reconnect Mode Page with a new Maximum Burst Size. Close the connection.

8. Allow the DUT to open an SSP connection to transmit a RESPONSE frame.


Possible Problems: Some DUTs may have a default Maximum Burst Size value that cannot be changed. In this case, the Testing Station should use the MODE SENSE command to determine the changeable values on the DUT for Mode Page 2 and then repeat step 7, sending a DATA frame to the DUT containing Mode Parameters for the Disconnect Reconnect Mode Page with a new value for any one of the changeable Mode Parameter values.



Test 10.1.6 - SCSI CDB – READ CAPACITY

Purpose: To determine that the DUT, an SSP Target port, properly handles a READ CAPACITY command.

References: [1] 5.12 SCSI Block Commands-2[2] Table 34 SCSI Block Commands-2[3] Table 36 SCSI Block Commands-2[4] 4.11 SCSI Block Commands-2[5] 4.16 SCSI Block Commands-2



Discussion: The READ CAPACITY (10) command [2] requests that the device server transfer 8 bytes ofparameter data describing the capacity and medium format of the direct-access block device to the data-in buffer. This command may be processed as if it has a HEAD OF QUEUE task attribute [4]. If the logical unit supports protection information [5], the application client should use the READ CAPACITY (16) command instead of the READ CAPACITY (10) command.




2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI READ CAPACITY(10) command to the DUT with the PMI bit set to 0. Close the connection

3. Allow the DUT to open an SSP connection and transmit DATA and RESPONSE frames to the received command.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command completed with GOOD status. Verify that the DATA returned by the DUT are formatted according to table 36 of SBC-2.




Test 10.1.7 - SCSI CDB – WRITE

Purpose: To determine that the DUT, an SSP Target port, properly handles a WRITE (10) command.

References: [1] 5.27 SCSI Block Commands-2[2] Table 62 SCSI Block Commands-2



Discussion: The WRITE (10) command [2] requests that the device server transfer the specified logical block(s) from the data-out buffer and write them. Each logical block transferred includes user data and may include protection information, based on the WRPROTECT field and the medium format. Each logical block written includes user data and, if the medium is formatted with protection information enabled, protection information.





3. Allow the DUT to open an SSP connection to the Testing Station and transmit XFER_RDY. 4. The Testing Station is instructed to open a connection to the DUT and transmit 4 512 byte DATA

frames. Close the connection. 5. Allow the DUT to open an SSP connection and transmit a SCSI RESPONSE frame to the received

command and data.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command completed with GOOD status. Verify that the DUT transmitted ACK for every received DATA frame.




Test 10.1.8 - SCSI CDB – READ

Purpose: To determine that the DUT, an SSP Target port, properly handles a READ(10) command.

References: [1] 5.8 SCSI Block Commands-2[2] Table 28 SCSI Block Commands-2



Discussion: The READ (10) command [2] requests that the device server read the specified logical block(s) and transfer them to the data-in buffer. Each logical block read includes user data and, if the medium is formatted with protection information enabled, protection information. Each logical block transferred includes user data and may include protection information, based on the RDPROTECT field and the medium format. The most recent data value written in the addressed logical block shall be returned.




2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI READ command for 2048 bytes. Close the connection

3. The DUT should open a connection to the Testing Station and transmit 4 512 byte DATA frames. The Testing Station is instructed to transmit ACK for each received frame.

4. Allow the DUT to open an SSP connection and transmit a SCSI RESPONSE frame to the received command.





Test 10.1.9 - SCSI CDB – LOG SENSE

Purpose: To determine that the DUT, an SSP Target port, properly handles a LOG SENSE command.

References: [1] 6.6 SCSI Primary Commands-3[2] Table 93 SCSI Primary Commands-3[3] 7.2.12 SCSI Primary Commands-3[4] Table 194 SCSI Primary Commands-3



Discussion: The LOG SENSE command [2] provides a means for the application client to retrieve statistical or other operational information maintained by the SCSI target device about the SCSI target device or its logical units. It is a complementary command to the LOG SELECT command.




2. The Testing Station is instructed to open an SSP connection to the DUT and transmit a SCSI LOG SENSE command with the PPC and PARAMETER POINTER fields set to 0, a LOG PAGE CODE of 00h (Supported Log Pages), and SP bit of 0. Close the connection

3. The DUT should open a connection to the Testing Station and transmit DATA frames to the DUT. 4. Allow the DUT to open an SSP connection and transmit a SCSI RESPONSE frame to the received

command.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command completed with GOOD status. Verify that the DUT transmitted Log Page data formatted according to [3]. Verify that the DUT reported its supported Log Pages defined in [4].




GROUP 2: APPLICATION LAYER TESTS FOR EXPANDERS

Overview:This group of tests verifies the specifications of the SCSI and ATA protocols used over SAS defined in SPC3, SBC2, and ATA/ATAPI 5/6 for expanders.



Test 10.2.1 - STP OPERATIONS – IDENTIFY DEVICE

Purpose: To determine that the DUT, an STP Bridge port, properly handles an IDENTIFY DEVICE request.

References: [1] 8.15 AT Attachment with Packet Interface-5/6 [2] Table 27 AT Attachment with Packet Interface-5/6



Discussion: The IDENTIFY DEVICE command enables the host to receive parameter information from the device.Some devices may have to read the media in order to complete this command. When the command is issued, the device sets the BSY bit to one, prepares to transfer the 256 words of device identification data to the host, sets the DRQ bit to one, clears the BSY bit to zero, and asserts INTRQ if nIENis cleared to zero. The host may then transfer the data by reading the Data register. Table 27 defines the arrangement and meaning of the parameter words in the buffer. All reserved bits or words shall be zero.

Test Setup: The DUT and the Testing Station are physically connected. The DUT is also connected to a SATA disk drive.

Test Procedure:1. The Testing Station is instructed to start and complete a phy Reset sequence followed by an

Identify sequence with the DUT. Since the DUT is an expander with an attached target The Testing Station is instructed to transmit an Identify Address frame indicating that it is an initiator.


3. The Testing Station is instructed to open an SMP Connection to the DUT and transmit a REPORT STA PHY SMP Request to the DUT phy which is attached to the SAS Target. The DUT should transmit a REPORT SATA PHY SMP Response with this information.

4. The Testing Station is instructed to transmit an OpenAddress frame for an STP Connection to the STP Target on the DUT. The Testing Station is instructed to wait for OPEN_ACCEPT.

5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code IDENTIFY DEVICE.

Observable Results: Verify that the DUT transmits RESPONSE frame indicating that the command completed.




Test 10.2.2 - STP OPERATIONS – SET FEATURES

Purpose: To determine that the DUT, an STP Bridge port, properly handles a SET FEATURES request.

References:[1] 8.46 AT Attachment with Packet Interface-5/6 [2] Table 44 AT Attachment with Packet Interface-5/6



Discussion: This command is used by the host to establish parameters that affect the execution of certain device features. Table 44 defines these features. At power-on, or after a hardware reset, the default settings of the functions specified by the subcommands are vendor specific.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code SET FEATURES.





Test 10.2.3 - STP OPERATIONS – IDLE

Purpose: To determine that the DUT, an STP Bridge port, properly handles an IDLE request.

References: [1] 8.17 AT Attachment with Packet Interface-5/6 [2] 6.11 AT Attachment with Packet Interface-5/6



Discussion: The IDLE command allows the host to place the device in the Idle mode and also set the Standby timer. INTRQ may be asserted even though the device may not have fully transitioned to Idle mode. If the Sector Count register is non-zero then the Standby timer shall be enabled. The value in the Sector Count register shall be used to determine the time programmed into the Standby timer [2]. If the Sector Count register is zero then the Standby timer is disabled.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code IDLE.





Test 10.2.4 - STP OPERATIONS – SET MULTIPLE MODE

Purpose: To determine that the DUT, an STP Bridge port, properly handles a SET MULTIPLE MODE request.

References:[1] 8.49 AT Attachment with Packet Interface-5/6



Discussion: This command establishes the block count for READ MULTIPLE, READ MULTIPLE EXT, WRITE MULTIPLE, and WRITE MULTIPLE EXT commands. Devices shall support the block size specified in the IDENTIFY DEVICE parameter word 47, bits (7:0), and may also support smaller values. Upon receipt of the command, the device checks the Sector Count register. If the content of the Sector Count register is not zero, the Sector Count register contains a valid value, and the block count is supported, then the value in the Sector Count register is used for all subsequent READ MULTIPLE, READ MULTIPLE EXT, WRITE MULTIPLE, and WRITE MULTIPLE EXT commands and their execution is enabled.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code SET MULTIPLE MODE.





Test 10.2.5 - STP OPERATIONS – WRITE SECTORS

Purpose: To determine that the DUT, an STP Bridge port, properly handles a WRITE SECTORS request.

References: [1] 8.5 AT Attachment with Packet Interface-5/6



Discussion: This command writes from 1 to 256 sectors as specified in the Sector Count register. A sector count of 0 requests 256 sectors. The device shall interrupt for each DRQ block transferred.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code WRITE SECTORS.





Test 10.2.6 - STP OPERATIONS – READ SECTORS

Purpose: To determine that the DUT, an STP Bridge port, properly handles a READ SECTORS request.




Discussion: This command reads from 1 to 256 sectors as specified in the Sector Count register. A sector count of 0 requests 256 sectors. The transfer shall begin at the sector specified in the LBA Low, LBA Mid, LBA High, and Device registers. The DRQ bit is always set to one prior to data transfer regardless of the presence or absence of an error condition. The device shall interrupt for each DRQ block transferred.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code READ SECTORS.





Test 10.2.7 - STP OPERATIONS – WRITE MULTIPLE

Purpose: To determine that the DUT, an STP Bridge port, properly handles a WRITE MULTIPLE request.




Discussion: This command writes the number of sectors specified in the Sector Count register. The number of sectors per block is defined by the content of word 59 of the IDENTIFY DEVICE response. When the WRITE MULTIPLE command is issued, the Sector Count register contains the number of sectors (not the number of blocks) requested. The device shall interrupt for each DRQ block transferred.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code WRITE MULTIPLE.





Test 10.2.8 - STP OPERATIONS – READ MULTIPLE

Purpose: To determine that the DUT, an STP Bridge port, properly handles a READ MULTIPLE request.




Discussion: This command reads the number of sectors specified in the Sector Count register. The number of sectors per block is defined by the content of word 59 in the IDENTIFY DEVICE response. When the READ MULTIPLE command is issued, the Sector Count register contains the number of sectors (not the number of blocks) requested. The device shall interrupt for each DRQ block transferred.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code READ MULTIPLE.





Test 10.2.9 - STP OPERATIONS – WRITE DMA

Purpose: To determine that the DUT, an STP Bridge port, properly handles a WRITE DMA request.




Discussion: The WRITE DMA command allows the host to write data using the DMA data transfer protocol.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code WRITE DMA.





Test 10.2.10 - STP OPERATIONS – READ DMA

Purpose: To determine that the DUT, an STP Bridge port, properly handles a READ DMA request.




Discussion: The READ DMA command allows the host to read data using the DMA data transfer protocol.







5. The Testing Station is instructed to transmit a SATA FIS of type Register Host to Device with Command Code READ DMA.




Teledyne LeCroy NACA-test

NACA Test 1 Test Procedure Note: Connect Port 1 and Port 2 of the DUT to the testing station.

1. The software runs the Identify project to acquire the SAS Address of the DUT. Note: Do this step only once when you begin running SAS Verification. Do not repeat for each test.

2. The software runs the Dummy project to clear unit attention. Note: Do this step only once when you begin running SAS Verification. Do not repeat for each test.

3. The software runs the DetectSupportReadCommands.sac project to determine which Read command is supported by the DUT. It issues all possible Read commands and chooses the one to which the DUT responds accurately and successfully. After this step, use the command, for example Read-10, to send data to the DUT.

4. The software runs the DummyForTwoPorts project only for the NACA test. This project links Port 1 and Port 2 and makes them ready. It also issues the Mode Sense command to acquire the Mode page parameters, such as TST bit.

5. The software runs the NACA_01_Read10 project. It sends some commands to fill the Queue command and activates ACA by sending a Read command with NACA bit = 1. After ACA activation, it issues a command to be sure that ACA has been activated, so that the command status is ACA ACTIVATE. A few more commands are sent - expect the DUT to

abort those. All these tasks are run on Port 1. 6. The software runs the NACA_02_Read10 project to send Read commands to Port 2 of the DUT. Expect to see correct behavior from the DUT regarding its TST condition. If TST is set (TST =1), expect the DUT to accept the Read commands. Otherwise, it should abort the commands.

7. The software runs the NACA_03_Read10 project to clear the ACA and issue some Read commands to Port 1. Expect the DUT to accept the commands and respond successfully.

8. If you now have N/A or failed results, the software runs the Clear_ACA_ForTwoPorts project to clear the ACA.

186

Documents

SAS Verification Test Descriptionscdn.teledynelecroy.com/files/manuals/sas_verification_test_descriptions_v5.70.pdfProtocol Solutions Group . 3385 Scott Blvd., Santa Clara, CA 95054