Specifications

SATA-IO Confidential 11
1.3. Methods of Implementation
A Method of Implementation (MOI) is defined as documentation specifying test tool details and procedures for the
specific use of verifying the different Interoperability test areas. In the future a template for development of a MOI for
a specific test tool may be developed, but at this time a MOI, at a minimum, must simply include the following:
• Hardware equipment model number(s)
• Software revision number(s)
• Hardware dependencies (e.g. test fixtures)
• Product dependencies (e.g. BIST modes, patterns)
• Detailed procedures for using the equipment to verify the specific Interop test requirements
• Procedures for extraction of results
• Approximate execution time of specific Interop test requirements
There are different MOI classes which are specific to the different test areas included in this Unified Test Document.
Any test tool approved for use in Interoperability Testing must fall under test execution within one of the following MOI
classes:
• Digital/protocol (device/host or port multiplier only)
• Phy electrical (device/host only)
• Phy TX/RX requirements (device/host only)
• RSG requirements (device/host or eSATA only)
• Receiver Jitter Tolerance (device/host only)
• Mechanical (device/host or eSATA only)
• Cable mechanical (internal or eSATA cable only)
• Cable electrical (internal or eSATA cable only)
• System interoperability (device/host only)
It is feasible that separate MOIs are developed for each type of equipment used depending on the class of testing, or
that a single MOI is used to cover an entire test class including the details for several pieces of test tool equipment.
This will be determined by the appropriate test tool vendors with considerations from the SATA-IO.
1.4. Test Product Considerations
1.4.1. Common Host/Device/Port Multiplier BIST Considerations
For many of the Phy electrical tests, it is required that a product (Host/Device/Port Multiplier and eSATA versions of
these) is able to transmit and/or loop back patterns which are identified within the SATA 2.6 specification or this
document. There are standard ways of doing this through the BIST protocol per definition within the specification. If a
product does not specifically support either BIST T, A, S, and/or BIST L capabilities then the vendor needs to bring all
equipment to support vendor unique methods for completely emulating BIST “T,A,S” and BIST “L”. Note that this
vendor unique process can have no substantial impact to the test during interoperability testing (e.g. significant growth
in test execution time or complexity of equipment calibration/setup).
1.4.2. Device specific considerations
A device vendor is required to supply at least three samples. In some cases up to two samples will be run through
testing in parallel at a given time. The third sample could be available for backup in case of unexpected errors or
failures.
1.4.3. Cable Considerations
If a cable assembly product family consists of cables which differ only in their length (the connector design, cable
construction, and assembly method is identical) and if the shortest and longest lengths pass the test requirements
then all intermediate lengths are considered to be passing.
A cable vendor is required to supply at least two identical samples of each length tested.