OCP_2_6_Group_2

DSSD_26_Admin_Command_Execution_Time_Verification_Test_Case.py

Admin Command Execution Time Verification Test Case:

For Standard Duration Admin Commands, the CTO test objectives are to verify that each validly formatted admin command completed successfully within 10 seconds under the following scenarios:

1. Admin commands issued sequentially,

2. Admin commands issued in the presence of a stressing background I/O workload.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

CTO-1/2/3/6/8/11

DSSD_26_Arbitration_Test_Case.py

Arbitration Test Case

The objectives of this test case are as follows:

1. Verify that the device’s default arbitration is Round-Robin by reading CC.AMS.

2. Verify that the device supports Weighted round robin with urgent class priority by reading CAP.AMS.

3. Verify that the arbitration can be changed to Weighted Round Robin by changing CC.AMS field.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-CFG-1

DSSD_26_Basic_Command_And_Data_Verification_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID 2h with different NSIDs

2. Check various field values

3. Do controller reset and repeat steps 1-2

4. Do FLR and repeat steps 1-2

5. Do NSSR and repeat steps 1-2

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.0 requirements referenced by this script:

STD-LOG-2/3/18/23, SLOG-1/3/4/5/11

DSSD_26_Basic_Data_Persistence_Test_Case.py

Basic Data Persistence Test Case

The purpose of this test case is to verify the following:

1. That the SMART/Health Information Extended Log (C0h) log page is returned, and the command completes with status success,

2. That all static attribute values in the C0h Log page persist across power cycles, resets, Sanitize, FormatNVM and TCG GenKey/RevertSP, and Revert operations, (Need to add error modes with EI),

3. That the limited subset of the dynamically updated attribute values that are highly unlikely to change in the absence of specific HW events persist across power cycles, resets, Sanitize, Format NVM and TCG GenKey/RevertSP, and Revert operations, (Need to add error modes with EI),

4. That the thermal throttling status is 0 reflecting not throttled.

5. That the capacitor health is greater than 1, and less than 0xFFFF.

6. That the value in all the reserved fields is 0.

7. That the NVMe Command Set Errata Version and Lowest Permitted Firmware Revision match the values in Adaptation data.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-35

steps_1_to_11(dut)

Perform repeated steps for Test Steps 1-11

DSSD_26_Basic_IEEE1667_Verification_Test_Case.py

Basic IEEE1667 Verification Test Case For Security TCG the test objectives are to verify the following:

1. For models that support eDrive, the IEEE 1667 Probe (0x100) and TCG Storage Transport (0x104) silos shall be supported.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SEC-13

DSSD_26_Basic_Namespace_Data_Verification_Test_Case.py

This script will run the following tests:

1. That new drives come from the factory configured with exactly one active namespace sized to the maximum capacity of the device.

2. That the FLBAS for this namespace corresponds to the default set at the factory and as specified per the device profile contained in the device Adaptation data.

3. That for a valid namespace, the namespace data returned from the Identify command exactly matches the namespace data as provided in the Adaptation data for the drive.

4. That the values of NN and MNAN reported in the Identify Controller Dataset are set correctly per the device profile setting in the Adaptation data.

5. That support for the NSWG and NAWUPF field is indicated in the NSFEAT field in adaptation data.

6. That the NSWG and NAWUPF field in Namespace data is populated and, that the value matches the indirection unit value in Adaptation data.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NSM-4/5/6, NVMe-OPT-7/15, SECTOR-3

DSSD_26_Basic_Security_TCG_Verification_Test_Case.py

Basic Security TCG Verification Test Case

For Security TCG the test objectives are to verify the following:

1. That the DUT supports TCG Opal 2.01 with support for:

   1. Opal SSC,

   2. Locking feature,

   3. Additional Datastore Tables feature.

2. That the DUT supports Single User Mode feature set v1.0 rev1.0.

3. That the DUT supports Configurable Namespace Locking feature set v1.0 rev1.0.

4. That with the DUT starting in OFS:

   1. The initial DUT TCG state can be validated,

   2. The DUT can then be activated and TCG state validated,

   3. The DUT can then be secured and TCG state validated,

   4. The DUT can then be deprovisioned and TCG state validated,

   5. The DUT can then be deactivated and TCG state validated.

5. For eDrive support, the DUT supports IEEE 1667 Silo

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

SEC-10 SEC-11 SEC-12 SEC-38 TCG-LOCKING-2

DSSD_26_Basic_Verification_Of_Asynchronous_Event_Requests_Test_Case.py

The objectives for the Basic Verification of Asynchronous Event Requests Test Case are as follows:

a.) Verify that the value of bit-3 in the LPA field is set to 1b, indicating the support for sending

Telemetry Log Notices.

b.) Verify that the value of bit-8 in the OAES field shall be set to 1b, indicating the support for

Namespace Attribute Notices event and the associated Changed Namespace List log page.

c.) Verify that the value of bit-9 in the OAES field shall be set to 1b, indicating the support for the

Firmware Activation Notices event.

d.) Verify that when attempting to an NVMe Asynchronous Event Request command when there are

already AERL+1 Asynchronous Event Request commands pending, the latest Asynchronous Event Request command shall fail because the number of outstanding Asynchronous Event Request commands has been exceeded.

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-OPT-8/9/10/11, NVMe-AD-24/25

DSSD_26_Boot_Requirements_Test_Case.py

This script will run the following tests:

1. Verify that the Expansion ROM Base Address contains a value of 0 indicating that an Option ROM is not included

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

BOOT-2

DSSD_26_Clear_FW_Update_History_Test_Case.py

This script will run the following tests:

1. Determine the current and alternate firmware slots

2. Clear the FW Update History log and verify it was cleared

3. Download the previous firmware image

4. Alternate committing the previous and current firmware images multiple times

5. Verify Valid Firmware Activation History Entries count is correct

6. Clear the FW Update History log and verify it was cleared

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

CFUH-1 to CFUH-15, GETF-2

DSSD_26_Clear_PCIe_Correctable_Error_Counters_Test_Case.py

Clear PCIe Correctable Error Counters Test Case

The objective of this test case is to clear the PCIe correctable error counters using set feature C3h and to verify this by reading “PCIe Correctable Error Count” in Log Page C0h.

1. Use Set feature C3h to clear PCIe correctable error counters. After this “PCIe Correctable Error Count” in Log Page C0h should be zero, this value will be zero even through power cycles. cycles and will only change to non-zero value when drive encounters any PCIe correctable errors.

2. If setting this feature is not supported, then a status error code of 02h (Invalid Field in Command) shall be returned.

3. Verify that setting this feature with Save bit set to 1 result in aborting the command with status of Feature Identifier not savable

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

CPCIE-1-15, GETF-2

DSSD_26_Commands_Received_During_Device_Self_Test_Operation_Test_Case.py

Commands Received During Device Self-Test Operation Test Case

The objectives for the Commands Received During Device Self-test Operations test case are to verify the following:

1. While the Device Self-test command is in progress, the device properly terminates Device Self-Test command with a status code of “Device Self-test in Progress”

2. If a new Device Self-Test command with STC = Fh be sent while the Extend Device Self-Test command is in progress, the device properly terminates the ongoing Device Self-Test operation.

3. If a new Device Self-Test command with STC = Fh be sent while the Short Device Self-Test command is in progress, the device properly terminates the ongoing Device Self-Test operation.

4. That the Device Self-Test command with STC = Fh completes successfully.

5. While the Short Device Self-Test Operation is in progress, the device properly terminates Device Self-Test command once a Controller Level reset is triggered.

6. While the Short Device Self-Test Operation is in progress, the device properly terminates Device Self-Test command once a Format NVM command is received.

7. While the Short Device Self-Test Operation is in progress, the device properly terminates Device Self-Test command once a Sanitize Command is received.

8. While the Extend Device Self-Test Operation is in progress, the device properly terminates ongoing Device Self-Test command once a Format NVM command is received.

9. While the Extend Device Self-Test Operation is in progress, the device properly terminates ongoing Device Self-Test command once a Sanitize Command is received.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe Section 5.9/5.16.1.7/8.6

DSSD_26_Commands_Supported_And_Effects_Log_Page_Test_Case.py

This script will run the following tests:

1. Read the Controller Capabilities register and check values of bits 37 and 44

2. Do GetLogPage for LID 5h

3. Verify the log page contains an entry for each admin command shown as supported in Table 4 in the testplan

4. Verify the log page contains an entry for each I/O command shown as supported in Table 5 in the testplan

5. Check the effects bits in Table 5 in the testplan for I/O commands

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

STD-LOG-6

DSSD_26_Compare_Test_Case.py

This script will run the following tests:

1. Confirm support and determine maximum I/O size to use

2. Determine and validate the maximum LBA transfer size

3. Test individual non-fused commands

4. Test valid fused operation

5. Test valid fused operation scenario with incorrect compare pattern

6. Test fused operation using nonmatching values for NLBs and verify no update performed

7. Test fused operation using FUSE=1 for both commands and verify no update performed

8. Test fused operation where first command has FUSE=2 and second command has FUSE=1 and verify no update performed

9. Test fused operation where second command has FUSE=0

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-IO-1/3/4/5/6/7/8/9/10/11/12/13/14, GETF-2

DSSD_26_Controller_Memory_Buffer_Test_Case.py

Controller Memory Buffer Test Case If the device supports Controller Memory Buffer, verify that it is set as shown below:

1. If the value of CMBMSC.CRE is 0b, both values of CMBLOC and CMBSZ are cleared to 00h.

2. If the value of CMBMSC.CRE is NOT 0b, either CMBMSC.CMSE or CMBSTS.CBAI has 0b value.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-CFG-11

DSSD_26_Controller_Reset_Test_Case.py

This script will run the following tests:

1. Execute controller reset

2. Verify AQA, ASQ, ACQ, CMBMSC and PMRMSC registers didn’t change

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMeR-2

DSSD_26_Controller_Status_Ready_Test_Case.py

Controller Status Ready Test Case

The objectives of the Controller Status Ready test case are as follows:

1. That the controller does not successfully complete Admin commands before CSTS.RDY == 1.

2. That the controller successfully completes Admin commands as soon as CSTS.RDY == 1.

3. That the controller keeps CSTS.RDY == 0 until it can service Admin commands.

4. That the controller successfully completes Admin commands requiring media access within DP-CFG-9 seconds (from Adaptation data) of setting CC.EN=1.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TTR-2/3/4

postcondition(dut)

Execute Postcondition

DSSD_26_DSSD_Asynchronous_Event_Feature_Verification_Test_Case.py

DSSD Asynchronous Event Feature Verification Test Case

Default State The objective is to check that the factory default value of C9h feature is cleared to 0.

1. Get factory default state of feature C9h and make sure that it is cleared to 0.

Set Feature DSSD Asynchronous Event Configuration For Set feature the objectives are to test the following:

1. Get factory default value of feature C9h and it should be cleared to 0.

2. Change “Enable Panic Notices” field to 1 using set feature and using get feature check that the current state is set to 1 no later than next power cycle.

3. Current state should be cleared to 0 after drive goes through power cycle.

4. Default state should be cleared to 0

5. Change “Enable Panic Notices” field to 0 using set feature and using get feature check that the current state is cleared to 0 no later than next power cycle.

6. Current should be cleared to 0 after drive goes through power cycle.

7. Default state should be cleared to 0.

8. If setting this feature is not supported, then a status error code of 0x2 (Invalid Field in Command) shall be returned.

9. A Set Feature Command with SV = 1 received by the DUT the command shall be aborted with status “Feature Identifier Not Saveable”.

Get Feature DSSD Asynchronous Event Configuration For Get feature the objectives are to test the following:

1. Check the default state of C9h with SEL=01b.It should be cleared to 0 and should not change over a power cycle. Current state selection should not affect the default state.

2. Check the capabilities of C9h with SEL=11b and it should be 100b indicating that this feature is not savable, changeable, and not namespace specific.

3. Check the current state of C9h with SEL=00b and it should match with selection made with set feature.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SDAEC-1 to SDAEC-15, GDAEC-1/2

DSSD_26_DSSD_Feature_Verification_Test_Case.py

DSSD Feature Verification Test Case

The objective of this test case is to verify that the capabilities of each DSSD feature match those listed in the DSSD Feature Tables and the outcome of the Get Features command with different classes of NSIDs.

1. Table of DSSD Features with NVM Subsystem Scope:

   1. Using NSID = 0 in the Get Features command passes as expected.

   2. Using NSID = 1 in the Get Features command fails with status code 02h (Invalid Field in Command).

   3. Using NSID = FFFFFFFFh in the Get Features command fails with status code 02h (Invalid Field in Command).

   4. Using NSID = NN+1h in the Get Features command fails with status code 02h (Invalid Field in Command).

   5. Verify that the SV capability returned from the Get Features command matches the Saveable Persistence shown in the DSSD Feature Table.

2. Table of DSSD Features with Controller Scope:

   1. Using NSID = 0 in the Get Features command completes successfully.

   2. Using NSID = 1, or any other active NSID, in the Get Features command completes successfully.

   3. Using any inactive NSID in the Get Features command completes with status code 02h (Invalid Field in Command).

   4. Using NSID = FFFFFFFFh in the Get Features command completes successfully.

   5. Using NSID = NN+1h, or any invalid NSID, in the Get Features command fails with status code 02h (Invalid Field in Command).

   6. Verify that the SV capability returned from the Get Features command matches the Saveable Persistence shown in the DSSD Feature Table.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

GETF-5

DSSD_26_Data_Persistence_Across_Format_NVM_Operations_Test_Case.py

The objective for the Data Persistence Across Format NVM Operations test case is to verify that the data in the SMART / Health Information Log Page (LID 02h) persists across Format NVM operations by performing the following checks:

1. Verify that all reserved and unsupported fields are cleared to 0 and do not change.

2. Verify that all statically defined fields remain unchanged.

3. Verify that all dynamically updated counter attribute values that are highly unlikely to change in the absence of specific HW events persist across the Format NVM Commands are either unchanged or have increased in value. The notable exception to this would be fields such as the Available Spares attribute that should persist through the Format NVM Commands but may decrease in value due to the nature of what is being reported.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-2/3/18/23, SLOG-1/3/4/5/11

DSSD_26_Data_Persistence_Across_Sanitize_Operations_Test_Case.py

The objective for the Data Persistence Across Sanitize Operations test case is to verify that the data in the SMART / Health Information Log Page (LID 02h) persists across Sanitize Operations by performing the following checks:

1. Verify that all reserved and unsupported fields are cleared to 0 and do not change.

2. Verify that all statically defined fields remain unchanged.

3. Verify that all dynamically updated counter attribute values that are highly unlikely to change in the absence of specific HW events persist across the sanitize process are either unchanged or have increased in value. The notable exception to this would be fields such as the Available Spares attribute that should persist through Sanitize Commands but may decrease in value due to the nature of what is being reported.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-2/3/18/23, SLOG-1/3/4/5/11

DSSD_26_Data_Persistence_Across_TCG_Operations_Test_Case.py

Data Persistence Across TCG Operations Test Case: The objective for the Data Persistence Across TCG Operations test case is to verify that the data in the SMART / Health Information Log Page (LID 02h) persists across the required TCG operations by performing the following checks:

1. Verify that all reserved and unsupported fields are cleared to 0 and do not change.

2. Verify that all statically defined fields remain unchanged.

3. Verify that all dynamically updated counter attribute values that are highly unlikely to change in the absence of specific HW events persist across the TCG purge related operations are either unchanged or have increased in value. The notable exception to this would be fields such as the Available Spares attribute that should persist through the TCG purge related operations but may decrease in value due to the nature of what is being reported.

DSSD_26_Dataset_Management_Command_Verification_Test_Case.py

The objectives of this test case are as follows:

1. Verify support for the Dataset Management command by checking bit-2 of the ONCS field in the Identify Controller dataset.

2. Verify the use of the Dataset Management command with Attribute = AD for deallocate.

3. Verify that data blocks that have been deallocated read back as 0.

4. Verify that after an unsafe power cycle, data blocks that have been deallocated continue to read back as 0.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

OCP-NVMe-IO-2, OCP-TRIM-1/2/8

DSSD_26_Device_Capabilities_Log_Page_Test_Case.py

This script will run the following tests:

1. NVMe Get Log Page Command with LID=C4h

2. NVMe Identify Command with CNS=01h

3. Verify number of physical PCIe ports matches the corresponding field in adaptation parameters

4. Verify bytes 1:0 of OOB Management Support field are correct

5. Verify bytes 1:0 of Write Zeroes Command Support field are correct

6. Verify bytes 1:0 of Sanitize Command Support field are correct

7. Verify bytes 1:0 of Dataset Management Command Support field are correct

8. Verify bytes 1:0 of Write Uncorrectable Command Support field are correct

9. Verify bytes 1:0 of Fused Operation Support field are correct

10. Verify various values for DSSD Power States

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

DCLP-1 to DCLP-12

DSSD_26_Drive_Behavior_In_Case_Of_PLP_Failure_Test_Case.py

This script will run the following tests:

1. Perform sequential write/read for five minutes

2. Inject PLP error

3. Record EOL-PLP setting

4. Perform sequential writes for one minute and verify pass/fail based on EOL-PLP setting

5. Recover the device from the error injection

6. Check drive performance after it recovers

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

PLP-9

DSSD_26_Drive_State_After_Firmware_Activation_Without_Reset_Test_Case.py

The objectives of this test case are to verify the following:

1. That firmware activation without reset does not change the contents of the features listed in the Feature Table

2. That firmware activation without reset does not change the contents of the log pages listed in the Log Page Table.

3. That firmware activation without reset does not change the PCIe Link Status.

4. That firmware activation without reset does not change the IO SQ/CQ queue settings.

5. That firmware activation without reset does not change the LBA format.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FWUP-11

compare_dict(log_a, log_b, resv, static, dyn)

Compares corresponding values in two dictionaries

Parameters:

• log_a (dict) – First dictionary of objects to be compared

• log_b (dict) – Second dictionary of objects to be compared

• resv (list) – List of reserved fields

• static (list) – List of static fields

• dyn (list) – List of dynamic fields

Return type:

None

enable_fw_update(dut)

Enables FW Update in SMBus command code 90 (byte 91)

Parameters:

dut (XML_API) – Device object under test

Return type:

None

get_feature_state(dut)

Does Get Features on a FID

Parameters:

dut (XML_API) – Device object under test

Return type:

Feature data

get_identify_state(dut)

Executes steps 25-30

Parameters:

dut (XML_API) – Device object under test

Return type:

Identify data for CNS 0h and 1h

get_io_state(dut)

Executes steps 20-23

Parameters:

dut (XML_API) – Device object under test

Return type:

None

get_log_page_state(dut, endgid)

Does Get Log Page on a LID

Parameters:

• dut (XML_API) – Device object under test

• endgid (int) – ENDGID value for LID 9h

Return type:

Log page data

get_pcie_link_status(dut)

Get the PCIe link status

Parameters:

dut (XML_API) – Device object under test

Return type:

PCIe link status

issue_io(dut, seektype, io_profile, threads, blocks, iosperpass=0, io_runtime=-1, io_pattern=0, extra_config=None)

Executes an IO Test

Parameters:

• dut (XML_API) – Device object under test

• seektype (str) – Either ‘Sequential’ | ‘Random’

• io_profile (str) – IO Profile to be executed

• threads (int | str) – Threads (QD) to execute IO on

• blocks (int | str) – Number of Logical Blocks

• iosperpass (int | str) – Param to determine what the IO does on the drive ‘0’: unlimited, ‘-1’: Iterate once over drive, ‘-2’: Iterate twice over drive

• io_runtime (int) – Time in seconds for IO to execute

• io_pattern (int) – Pattern for io to be executed

• extra_config (dict | None) – Optional parameter for running IO test with additional configurations

Return type:

dict

verify_ios(io_tests)

Checks if I/O tests passed or failed

Parameters:

io_tests (list) – list of I/O test dicts

Returns:

io_failed – Returns failed if any I/O test failed

Return type:

bool

DSSD_26_E1L_PCIe_Speed_And_Lane_Width_Test_Case.py

This script will run the following tests:

1. Verify PCI Express Link Capabilities register (0Ch) lane width and speed

2. Verify PCI Express Link Status register (12h) lane width and speed

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FFE1L-2

DSSD_26_E1L_PWRDIS_Test_Case.py

This script will run the following tests:

1. Assert PWRDIS and wait for device to shutdown

2. De-assert PWRDIS and wait for device to come up

3. Start sequential write I/O test and assert PWRDIS and wait for device to shutdown

4. De-assert PWRDIS and wait for device to come up

5. Run sequential read I/O test for 5 minutes and verify there are no miscompares

6. Run sequential write I/O test for 5 minutes

7. Run sequential read I/O test for 5 minutes

8. Verify performance is within 5% of performance numbers supplied in adaptation parameters

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FFE1L-9

DSSD_26_E1S_PCIe_Speed_And_Lane_Width_Test_Case.py

This script will run the following tests:

1. Verify PCI Express Link Capabilities register (0Ch) lane width and speed

2. Verify PCI Express Link Status register (12h) lane width and speed

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FFE1S-2

DSSD_26_E1S_PWRDIS_Test_Case.py

This script will run the following tests:

1. Assert PWRDIS and wait for device to shutdown

2. De-assert PWRDIS and wait for device to come up

3. Start sequential write I/O test and assert PWRDIS and wait for device to shutdown

4. De-assert PWRDIS and wait for device to come up

5. Run sequential read I/O test for 5 minutes and verify there are no miscompares

6. Run sequential write I/O test for 5 minutes

7. Run sequential read I/O test for 5 minutes

8. Verify performance is within 5% of performance numbers supplied in adaptation parameters

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FFE1S-9

DSSD_26_EUI64_And_NGUID_Test_Case.py

EUI64 and NGUID Test Case

The objectives of this test case are to:

1. Verify that the device comes from the factory with a single namespace that has a nonzero value for EIU64 and NGUID.

2. Verify that for all subsequent namespace creations, the EUI64 field is 0.

3. Verify that for all subsequent namespace creations, the NGUID field contains a value that is different from the default and from all other NGUID values.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-CFG-7/8

DSSD_26_Endianness_Verification_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID C0h

2. Check that byte 0 of Security Version Number and Log Page Version fields is correct

3. Verify Log Page GUID is correct

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_Endurance_Estimate_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID C0h and get Endurance Estimate field value

2. If endurance groups are supported, do GetLogPage for LID 9h and get Endurance Estimate field value

3. Verify both values are the same

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_Endurance_Group_Information_Log_Page_09h_Test_Case.py

This script will run the following tests:

1. Verify support for endurance groups

2. Read the endurance group information log page and sanity check fields

3. Compare endurance estimate values

4. Sanity check remaining fields

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

STD-LOG-17

DSSD_26_Error_Information_Log_Page_Test_Case.py

This script will run the following tests:

1. Get ELPE field

2. Do GetLogPage for LID 1h to get error count for each entry

3. Reset controller

4. Do IdentifyController

5. Do GetLogPage for LID 1h to get error count for each entry

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

STD-LOG-1

DSSD_26_Error_Recovery_Log_Page_Test_Case.py

This script will run the following tests:

1. Read Error Information log page to get recovery settings

2. Verify reserved fields and static fields and make sure device is in error free state

3. Record performance logs and set AEN before drive goes into error state

4. Inject error and recover the drive based on reset and recovery actions

5. Check drive performance after it recovers

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

EREC-AEN-1, EREC-1 to EREC-15

DSSD_26_Execution_Time_Device_Self_Test_Operation_Test_Case.py

Execution Time Device Self-Test Operation Test Case

the objectives for the Device Self-Test Command test case are to verify the following:

1. That the device properly indicates support for the Device Self-Test operation in Identify Controller data.

2. That the device properly defines the Extended Device Self-test Time in Identify Controller data.

3. That the Device Self-Test Log Page correctly reports the Device Self-Test Operation status.

4. That the execution time for each Device Self-Test Commands is defined as follows:

   • A short Device Self-Test operation shall be completed in less than or equal to 2 minutes.

   • An extended Device Self-Test operation shall be completed in less than or equal to 30 minutes.

   • A vendor-specific self-test operation shall be completed in less than or equal to 2 seconds.

5. That even though the Device Self-Test operation and host I/O activities are running concurrently, the Device Self-Test operation is still completed within the OCP required time.

6. That even though no blocks have been written at all, the extend Device Self-Test operation doesn’t fail as a result.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-AD-12, STD-LOG-13, SELFTST-2/3/4/5/9

DSSD_26_Factory_Default_Settings_Verification_Test_Case.py

This script will run the following tests:

1. All supported firmware slots shall contain the most recent production firmware revision.

2. All logical blocks shall be deallocated.

3. The following SMART / Health Information log page fields shall be cleared to 0h: Critical Warning, Endurance Group Critical Warning Summary, Data Units Read, Data Units Written, Host Read Commands, Host Write Commands, Controller Busy Time, Power Cycles, Power On Hours, Unsafe Shutdowns, Media and Data Integrity Errors, Percentage Used, Number of Error Information Log Entries.

4. The Available Spare field in the SMART / Health Information log page shall be set to a value of 100.

5. The Total Number of Events field in the Persistent Event log page shall be cleared to 0h.

6. The Sanitize Status field in the Sanitize Status log page cleared to 0 indicating the NVM subsystem has never been sanitized and the Global Data Erased bit in the Sanitize Status field set to 1b.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FDEF-1/2/3/4/5, NVMe-AD-22

DSSD_26_Failed_Sanitize_Operations_Test_Case.py

Failed Sanitize Operations Test Case

The objectives for the Failed Sanitize Operation test case are to verify the following:

1. The DUT shall fail all Sanitize commands received while a namespace is Write Protected and return command completion status code 20h.

2. The DUT shall fail all Sanitize commands received while a Firmware Activation is pending and shall return the same non-zero command completion status code that was received for the firmware commit command when the status code is 0Bh or 10h. For all other Firmware Commit status codes the DUT shall fail the Sanitize Command with command completion status code 11h.

3. That a failed Sanitize Operation can be successfully restarted once the reason for the previous failure is resolved.

4. That if a DUT fails a Sanitize command for any reason it shall not perform any Sanitize operations and shall not update the Sanitize Status Log Page.

5. Sending the Sanitize command with Sanitize Action = 001b while the DUT is in the Sanitize Operation failed state causes the DUT to exit the Sanitize Failed state.

6. If the DUT receives a Sanitize Command with Sanitize Action = 001b while the DUT is not in the Sanitize Failed state, the DUT shall successfully complete the command regardless of the state and regardless of any values in other Sanitize Command fields.

7. A Sanitize Command with an invalid Sanitize Action value received by the DUT the command shall be aborted with status “Invalid Field in Command”.

8. If a Sanitize command sent with Restricted Completion Mode fails, the failure can be recovered by sending another Sanitize command with Restricted Completion Mode and Sanitize Action = 001b.

9. Sending another Sanitize command with Unrestricted Completion Mode shall be aborted with command status “Sanitize Failed”.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe v2.0d 5.16.1.25/5.27.1.19/5.24/8.21

postcondition(dut)

Execute Postcondition

DSSD_26_Fatal_Status_Test_Case.py

Fatal Status Test Case

When the device is in factory default state the CSTS.CFS field should be zero. If device experiences panic issues, for example “Logic FW error,” and if the device uses CFS for panic notifications, this field will be set to 1. Upon performing the recommended panic reset action and device recovery action CSTS.CFS should reset back to zero.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-CFG-3

DSSD_26_Feature_ID_D0h_Verification_Test_Case.py

Feature ID D0h Verification Test Case

The objective of this test case is to verify that the device does not support FID D0h as follows:

1. Verify that an NVMe Get Features command sent with FID=D0h is aborted with status code 02h (Invalid Field in Command).

2. Verify that an NVMe Set Features command sent with FID=D0h is aborted with status code 02h (Invalid Field in Command).

3. Read the Feature Identifiers Supported and Effects Log and verify that the FSUPP field in the entry for FID D0h is cleared to 0.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

GETF-3

DSSD_26_Firmware_Activation_Notice_AE_Test_Case.py

The objectives for the Firmware Activation Notice AE Test Case are as follows:

a.) Verify that if an event occurs for which reporting is enabled and there are no Asynchronous Event

Request commands pending, the device retains the event information for that Asynchronous Event Type and reports it once an Asynchronous Event Request command is submitted.

b.) Verify that if duplicate events are queued while no Asynchronous Event Request commands are

pending, the duplicate events are reported as a single response to a future Asynchronous Event Request command.

c.) Verify that, if an AER is pending, after sending the NVMe Firmware Commit command with CA=3

and slot = 0, an AEN is sent to the host with the following information:

1. Event Type: Notice

2. Asynchronous Event Information: Firmware Activation Starting

3. Log Page Identifier: Firmware Slot Information log (03h)

d.) Verify that, if an AER is pending, after sending the NVMe Firmware Commit command with CA=3

and firmware slot specified, an AEN is sent to the host with the following information:

1. Event Type: Notice

2. Asynchronous Event Information: Firmware Activation Star

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-OPT-8/9/10/11, NVMe-AD-24/25

DSSD_26_Firmware_Slot_Information_Log_Page_Test_Case.py

This script will run the following tests:

1. Get firmware slot info from LID 3h

2. Get FRMW from Identify Controller

3. Download and commit the previous firmware image to the starting firmware slot

4. Verify FRS field for appropriate slot in LID 3h matches the previous firmware image

5. Verify current and next active firmware slots in LID 3h

6. Do controller reset

7. Verify current firmware slot in LID 3h

8. Repeat steps 3-7 for all supported firmware slots

9. Commit the current firmware image to the current firmware slot

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

STD-LOG-5, MS-CONF-6

DSSD_26_Firmware_Update_Test_Case.py

Test objectives are to verify the following:

1. The firmware Commit command with Commit Action (CA) 000b, 001b, 010b and 011b are supported.

2. A minimum of 3 slots firmware slots are supported by verifying that the value of bits [3:1] in the Firmware Updates (FRMW) field is greater than or equal to 3.

3. The device shall complete the Firmware Activation process and be ready to accept host IO and admin commands within 1 second from the receipt of the firmware commit command. Verify that the value of Maximum Time for Firmware Activation (MTFA) field is less than or equal to Ah.

4. The device supports a read-only firmware slot in slot 1.

5. If the Firmware Slot field in the Firmware Commit command is cleared to 0h, verify that the device commits the firmware image to a firmware slot that is not currently active.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FWUP-3/4/6/7/20/21/25

DSSD_26_Firmware_Update_Without_Data_Loss_Or_Destruction_Test_Case.py

Test objectives are to verify the following:

1. Device supports repeated Firmware Download and Commit operations.

2. Repeated Firmware Download and Commits shall not cause data to be lost or corrupted.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FWUP-2/10

DSSD_26_Format_NVM_Command_Extended_Execution_Time_Verification_Test_Case.py

This script will run the following tests:

Verify each Format NVM commands completes within these timeout settings. 1. The Format NVM Command for Cryptographic Erase shall complete within 10 seconds. 2. The Format NVM Command for No Secure Erase shall complete within the per TB specific timeout parameter provided by the supplier in the Adaptation Data. 3. The Format NVM Command for User Data Erase shall complete within 10 seconds per TB of device capacity.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

CTO-1/2/3/6/8/11

DSSD_26_Format_NVM_Command_On_A_Per_Namespace_Basis_Test_Case.py

This script will run the following tests:

1. Verify support for Format NVM command

2. Determine the maximum number of namespaces supported

3. Get and save the current namespace dataset

4. Calculate the LBA size

5. Read the namespace granularity list

6. Use the namespace granularity descriptor to calculate the capacity to use to create MaxNsCnt namespaces

7. Delete original namespace

8. Create and precondition new namespaces

9. Format (SES=1) two randomly selected namespaces

10. Verify the Format NVM only affected the two specific namespaces

11. Restore original namespace

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-AD-2/5/8/23, SEC-4, NVMe Spec Format NVM Section

DSSD_26_Format_NVM_Crypto_Erase_Test_Case.py

This script will run the following tests:

1. Verify support for Format NVM command

2. Get and save current LBA size

3. Precondition namespace

4. Start Format NVM command (SES=2)

5. Verify Format command has ended

6. Verify the Format NVM results

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-AD-2/5/8/23, SEC-4, NVMe Spec Format NVM Section

DSSD_26_Format_NVM_No_Secure_Erase_Test_Case.py

This script will run the following tests:

1. Verify support for Format NVM command

2. Get and save current LBA size

3. Precondition namespace

4. Start Format NVM command (SES=0)

5. Verify format command has ended

6. Verify the Format NVM results

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-AD-2/5/8/23, SEC-4, NVMe Spec Format NVM Section

DSSD_26_Format_NVM_User_Data_Erase_Test_Case.py

This script will run the following tests:

1. Verify support for Format NVM command

2. Determine if the controller will use crypto erase instead of user data erase

3. Get and save current LBA size

4. Precondition namespace

5. Start Format NVM command (SES=1)

6. Verify format command has ended

7. Verify the Format NVM results

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-AD-2/5/8/23, SEC-4, NVMe Spec Format NVM Section

DSSD_26_Hardware_Component_Log_Page_Test_Case.py

Test objectives are to verify the following:

1. That the Hardware Component log page is returned, and the command completes with status success.

2. That the Hardware Component log page format for recording the hardware components on the device matches OCP requirements.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

HWCOMP-1/2/3/4/5

DSSD_26_IEEE1667_Feature_Test_Case.py

This script will run the following tests:

For Set feature the objectives are to test the following:

1. Get factory default state of feature IEEE1667

2. If the default state is enabled:

   • Disable IEEE1667 Silo using set feature and using get feature check that the current state and saved state are set to “disabled” no later than next power cycle

   • Current and saved state should be “disabled” even after drive goes through power cycle

   • Default state should be “enabled”

   • Enable IEEE1667 Silo using set feature and using get feature check that the current state and saved state are set to “enabled” no later than next power cycle

   • Current and saved state should be “enabled” even after drive goes through power cycle

   • Default state should be “enabled”

   • If setting this feature is not supported, then a status error code of 0x2 (Invalid Field in Command) shall be returned

3. If the default state is disabled:

   • Enable IEEE1667 Silo using set feature and using get feature check that the current state and saved state are set to “enabled” no later than next power cycle

   • Current and saved state should be “enabled” even after drive goes through power cycle

   • Default state should be “disabled”

   • Disable IEEE1667 Silo using set feature and using get feature check that the current state and saved state are set to “disabled” no later than next power cycle

   • Current and saved state should be “disabled” even after drive goes through power cycle

   • Default state should be “disabled”

   • If setting this feature is not supported, then a status error code of 0x2 (Invalid Field in Command) shall be returned

For Get feature the objectives are to test the following:

1. Check the default state of C4h with SEL=01b.It should match with factory default value and should not change during power cycle. Current state selection should not affect the default state

2. Check the capabilities of C4h with SEL=11b and it should be 101b indicating that this feature is savable, changeable, and not name space specific

3. Check the current state of C4h with SEL=00b and it should match with enabled/disable selection made with set feature

4. Check the saved state of C4h with SEL=10b

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

S1667-1 to S1667-15, GETF-1/2

DSSD_26_IO_Command_Execution_Time_Verification_Test_Case.py

I/O Command Execution Time Verification Test Case:

For I/O commands the CTO test objectives are to verify the following:

1. That when executing a stressing I/O workload over the course of 1 hour no more than 7 I/Os shall take more than 2s to complete.

2. That when executing the previous I/O workloads under full capacities of device (Maximum Data Transfer Size and Maximum Queue Entries Supported), the performance still shall be met.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

CTO-1/2/3/6/8/11

DSSD_26_Incomplete_Shutdown_Test_Case.py

This script will run the following tests:

1. Perform sequential write and read for five minutes and collect performance logs

2. Issue GetLogPage for LID 2h and check Critical Warning bits 3-4

3. Issue GetLogPage for LID C0h and record Incomplete Shutdowns field

4. Create INCS scenario on the drive

5. Perform 4KB random writes with a queue depth of 128

6. Issue Identify command and verify it passes

7. Issue GetLogPage for LID C0h and check Incomplete Shutdowns field

8. Issue GetLogPage for LID 2h and check Critical Warning bit 3

9. Issue GetLogPage for LID C1h and check various fields

10. Perform sequential writes and verify they fail

11. Perform sequential reads and check if they pass or fail

12. Format the drive

13. Set CC.EN=1

14. Issue GetLogPage for LID C1h and check Panic ID field

15. Issue Identify command and verify it passes

16. Perform sequential write and read for five minutes and collect performance logs

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

INCS-1/4/5/6

DSSD_26_LBA_Status_Information_Log_Page_Test_Case.py

This script will run the following tests:

1. That reading the LBA Status Information Log page is supported by the DUT.

2. That the log page reports LBA ranges that have been marked uncorrectable by the Write Uncorrectable command.

3. The test case shall use the Write Uncorrectable command to create N separate LBA ranges marked as uncorrectable.

4. The test case shall next read the LBA Status Information Log Page and verify that it contains a single LBA Status Namespace Element.

5. The test case shall verify that the number of LBA Range Descriptors reported in the LBA Status Log Namespace Element is equal to N, where N is the number of uncorrectable LBA Ranges created.

6. The test case shall next verify that the LBA ranges reported in the LBA Range Descriptors in the LBA Status Namespace Element match the LBA ranges marked as uncorrectable.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-AD-27, STD-LOG-11

DSSD_26_Little_Endian_Verification_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID 2h and get values of Data Units Read/Written, Host Read/Write Commands, Controller Busy Time, Power Cycles, Power On Hours, and Unsafe Shutdowns fields

2. Issue four write and read commands, each with 251 blocks

3. Power cycle the drive

4. Do GetLogPage for LID 2h and verify Data Units Read/Written and Host Read/Write Commands values increased by at least 1

5. Surprise power cycle the drive

6. Do GetLogPage for LID 2h and verify Power Cycle Count and Unsafe Shutdowns values increased by at least 1

7. Perform 4KB random reads and writes for 65 minutes

8. Do GetLogPage for LID 2h and verify Power On Hours value increased by at least 1

9. Verify Controller Busy Time value stayed the same or increased by at least 1

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-2/3/18/23, SLOG-1/3/4/5/11

DSSD_26_Low_Power_Modes_Requirements_Test_Case.py

This script will run the following tests:

1. Verify that ASPM Optionality Compliance (AOC) bit is set to 1

2. Verify that ASPM Support (ASPMS) field is set to 10b or 11b

3. Execute PCIe reset

4. Verify that ASPM Control (ASPMC) field is cleared to 00b

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

LPWR-1/2

DSSD_26_M2_PCIe_Speed_And_Lane_Width_Test_Case.py

This script will run the following tests:

1. Verify PCI Express Link Capabilities register (0Ch) lane width and speed

2. Verify PCI Express Link Status register (12h) lane width and speed

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FFM2-5

DSSD_26_Maximum_Data_Transfer_Size_Test_Case.py

Maximum Data Transfer Size Test Case

The objective of this test case is read the Identify controller’s MDTS field and verify that the device maximum data transfer size is greater than or equal to 256KiB.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-CFG-2

DSSD_26_NVMe_Commands_Received_During_Sanitize_Operation_Test_Case.py

NVMe Commands Received During Sanitize Operation Test Case

The objectives for the Commands Prohibited During Sanitize Operation test case are to verify the following:

1. Once the Sanitize Operation begins, the device shall abort any active or subsequently received commands that are not allowed during Sanitize Operations with status “Sanitize in Progress”. Refer to the NVMe Commands Table for commands that are allowed and prohibited.

2. Once the Sanitize Operation begins, the device successfully completes any active or subsequently received commands that are allowed during Sanitize Operations. Refer to the NVMe Commands Table for commands that are allowed and prohibited.

3. That while in the Sanitize Failed state, the DUT aborts all commands submitted that are prohibited during a Sanitize Operation with status “Sanitize Failed”. Note that supporting this will require error injection capability.

4. That all Admin/NVM commands not allowed during a sanitize operation also are aborted while the DUT is in a sanitize failed state.

5. Once the DUT exits the Sanitize Failed state it shall successfully complete all supported commands received including those that are prohibited during Sanitize Operations.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe v2.0d 5.16.1.25/5.27.1.19/5.24/8.21

check_sanitize_in_progress(dut, sanitize_action=522)

Verify a Sanitize Operation is in progress before executing a command

do_format(dut, nsid, lbaf, ses, format_results, TotalNVMCapacity_TB)

Execute format command and put the results into a dictionary (since the format is done as part of a thread, a dictionary will allow the main part of the program to access the results)

Parameters:

• dut (XML_API) – Device object under test

• nsid (int) – Namespace under test

• lbaf (int) – LBAF to use in the format

• ses (int) – SES to use in the format

• format_results (dict) – Dictionary to hold the results of the format command

Return type:

None

do_sanitize(dut, sanact, sanitize_results)

Execute sanitize command and put the results into a dictionary (since the sanitize is done as part of a thread, a dictionary will allow the main part of the program to access the results)

Parameters:

• dut (XML_API) – Device object under test

• sanact (bin) – Sanitize action to use when starting sanitize operation

• sanitize_results (dict) – Dictionary to hold the results of the sanitize command

Return type:

None

postcondition(dut)

Execute Postcondition

DSSD_26_NVMe_Controller_Configuration_And_Behavior_Test_Case.py

NVMe Controller Configuration and Behavior Test Case

Verify that the device configuration is set as shown below:

1. The stride between doorbell properties shall be 4 bytes, as set by CAP.DSTRD.

2. The device shall be NVM subsystem scope, as set by CAP.CPS.

3. The device shall support the NVM Command Set, as set by CAP.CSS and “Controller Type (CNTRLTYPE)” field in the Identify Controller’s data structure.

4. The minimum memory page size is 2^12.

5. The maximum memory page size is at least 2 ^ (12 + CAP.MPSMAX).

6. The maximum number of Error Information log entries that are stored by the controller is 256, as set by “Error Log Page Entries (ELPE)” field in the Identify Controller’s data structure.

7. The device shall NOT support the Host Memory Buffer, as set by zero values of “Host Memory Buffer Minimum Size (HMMIN)” field and “Host Memory Buffer Preferred Size (HMPRE)” field in the Identify Controller’s data structure.

8. The device shall NOT support the Controller Ready Independent of Media mode, as set by zero value of CAP.CRMS.CRIMS.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-CFG-9/12/13/16/17/18/19/20

DSSD_26_Namespace_Attachment_Command_Verification_Test_Case.py

This script will run the following tests:

1. That when sending a properly formatted Namespace Attachment command specifying the Controller Attach operation and providing a valid controller ID and NSID, the drive accepts and processes the Namespace Attachment command without error and Identify data shows the namespace associated with the controller ID

2. That when a namespace is attached to a controller the namespace shifts from inactive to active state

3. That when deleting a namespace that is actively attached to a controller, the namespace shifts from being active to inactive

4. That when sending a properly formatted Namespace Attachment command specifying the Controller Detach operation, and providing a valid controller ID and NSID, the drive accepts and processes the Namespace Attachment command without error, the namespace is disassociated with the controller ID, and is shown as inactive

5. That based upon using the values of NN and MNAN from the Identify Controller dataset to set the maximum number of namespaces supported, that namespace management can be performed for the full number of namespaces supported

6. That based upon using the values of NN and MNAN from the Identify Controller dataset to set the maximum number of namespaces supported, the maximum number of namespaces supported can be created and the NGUID field value in each namespace data block shall be unique

7. That the Namespace Management command and namespace attach command can be used to increase the over provisioning from the default set at the factory. Note that this step is here because the Namespace Attach command must be used to make a namespace active, which is required to pull and see the full namespace dataset.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-AD-4, NUSE-1, NSM-1/2/3/4/5/6/7, NVMe sections 3.2.1/5.22/8.11

DSSD_26_Namespace_Attribute_Notices_AE_Test_Case.py

This script will run the following tests: The objectives for the Namespace Attribute Notices AE Test Case are to verify that the device completes an Asynchronous Event Request command for the “Namespace Attribute Changed” event when there is a change to one or more of the following:

1. LBA format has been changed by Format NVM command, the AEN will be triggered because of the Identify Namespace data structure (CNS = 00h).

2. The namespace is currently write-protected because of the Write Protection Config Set Feature Command, the AEN will be triggered because of the change of the I/O Command Set Independent Identify Namespace data structure (CNS = 08h).

3. The namespace has been detached/attached/deleted, the AENs will be triggered because of the change of the Active Namespace ID list (CNS = 02h).

4. The LBA format has been changed by Format NVM command, the AEN will be triggered because of the change of the Identify Namespace data structure for an Allocated Namespace ID (CNS = 11h).

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-OPT-8/9/10/11, NVMe-AD-24/25

DSSD_26_Namespace_Management_Command_Verification_Test_Case.py

This script will run the following tests:

1. That when sending a properly formatted Namespace Management command specifying the Create option and providing a valid copy of the namespace data structure, the drive accepts and processes the Namespace Management command without error and returns the NSID for the new namespace in Dword 0 of the completion queue entry for the command

2. That when sending a properly formatted Namespace Management command specifying the Delete option and the NSID of a valid namespace, the drive accepts and processes the Namespace Management command without error and deletes the namespace

3. That if the value of the MNAN field in the Identify Controller data set is greater than 0, it shall be used to set the ceiling for the maximum number of namespaces. If it is 0, the value of NN in Identify Controller data shall set the ceiling.

4. That if the value of the NN or MNAN fields in the Identify Controller data set are greater than 1, then (a) can be performed for the full number of namespaces supported, followed by performing (b) for the full number of namespaces supported. Note that this requires the drive capacity to be factored in if multiple namespaces are to be created.

5. That if the value ELBAS is 0 in Controller Attributes Field of Identify Controller Data, indicating no support for Extended LBA Formats

6. That when creating or formatting a namespace, the default value FLBAS=0 and LBAF=0 correspond to the default format set at the factory, which also should be the same as the value for DP-CFG-1 in the device profile in the devices Adaptation data

7. That namespace granularity is supported, the namespace granularity descriptor values are not 0, and the namespace granularity values can be successfully used to create one or more namespaces

8. That Identify Commands show newly created namespaces are valid and inactive when not attached to a controller

9. That the Identify Namespace command send with a valid inactive NSID succeeds and returns a Namespace data structure filled with 0s

10. That the identify Namespace command sent with broadcast NSID succeeds and returns a data struct with fields set common to all Namespaces. Note fields unique to each Namespace such as NSZE, NCAP, NGUID, EUI64, etc., shall be 0.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-AD-3, NSM-1/2/3/4/5/6/7/8, NVMe sections 3.2.1/5.23/8.11

namespace_management(dut, id_ns, sel, format_index, mset, new_ns_capacity=0, max_ns_count=1, is_private=0, pi=0, pil=0)

Helper function to create a new Namespace with specific field information

Parameters:

• dut (XML) – Device object under test

• id_ns (dict) – Identify Namespace command dictionary

• sel (int) – Select Field for namespace management action

• new_ns_capacity (int) – Create Size capacity

• max_ns_count (int) – Count of namespaces to be made

• format_index (int)

• mset (int) – Metadata Settings

• is_private (int) – Determines if namespace is private or not

• pi (int) – Protection Information

• pil (int) – Protection Information Location

Returns:

create_namespace

Return type:

dict

DSSD_26_Namespace_Support_Test_Case.py

This script will run the following tests:

1. Issue Identify command with CNS = 1 and verify MNAN/NN values

2. Issue Identify command with CNS = 2 and verify active NSID list contains one NSID

3. Issue Identify command with CNS = 0

4. Verify MaxBlks = NSZE = NCAP

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SECTOR-3

DSSD_26_No_Data_Destruction_During_Device_Self_Test_Operation_Test_Case.py

Destructiveness for Device Self-Test Operation Test Case

The objective of this test case is to verify the OCP requirement SELFTST-11 as follows:

1. Verify that user data pattern created during preconditioning is unchanged after a self-test operation.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SELFTST-11

DSSD_26_PCIe_Basic_Configurations_Test_Case.py

Test objectives are to verify the following:

1. That the MSI capability structure in configuration space is 4-byte aligned if the device supports the MSI capability.

2. That the device supports Power Management Capability and that neither the D1 or D2 power management states are supported.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

PCI-11/35

DSSD_26_PCIe_Conventional_Reset_Test_Case.py

PCIe Conventional Reset Test Case The objectives of the Device Stability and Data Integrity test case are as follows:

1. That the out-of-band NVMe admin commands requiring media access complete within DP-CFG-9 seconds (from Adaptation data) after the cold reset is completed.

2. That the out-of-band NVMe admin commands requiring media access complete within DP-CFG-9 seconds (from Adaptation data) after the warm reset is completed.

3. That the out-of-band NVMe admin commands requiring media access complete within DP-CFG-9 seconds (from Adaptation data) after the hot reset is completed.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TTR-22

mi_transport(dut, transport)

Execute NVMe Admin command via MI

postcondition(dut)

Execute Postcondition

DSSD_26_PCIe_Max_Payload_Size_Requirements_Test_Case.py

Test objectives are to verify the following:

1. Verify that the Max Payload Size supported by the device is 512 bytes or higher by reading the MPS field of the PCIe Device Capabilities register.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

PCI-1/2/3/4/5/6/11/33/35, DP-CFG-11, TTR-22

DSSD_26_PCIe_Resets_Requirements_Test_Case.py

Test objectives are to verify the following:

1. That the device supports FLR by verifying the Function Level Reset Capability (FLRC) field in the Device Capabilities Register, and by triggering multiple FLRs and verifying that the device comes back in an error free state.

2. That the device supports the PCIe Cold Reset by performing system shutdown/startup and verifying that the drive powers back up in an error free state.

3. That the device supports the PCIe Warm Reset by toggling the PERST# multiple times and verifying that the drive comes back in an error free state.

4. That the device supports PCIe Hot Reset by triggering multiple times and verifying that each time the drive comes back in an error free state.

5. That the device successfully processes both I/O and Admin commands that require media access after completing the PCIe Conventional Reset.

6. That the admin commands that are prohibited via Lockdown command should remain prohibited after toggling the PERST# signal.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

PCI-5/6, PCI-33, TTR-22, DP-CFG-11

DSSD_26_PCIe_TLP_Completion_Timeout_Requirements_Test_Case.py

Test objectives are to verify the following:

1. The TLP completion timeout is programmable to different supportable ranges by programming the timeout to a different subset range.

2. Disable the TLP completion timeout and verify that it was successful.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

PCI-2/3/4

DSSD_26_PEL_Data_Persistence_Across_Format_NVM_Operations_Test_Case.py

The objectives for this test case are to verify the following:

1. That the device processes the Get Log Page commands to backup Persistent Event Log as the baseline.

2. That the data in the Persistent Event Log Page (LID 0Dh) persists across Format NVM commands by performing the following checks:

   1. That all reserved and unsupported fields are cleared to 0 and do not change.

   2. That all statically defined fields remain unchanged.

   3. Verify that the Total Number of Events field in the Log Page data following successful Format NVM completion has increased as expected.

   4. Verify that the event data in the Log Page has persisted.

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-9/10/20/21/22/23

DSSD_26_PEL_Data_Persistence_Across_Sanitize_Operations_Test_Case.py

The objectives for the Data Persistence during Sanitize Operation test case are to verify the following:

1. That the device processes the Get Log Page commands to backup Persistent Event Log Page as the baseline.

2. That the data in Persistent Event Log Page (LID 0Dh) persists across the Sanitize operations by performing the following checks:

   1. That all reserved and unsupported fields are cleared to 0 and do not change.

   2. That all statically defined fields remain unchanged.

   3. Verify that the Total Number of Events field in Log Page data following successful Sanitize completion has increased as expected.

   4. Verify that the event data in the Log Page has persisted.

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-9/10/20/21/22/23

DSSD_26_PEL_Data_Persistence_Across_TCG_Purge_Operations_Test_Case.py

The objectives for this test case are to verify the following:

1. That the device processes the Get Log Page commands to backup Persistent Event Log as the baseline.

2. That the data in Persistent Event Log Page (LID 0Dh) has persisted across the previous TCG command by performing the following checks:

   1. That all reserved and unsupported fields are cleared to 0 and do not change.

   2. That all statically defined fields remain unchanged.

   3. That the data in the Persistent Event Log Page should be persisted across the previous TCG commands by checking the ‘Total Number of Events’ field in Log Page data.

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-9/10/20/21/22/23

DSSD_26_PERST_Test_Case.py

PERST Test Case

De-assert/assert PERST# and verify that the device responds to configuration access space setting CC.EN to 1 within 1 second of de-asserting PERST#.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TTR-20

DSSD_26_PLP_Health_Check_Interval_Feature_Test_Case.py

Default State: The objective is to check that the factory default value of 0xC6 feature is set to 15 minutes.

1. Get factory default state of feature 0xC6 and make sure that it is set to 0x000F.

b. If this feature is not supported by the controller, then a status error code of 0x2 (Invalid Field in Command) shall be returned.

Set Feature PLP Health Check Interval: For Set feature the objectives are to test the following

1. Get factory default value of feature PLP Health Check Interval (0xC6) and it should be 000Fh.

b. Using set feature change the interval to X minute, value other than 000Fh, and using get feature check that the current state and saved state are set to Xh no later than next power cycle.

3. Current and saved state should be Xh even after drive goes through power cycle.

4. Default state should be 000Fh.

e. Using set feature change the interval to 0 , Disable Health Check, and using get feature check that the current state and saved state are set to 0h no later than next power cycle.

6. Current and saved state should be 0h even after drive goes through power cycle.

7. Default state should be 000Fh.

h. Using set feature change the interval to 000Fh and using get feature check that the current state and saved state are set to 000Fh no later than next power cycle.

1. Current and saved state should be 000Fh even after drive goes through power cycle.

10. Default state should be 000Fh.

k. If setting this feature is not supported by the device then it shall return a status error code of 0x2 (Invalid Field in Command)

Get Feature PLP Health Check Interval: For Get feature the objectives are to test the following

a. Check the default state of 0xC6 with SEL=01b. It should be 000Fh and should not change over power cycle. Current state selection should not affect the default state.

b. Check the capabilities of 0xC6 with SEL=11b and it should be 5h indicating that this feature is savable, changeable, and not name space specific.

c. Check the current state of 0xC6 with SEL=00b and it should match with Interval selection made with set feature.

4. Check the saved state of 0xC6 with SEL=10b.

e. If this feature is not supported by the controller, then a status error code of 0x2 (Invalid Field in Command) shall be returned.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SPLPI-1 to SPLPI-15, GPLPI-1/2, GETF-1/2, PLP-7

DSSD_26_PLP_Start_Count_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID C0h and get PLP Start Count field value

2. Power cycle the drive

3. Do GetLogPage for LID C0h and get PLP Start Count field value and verify it increased by 1

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_Persistent_Event_Log_Page_Test_Case.py

The objectives for the Persistent Event Log Page test case are to verify the following:

1. Verify that the Persistent Event Log page is supported by the DUT.

2. Verify that the maximum size of the Persistent Event log page reported in the Identify Controller data structure is 5 MiB or greater.

3. If the controller does not have a persistent event log reporting context, then the controller shall abort the command with a status code of Command Sequence Error.

4. Verify that the Supported Events Bitmap field has bits set to 1 indicating support for the following event logs.

   1. Thermal Excursion Event

   2. Telemetry Log Create Event

   3. Sanitize Completion Event

   4. Sanitize Start Event

   5. Format NVM Completion Event

   6. Format NVM Start Event

   7. Change Namespace Event

   8. NVM Subsystem Hardware Error Event

   9. Power-on or Reset Event

   10. Timestamp Change Event

   11. Firmware Commit Event

   12. SMART / Health Log Snapshot Event

5. Verify that the Persistent Event log page events are ordered by timestamp.

6. Verify that each of the following operations increases the TNE in the log page.

   1. power cycle,

   2. controller reset,

   3. subsystem reset,

   4. function level reset,

   5. Format NVM Command.

7. Verify that mandatory events that occur while a reporting context is active are not reported in that reporting context.

8. Verify that the persistent event log reporting context is maintained for at least 5 minutes after the last host access to the log.

9. Verify that mandatory events that occur while a reporting context is not active are reported when the next reporting context is created.

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-9/10/20/21/22/23

DSSD_26_Physical_Media_Units_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID C0h and get physical media units written and read values

2. Perform 128KB sequential writes for 5 minutes

3. Perform 128KB sequential reads for 5 minutes

4. Do GetLogPage for LID C0h and verify physical media units written and read values increased

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_Power_Loss_And_Reset_Events_During_Firmware_Activation_Process_Test_Case.py

Test objectives of this test case is to verify that the device is not left in an unusable state if the firmware activation process is interrupted by the events listed below. The device shall either abort the firmware activation and continue running with the firmware revision that was running at the start of the firmware update process or complete the firmware activation and start running with the new firmware revision.

1. Unsafe Power Cycle,

2. Controller Level Reset,

3. NVM Subsystem Reset,

4. Function Level Reset,

5. PCIe Warm Reset,

6. PCIe Hot Reset.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

FWUP-18

DSSD_26_Power_State_Change_Count_Test_Case.py

This script will run the following tests:

1. Verify Power State Change Count reported in the SMART/Health Information Extended Log has increased by the number of NVMe Power state changes

2. Verify Power State Change Count reported in the SMART/Health Information Extended Log has increased by the number of DSSD Power State changes

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_Purge_Data_By_TCG_Related_Operations_Test_Case.py

Purge Data by TCG related operations Test Case:

The objectives for this test case are to verify the following:

1. That the device accepts and processes the TCG Activate Operation.

2. That the TCG Activate Operation completes successfully.

3. That the device accepts and processes the following TCG related purge commands successfully,

   1. TCG Revert Operation

   2. TCG RevertSP Operation

   3. TCG GenKey Operation

4. That reads to all LBAs complete successfully and return data that is all 0.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-AD-8

DSSD_26_Queue_Depth_And_IO_Queue_Pairs_Test_Case.py

Queue Depth and IO Queue Pairs Test Case

The minimum supported queue depth shall be 1024 per submission queue and the minimum number of IO Queue Pairs shall be 1024.

Verify the Queue pairs by checking MQES. Verify queue depth by checking the controller’s SQES and CQES values.

Create 1024 IO completion and IO submission queues each with Queue Depth of 1024.

Successful completion of these commands verifies Queue depth and Queue pair requirements

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-CFG-5/6/14/15

DSSD_26_Read_Only_Or_Write_Through_Mode_Feature_Test_Case.py

This script will run the following tests:

Default state

The objective is to check that the factory default value of 0xC2 feature is set to Read Only Mode - Get factory default sate of feature 0xC2(ROWTM) and make sure that it is set to RO Mode

Set Feature Read Only or Write Through Mode

For Set feature the objectives are to test the following: a. Get factory default value of feature ROWTM(0xC2) and it should be RO Mode b. Change to Write Through Mode using set feature and using get feature check that the current state and saved state are set to Write Through Mode no later than next power cycle c. Current and saved state should be Write Through Mode even after drive goes through power cycle d. Default state should be Read Only Mode e. Change to Normal Mode using set feature and using get feature check that the current state and saved state are set to Normal Mode no later than next power cycle f. Current and saved state should be Normal Mode even after drive goes through power cycle g. Default state should be Read Only Mode h. Change to Read Only Mode using set feature and using get feature check that the current state and saved state are set to Read Only Mode no later than next power cycle i. Current and saved state should be Read Only Mode even after drive goes through power cycle j. Default state should be Read Only Mode k. If setting this feature is not supported, then a status error code of 0x2 (Invalid Field in Command) shall be returned

Get Feature Read Only or Write Through Mode

For Get feature the objectives are to test the following: a. Check the default state of 0xC2 with SEL=01b.It should be Read Only Mode and should not change over power cycle. Current state selection should not affect the default state. b. Check the capabilities of 0xC2 with SEL=11b and it should be 101b indicating that this feature is savable, changeable, and not name space specific c. Check the current state of 0xC2 with SEL=00b and it should match with Read Only, Write Through or Normal selection made with set feature d. Check the saved state of 0xC2 with SEL=10b e. Check whether smart page critical warning is reflecting ROWTM settings or not f. Check drive is in RO, WT or Normal Mode state by performing IO

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

ROWTM-1, SROWTM-1 to SROWTM-17, GROWTM-1/2, GETF-1/2

DSSD_26_SMBus_Data_TTR_Verification_Test_Case.py

This script will run the following tests:

1. Do a power cycle

2. Get timestamp

3. Poll MI Basic subsystem management data structure command code 0 until it’s successful

4. Get timestamp

5. Verify MI Basic subsystem management data structure command code 0 info is correct

6. Verify difference between timestamps is within CAP.TO

7. Repeat steps 1-6 using controller reset

8. Repeat steps 1-6 using NSSR

9. Repeat steps 1-6 using FLR

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/4/7/9/10

DSSD_26_SMBus_Data_Verification_256_Bytes_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure with offset 0 and length 154 bytes

2. Get MI Basic subsystem management data structure with offset 154 and length 102 bytes

3. Verify various fields return correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/5/6/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_0_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 0 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_154_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 154 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/8/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_167_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 167 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_242_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 242 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/5/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_248_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 248 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_32_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 32 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/39/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_50_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 50 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_8_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 8 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/9/10

DSSD_26_SMBus_Data_Verification_Cmd_Code_90_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 90 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/4/9/10, FB-CONF-6, MS-CONF-6

DSSD_26_SMBus_Data_Verification_Cmd_Code_96_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 96 and verify it returns correct info

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/9/10

DSSD_26_SMBus_Firmware_Update_Verification_Test_Case.py

This script will run the following tests:

1. Verify disabling Firmware Update using Basic Management SMBus Block Write command and verifying using SMBus Read Byte command.

2. Verify enabling Firmware Update using the SMBus Write Byte protocol

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/3/4/5/6/7/9/10, FB-CONF-6, MS-CONF-6

DSSD_26_SMBus_Invalid_Transaction_Test_Case.py

This script will run the following tests:

1. Send the NVMe Basic Management Block Read command with any invalid SMBus slave address

2. Verify that NVMe Basic Management command does not complete successfully

Pass/Fail: Script passes if all info is correct

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/2/3/4/7/9/10

DSSD_26_SMBus_Secure_Boot_Failure_Verification_Test_Case.py

This script will run the following tests:

1. Get MI Basic subsystem management data structure command code 242 and verify it returns correct info

2. Inject secure boot failure

3. Power cycle the drive

4. Issue Identify command and verify it passes

5. Get MI Basic subsystem management data structure command code 242 and verify it returns correct info

6. Get MI Basic subsystem management data structure command code 0 and verify it returns correct info

7. Power cycle the drive

8. Issue Identify command and verify it passes

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SMBUS-1/3/5/6/9/10

DSSD_26_Sanitize_Operation_Block_Erase_Test_Case.py

Sanitize Operation Block Erase Test Case

The objectives for the Sanitize Operation Block Erase test case are to verify the following:

1. That the device properly indicates support for the Sanitize Block Erase operation in Identify Controller data including verification support.

2. That the Sanitize Status Log Page correctly reports the Sanitize Operation status.

3. That the Sanitize command completes successfully.

4. That the DUT enters the Media Verification State if all necessary conditions are met.

5. That the Sanitize Operation Block Erase completes successfully.

6. That if AERs are submitted and AENs enabled by the host, the device sends a correctly formatted AEN to the host on successful completion of the sanitize operation.

7. When the Sanitize Operation is completed successfully the previously written namespace data cannot be read back.

8. The Sanitize Block Erase operation shall sanitize 1TB of capacity every 10s.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-AD-7/8/17/18/26, SEC-4, STD-LOG-9/10, CTO-8, NVMe v2.0d Section 5.16.1.25/5.27.1.19/5.24/8.21

postcondition(dut)

Execute Postcondition

DSSD_26_Sanitize_Operation_Crypto_Erase_Test_Case.py

Sanitize Operation Crypto Erase Test Case

The objectives for the Sanitize Operation Crypto Erase test case are to verify the following:

1. That the device properly indicates support for the Sanitize Crypto Erase operation in Identify Controller data including Media Verification support.

2. That the Sanitize Status Log Page correctly reports the Sanitize Operation status.

3. That the Sanitize Status Log Page reports a value in the Estimated Time for Crypto Erase field that is greater than 0, not equal to FFFFFFFFh, and matches the value in Adaptation data.

4. That the Sanitize command completes successfully.

5. That the DUT enters the Media Verification State if all necessary conditions are met.

6. That the Sanitize Operation Crypto Erase completes successfully.

7. That if AERs are submitted and AENs enabled by the host, the device sends a correctly formatted AEN to the host on successful completion of the sanitize operation.

8. When the Sanitize Operation Crypto Erase is completed successfully the previously written namespace data cannot be read back.

9. That if No-Deallocate After Sanitize bit cleared to 1b, reads of sanitized LBAs complete successfully and return data that is randomized garbage regardless of whether the LBA were previously written, unwritten, or deallocated.

10. That if No-Deallocate After Sanitize bit cleared to 0b, reads to sanitized LBAs complete successfully and return data that is all 0s regardless of whether the LBA were previously written, unwritten, or deallocated.

11. The Sanitize Crypto Erase operation completes within 10s.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-AD-7/8/18/26 SEC-4 STD-LOG-9/10 CTO-7/9/10 NVMe v2.0d Section 5.16.1.25/5.27.1.19/5.24/8.21

postcondition(dut)

Execute Postcondition

DSSD_26_Sanitize_Operation_Overwrite_Erase_Test_Case.py

Sanitize Operation Overwrite Erase Test Case

The objectives for the Sanitize Operation Overwrite Erase test case are to verify the following:

1. That, if supported, the device properly indicates support for the Sanitize Overwrite Erase operation in Identify Controller data and as per Adaptation data.

2. That the Sanitize Status Log Page correctly reports the Sanitize Operation status.

3. That the Sanitize command completes successfully.

4. That the Sanitize Operation Overwrite Erase completes successfully.

5. That if AERs are submitted and AENs enabled by the host, the device sends a correctly formatted AEN to the host on successful completion of the sanitize operation.

6. If the Sanitize Operation Overwrite Erase is completed successfully, the previously written namespace data cannot be read back.

7. That if No-Deallocate After Sanitize bit cleared to 1b, reads to sanitized LBAs return data that matches the overwrite pattern used regardless of whether the LBA were previously written, unwritten, or deallocated.

8. That if No-Deallocate After Sanitize bit cleared to 0b, reads to sanitized LBAs complete successfully and return data that is all 0s regardless of whether the LBA were previously written, unwritten, or deallocated.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-AD-7/8/18, SEC-4, STD-LOG-9/10, NVMe v2.0d Section 5.16.1.25/5.27.1.19/5.24/8.21

postcondition(dut)

Execute Postcondition

DSSD_26_Sector_Size_Test_Case.py

This script will run the following tests:

1. The device supports both 512-byte and 4096-byte sector sizes

2. The device is configured from the factory with the default sector size specified by OCP requirements per form factor

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SECTOR-4, MS-CONF-1/2, NSM-2/3

DSSD_26_Security_Version_Number_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID C0h

2. Check Security Version field against parameterization data

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_Shutdown_Notification_And_Status_Test_Case.py

Shutdown Notification and Status Test Case

The objectives of the Shutdown Notification and Status test case are as follows:

1. That the shutdown notification completion is received within 10 seconds of a normal shutdown if RDT3 Entry Latency is 0.

2. That the shutdown notification completion is received within RDT3 Entry Latency seconds of a normal shutdown if RDT3 Entry Latency is greater than 0.

3. That the shutdown notification completion is received within 10 seconds of an abrupt shutdown if RDT3 Entry Latency is 0.

4. That the shutdown notification completion is received within RDT3 Entry Latency seconds of an abrupt shutdown if RDT3 Entry Latency is greater than 0.

5. That the device supports both Normal and Abrupt shutdown notifications.

6. That the CAP.NSSS is cleared to 0 indicating that the device shall not support NVM Subsystem Shutdown.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TTR-5/6/23

DSSD_26_Subsystem_Reset_Test_Case.py

This script will run the following tests:

1. Execute NSSR

Pass/Fail: Script passes if NSSR is successful

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMeR-1

DSSD_26_TCG_Activity_Events_For_Persistent_Event_Log_Test_Case.py

The objective for the TCG Persistent Event Log is to verify the following:

1. Perform all TCG methods according to TCGHST-PE-2 requirements.

   1. Level 0 Discovery

   2. Start Session

   3. Authenticate method (entries only recorded when the authority specified is not locked out)

   4. Close Session by the host when it sends an End-Of-Session token

   5. Close Session due to timeout

   6. Properties method

   7. Stack Reset

   8. TPer Reset

   9. Get method

   10. Set method

   11. GenKey method

   12. Random method

   13. Activate method

   14. Revert method

   15. RevertSP method

   16. Reactivate method

   17. Erase method

   18. Block SID Authentication

   19. Assign method

   20. Deassign method

2. To generate a sufficient number of persistent log entries (at least 100 entries), the Assign and Deassign methods will be invoked multiple times.

3. Utilize the Get Log Page command to retrieve the persistence event log page.

4. Verify that the “Total Number of Events” increment at least 100.

5. Verify that all methods invoked above are logged in the event log entries except SyncSession method.

6. Verify that all the TCG Activity PEL entries comply with OCP 2.5 requirements in the TCG Activity Event Format Table.

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

TCGHST-PE-1 - TCGHST-PE-5 TCGCE-1 - TCGCE-24 TCG-AUTHM-1 - TCG-AUTHM-3 TCG-ACT-1 TCG-ACT-2 TCG-RACT-1 TCG-RACT-2 TCG-ASGN-1 TCG-ASGN-2 TCG-BSID-1 TCG-BSID-2

DSSD_26_TCG_Authentication_PIN_Codes_Of_16_Bytes_And_32_Bytes_For_All_Authorities_Test_Case.py

TCG Authentication - PIN codes of 16 bytes and 32 bytes for all authorities Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that TCG devices shall enforce a minimum password length (C-PIN PinLength of 16) of 16 bytes for all TCG Opal authorities, TCG-AUTH-1.

2. Verify that TCG devices shall allow a password length (C-PIN PinLength of 32) of at least 32 bytes for all TCG Opal authorities, TCG-AUTH-2.

3. Set a 16-byte PIN for the SID PIN.

4. Start a session as SID authority with the 16-byte PIN.

5. Set a 32-byte PIN for the SID PIN.

6. Start a session as SID authority with the 32-byte PIN.

7. Set a 16-byte PIN for the Admin1 PIN.

8. Start a session as Admin1 authority with the 16-byte PIN.

9. Set a 32-byte PIN for the Admin1 PIN.

10. Start a session as Admin1 authority with the 32-byte PIN.

11. Set a 16-byte PIN for the User1 PIN.

12. Start a session as User1 authority with the 16-byte PIN.

13. Set a 32-byte PIN for the User1 PIN.

14. Start a session as User1 authority with the 32-byte PIN.

15. Repeat step 11 - step 14 for all for all users from User1 to User16.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-AUTH-1 - TCG-AUTH-2 TCG-LOCKING-6 TCG-AUTH-5

DSSD_26_TCG_Authentication_Tries_And_TryLimit_Test_Case.py

TCG Authentication - Tries and Trylimit Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that the DUT shall set the default TryLimit to 10 for all TCG Opal authorities, TCG-AUTH-3.

2. Start a session as SID authority with incorrect PIN 10 times. Verify that the error code (NOT_AUTHORIZED) is returned by the DUT.

3. Verify that the error code (AUTHORITY_LOCKED_OUT) is returned by the DUT even when the correct PIN is used after the number of tries reaches the limit.

4. Start a session as Admin1 authority with incorrect PIN 10 times. Verify that the error code (NOT_AUTHORIZED) is returned by the DUT.

5. Verify that the error code (AUTHORITY_LOCKED_OUT) is returned by the DUT even when the correct PIN is used after the number of tries reaches the limit.

6. Start a session as User1 authority with incorrect PIN 10 times. Verify that the error code (NOT_AUTHORIZED) is returned by the DUT.

7. Verify that the error code (AUTHORITY_LOCKED_OUT) is returned by the DUT even when the correct PIN is used after the number of tries reaches the limit.

8. Perform a power cycle

9. Verify that the value of the tries has been cleared.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-AUTH-3

DSSD_26_TCG_Communication_Layer_And_Session_Layer_Test_Case.py

TCG Communication Layer and Session Layer Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that the ComID management is supported by the DUT.

2. Verify that the MaxComIDTime is at least 120 seconds, TCG-COMM-4.

3. Verify that the MaxComIDTime is greater than DefSessionTimeout, TCG-COMM-5.

4. Verify that at least 2 Read-Only Sessions is supported per SP and is indicated by MaxReadSessions, TCG-SES-2.

5. Verify that A single Read-Write Session is supported per SP and is indicated by MaxSessions, TCG-SES-1.

6. Verify that the default DefSessionTimeout is 90,000 milliseconds, TCG-SES-4.

7. Verify that the MaxSessionTimeout is 0, TCG-SES-5.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-SES-1 - TCG-SES-5 TCG-COMM-1, TCG-COMM-4 - TCG-COMM-5

DSSD_26_TCG_Communication_Layer_Static_Session_Test_Case.py

TCG Communication Layer - Static Session Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that the 2 Static ComIDs are supported by the DUT, TCG-COMM-2.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-COMM-2

DSSD_26_TCG_Configuration_Log_Page_C7h_Block_SID_Authentication_Test_Case.py

The objective for the TCG Block SID Authentication is to verify the following:

1. Verify that the “C_PIN_SID Authentication Blocked”, TCGL-1 bit[1], will be set to 1(Blocked) upon successful completion of the Block SID Authentication command.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCGL-1

DSSD_26_TCG_Configuration_Log_Page_C7h_Programmatic_Count_Test_Case.py

The objective for the TCG Programmatic count is to verify the following:

1. Verify that the Programmatic TCG Reset Count(TCGL -17) and Programmatic TCG Reset Lock Count(TCGL -18) have been updated correctly after performing a programmatic reset.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCGL-17 - TCGL-18

DSSD_26_TCG_Configuration_Log_Page_C7h_Test_Case.py

The objective for the TCG Configuration Log Page C7h is to verify the following:

1. Verify that the default values of the log page shall be cleared to 0.

2. Perform TCG activate method to locking SP.

3. Perform TCG assign method to assign Namespace non-Global Range Locking object for all Namespaces exist on the device.

4. Verify that the number of Locking Objects, Number of Range Provisioned Locking Objects, and Number of Namespace Provisioned Locking Objects have been updated accordingly and correctly.

5. Perform TCG set method to enable ReadLockEnabled, WriteLockEnabled, ReadLocked, and WriteLocked.

6. Verify that the Number of Read Locked Locking Objects, Number of Write Locked Locking Objects, Number of Read Unlocked Locking Objects, and Number of Write Unlocked Locking Objects have been updated accordingly and correctly.

7. Perform TCG revert method to Locking SP.

8. Verify that the Locking SP Revert Count has increased.

9. Perform TCG revert method to Admin SP.

10. Verify that the TPer Revert Count has increased.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCGL-1 - TCGL-16, TCGL-19 - TCGL-22

DSSD_26_TCG_Implementation_Requirements_Additional_Datastore_Table_Test_Case.py

TCG Implementation Requirements - Additional Datastore Table

Add high level functional description of test case including any assumptions and test case specific tables.

1. Devices that support TCG functionality (i.e., TCG devices) shall implement the specifications in accordance with the additional requirements in section 12.5.

2. This section focuses on the validation of the Additional DataStore Table.

3. Activate LockingSP with 5 additional datastore tables and each table being 128KB in size.

4. Verify that the each DataStore table’s Row column from the Table table are set as the value in Activate method.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-FEATURE-7

DSSD_26_TCG_Locking_Security_Provider_Admin_Authority_Test_Case.py

TCG Locking Security Provider - Admin Authority Test Case

Add high level functional description of test case including any assumptions and test case specific tables.

2. Verify that the locking objects can be assigned, deassigned, and the ReadLockEnabled and WriteLockEnabled can be enabled using admin authorities from Admin1 to Admin4. TCG-LOCKING-6.

3. Verify that ReadLocked and WriteLocked are only enabled after a power cycle is performed, PCI-33.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-LOCKING-6 PCI-33

DSSD_26_TCG_Locking_Security_Provider_K_AES_256_Test_Case.py

TCG Locking Security Provider - K_AES_256 Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that the K_AES_256 Table is supported by the DUT, TCG-LOCKING-3.

2. Verify that the K_AES_256 Table’s Key columns shall not be readable by the host or be accessible outside the device in any manner, TCG-LOCKING-4.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-LOCKING-3 TCG-LOCKING-4

DSSD_26_TCG_Locking_Security_Provider_Lock_On_Reset_Test_Case.py

TCG Locking Security Provider - Lock On Reset Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that any attempt to remove the Power Cycle reset type from a LockOnReset column set value is rejected, TCG-LOCKING-5.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-LOCKING-5

DSSD_26_TCG_Locking_Security_Provider_Number_Of_Locking_Ranges_Test_Case.py

TCG Locking Security Provider - Number of Locking Ranges Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Retrieve Level 0 Discovery from the device.

2. Retrieve Identify Namespace dataset from the device.

3. Verify that the Number of Locking Objects Supported should be greater than or equal to the maximum number of NVMe namespaces supported on the device, TCG-LOCKING-1.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-LOCKING-1

DSSD_26_TCG_Locking_Security_Provider_Test_Case.py

TCG Locking Security Provider Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that the device shall support at least one User per Locking Range, TCG-LOCKING-2.

2. Activate Locking SP.

3. Enable User authorities from User1 to User16.

4. Give ReadLocked access control and WriteLocked access control of the locking object to corresponding user. E.g., give LO1 access to User1, LO2 access to User2, and continue in this manner from User1 to User16.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-LOCKING-2

DSSD_26_TCG_Operation_Execution_Time_Verification_Test_Case.py

TCG Operation Execution Time Verification Test Case:

For the TCG operations listed in the TCG Operation Table, the CTO test objectives are to verify that each validly formatted TCG command completes successfully within 10 seconds under the following scenarios:

1. Host level TCG commands executed sequentially resulting in TCG Operations being sent to DUT via Security Send/Receive commands,

2. Host level TCG commands issued in the presence of a stressing background I/O workload.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

CTO-1/2/3/6/8/11

DSSD_26_TCG_Session_Layer_Session_Timeout_Test_Case.py

TCG Session Layer - Session Timeout Test Case:

Add high level functional description of test case including any assumptions and test case specific tables.

1. Open a session to Admin SP as SID Authority and set 10000 msec to SessionTimeout.

2. Idle 10 msec.

3. Verify that the session has been aborted.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-SES-7

DSSD_26_TCG_Transactions_Test_Case.py

TCG Transactions Test Case

Add high level functional description of test case including any assumptions and test case specific tables.

1. Verify that TCG devices shall support TCG Transactions, TCG-TRAN-1.

2. Verify that the TCG Transactions supported by the DUT conform to the definitions in the TCG Core specifications.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-TRAN-1

DSSD_26_TCG_Version_And_Features_Firmware_Update_Test_Case.py

TCG Version and Features - Firmware Update Test Case

Add high level functional description of test case including any assumptions and test case specific tables.

1. Assign Namespace Global Range Locking object 1 for Namespace 1.

2. Download the N-1 firmware and commit with CA 3.

3. Verify that the NamespaceID of LO1 is the same as assigned in step 1.

4. Assign Namespace Global Range Locking object 2 for Namespace 2.

5. Download the normal firmware and commit with CA 3.

6. Verify that the NamespaceID of LO2 is the same as assigned in step 4

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-FEATURE-5 TCG-AUTH-5

DSSD_26_TCG_Version_Features_And_Requirements_Test_Case.py

TCG Version, Features and Requirements Test Case

Add high level functional description of test case including any assumptions and test case specific tables.

1. Devices that support TCG functionality (i.e., TCG devices) shall implement the specifications in accordance with the additional requirements in section 12.5.

2. Send Level 0 Discovery to the DUT to retrieve the data and verify that the mandatory functionality is supported by the DUT.

3. Verify that the RevertSP and Revert are supported by the DUT.

4. Verify that the PSID is supported by the DUT.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TCG-FEATURE-1 - TCG-FEATURE-4

DSSD_26_Test_NSID_Values_In_Set_Feature_C2h_Test_Case.py

This script will run the following tests:

1. Using NSID = 0 in the set features command passes as expected

2. Using NSID = 1 in the set features command fails with status code 02h

3. Using NSID = FFFFFFFFh in the set features command fails with status code 02h

4. Using NSID = NN+1 (invalid NSID) fails with status code 02h

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SROWTM-6

DSSD_26_Test_NSID_Values_In_Set_Feature_C3h_Test_Case.py

Test NSID Values in Set Feature (C3h) Test Case

This test case is intended to verify the following:

1. That when using NSID = 0 in the Set Features command, the command completes successfully.

2. That when using NSID = 1, or any other active NSID, in the Set Features command, the command is aborted with status code 0Fh for “Feature Not Namespace Specific”.

3. That when using NSID = 2, or any other inactive but valid NSID, in the Set Features command, the command is aborted with status code 0Fh for “Feature Not Namespace Specific”.

4. That when using NSID = FFFFFFFFh in the Set Features command, the command completes successfully.

5. That when using NSID = NN+1, or any other invalid NSID, in the Set Features command, the command is aborted with status code 02h for “Invalid Field in Command”.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SDAEC-6

DSSD_26_Test_NSID_Values_In_Set_Feature_C4h_Test_Case.py

This script will run the following tests:

1. Using NSID = 0 in the set features command passes as expected

2. Using NSID = 1 in the set features command fails with status code 02h

3. Using NSID = FFFFFFFFh in the set features command fails with status code 02h

4. Using NSID = NN+1 (invalid NSID) fails with status code 02h

5. Using NSID = any inactive NSID fails with status code 02h

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

S1667-6

DSSD_26_Test_NSID_Values_In_Set_Feature_C9h_Test_Case.py

Test NSID Values in Set Feature (C9h) Test Case

The objectives of this test case are to verify that the device responds correctly to Set Feature commands with various NSIDs as follows:

1. Using NSID = 0 in the Set Features command completes successfully.

2. Using NSID = 1, or any other valid NSID, in the Set Features command, fails with status code 0Fh for “Feature Not Namespace Specific”.

3. Using NSID = 2, or any other inactive NSID, in the Set Features command, fails with status code 02h for “Invalid Field In Command”.

4. Using NSID = FFFFFFFFh in the Set Features command completes successfully.

5. Using NSID = NN+1, or any other invalid NSID, in the Set Features command, fails with status code 02h for “Invalid Field In Command”. for “Invalid Field In Command”.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SDAEC-6

DSSD_26_Test_NSID_Values_In_Set_Features_C6h_Test_Case.py

This test case is intended to verify the following:

1. Using NSID = 0 in the Set Features command passes as expected.

2. Using NSID = 1 in the Set Features command fails with status code 02h.

3. Using NSID = FFFFFFFFh in the Set Features command fails with status code 02h

4. Using NSID = NN+1 (invalid NSID) fails with status code 02

5. Using NSID = any inactive NSID between 1 and NN (valid NSID) fails with status code 02hI

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SPLPI-6

DSSD_26_Time_To_Admin_And_IO_Ready_Test_Case.py

The objectives of the Time to Admin and IO Ready test case are as follows:

1. Perform a controller reset and verify that the device successfully responds to Identify commands within DP-CFG-8 seconds (from Adaptation data) after setting CC.EN=1.

2. Perform a controller reset and verify that the device successfully responds to I/O commands within DP-CFG-9 seconds (from Adaptation data) of setting CC.EN=1.

3. Perform a safe power cycle and verify that the device successfully responds to Identify commands within DP-CFG-8 seconds (from Adaptation data) after setting CC.EN=1.

4. Perform a safe power cycle and verify that the device successfully responds to I/O commands within DP-CFG-9 seconds (from Adaptation data) of setting CC.EN=1.

5. Perform an unsafe safe power cycle and verify that the device successfully responds to Identify commands within DP-CFG-8 seconds (from Adaptation data) after setting CC.EN=1.

6. Perform an unsafe power cycle and verify that the device successfully responds to I/O commands within DP-CFG-9 seconds (from Adaptation data) of setting CC.EN=1.

7. Ensure that device complies TTR-4 and with DP-CFG-10 is if column B is supported.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

TTR-1/2/4, DP-CFG-8/9/10

DSSD_26_Timestamp_Feature_Test_Case.py

The objectives of the test case are as follows:

1. Default state

   The objective is to verify that the 0Eh timestamp feature is supported by the DUT.

   1. Get the Identify Controller Data for DUT and verify that the timestamp feature is set as supported in ONCS field.

   2. Issue a Get Features command with select field set to 011b for timestamp feature (0Eh) and verify that feature is not saveable from the command status.

2. Basic functionality

   For testing basic functionality, the objectives are to test the following:

   1. Using set features for Timestamp feature (0Eh), set the timestamp to X milliseconds and using Get Features check that the value returned is greater than X for all subsequent Get features before NVM Subsystem Reset.

   2. Verify that Timestamp Origin value in Timestamp Attribute field is not set to 000b before NVM Subsystem reset is issued.

   3. Verify that Synch value in Timestamp Attribute field is not set to 1b.

3. Persistence

   For testing persistence of timestamp value across controller level resets, objectives are to test the following:

   1. Issue Controller Level Reset and verify the timestamp value read after reset is not reset to 0 and continues to count for duration of reset.

   2. Also verify the Synch value is not set to 1b in Get Features command status indicating timestamp did not stop in between reset handling.

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

NVMe-OPT-2/4/5/13

get_nvme_timestamp_feature_value()

Returns the value of /sys/module/nvme_core/parameters/nvme_timestamp_feature

Parameters:

None

Return type:

Integer value

DSSD_26_Total_NUSE_Test_Case.py

This script will run the following tests:

1. Precondition the device to have a single namespace

2. Verify that the values of NUSE in Identify Namespace and Total NUSE in LID C0h are the same

3. Calculate the temporary namespace capacity to use, factoring in the namespace granularity descriptor size

4. Delete the namespace

5. Create, attach and write to namespaces, from 1 to MNAN/NN value

6. Power cycle the device and delay for 10 minutes

7. Verify that the Total NUSE value reported in LID C0h is equal to the value of total NUSE summed over all the namespaces created

8. Delete all of the namespaces

9. Create and attach a new namespace

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_UUID_Test_Case.py

This script will run the following tests:

1. Verify that the UUID List obtained by using the NVMe Identify Command using CNS=17h contains the UUID value C194D55BE0944794A21D29998F56BE6F in big endian format as shown below:

   [——————–Bytes——————–] 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 6F BE 56 8F 99 29 1d A2 94 47 94 E0 5B D5 94 C1

2. Verify that sending Get/Set Feature commands with vendor unique FIDs and the UUID index = matching UUID Index complete successfully.

3. Verify that Get/Set Feature commands with valid vendor unique FIDs and UUID index = 0 complete successfully.

4. Verify that Get/Set Feature commands with valid vendor unique FIDs and UUID index = invalid index fail with Invalid Field in Command status.

5. Verify that the Get Log Page commands with valid vendor unique LIDs and the UUID index = matching UUID Index complete successfully.

6. Verify that the Get Log Page commands with valid vendor unique LIDs and the UUID index = 0 complete successfully.

7. Verify that the Get Log Page commands with valid vendor unique LIDs and invalid UUID index fail with Invalid Field in Command status.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

UUID-1/2/3/4/5/6

get_latency_monitor_values(dut, get_log_c3_input=None)

Receives the values stored in a Latency Monitoring Log (C3h), returning each field

Parameters:

• dut (XML_API) – Device object under test

• get_log_c3_input (dict) – Latency Monitor Log Page dictionary

Returns:

data – Value of all lmdata fields

Return type:

int

issue_get_features(dut, uuid_index, starting_step, check_sc=False, orig_values=None, orig_values_pristine=None)

Issues a series of get-feature commands and verifies if they are successful

Parameters:

• dut (XML_API) – Device object under test

• uuid_index (int) – Index to be used for UUID

• starting_step (int) – Step to start incrementing from throughout the loop

• check_sc (bool) – bool flag to check for expected failure status

• orig_values (list) – List of original feature values to check against

• orig_values_pristine (list) – List of original feature values (before reversing the bit order for use in Set Features) to check against

Returns:

get_feat_values

Return type:

list

issue_log_pages(dut, uuid_index, starting_step, check_sc=False)

Issues a series of GetLog Page commands and verifies if they are successful

Parameters:

• dut (XML_API) – Device object under test

• uuid_index (int) – Index to be used for UUID

• starting_step (int) – Step to start incrementing from throughout the loop

• check_sc (bool) – bool flag to check for expected failure status

Return type:

None

issue_set_features(dut, uuid_index, get_feat_values, starting_step, check_sc=False, data_buffer='')

Issues a series of set-feature commands and verifies if they are successful

Parameters:

• dut (XML_API) – Device object under test

• uuid_index (int) – Index to be used for UUID

• get_feat_values (list) – List of values from get features for FIDs 0xC2, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8, 0xC9, 0xC3

• starting_step (int) – Step to start incrementing from throughout the loop

• check_sc (bool) – bool flag to check for expected failure status

• data_buffer (hex) – Data buffer

Return type:

None

obtain_values(current_states)

Returns valid values to set in the Set Features commands from the Get Features values

Parameters:

current_states (dict) – Dictionary of FID to value

Returns:

• get_feat_values (dict)

• get_feat_values_pristine (dict)

DSSD_26_Unaligned_IO_Test_Case.py

This script will run the following tests:

1. Power cycle the device

2. Do GetLogPage for LID C0h and verify Unaligned I/O field is 0

3. Send 10 4KB sequential write I/O commands starting at LBA 1

4. Do GetLogPage for LID C0h and verify Unaligned I/O field increased by at least 10

5. Power cycle the device

6. Do GetLogPage for LID C0h and verify Unaligned I/O field is 0

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SLOG-1/3/4/10, STD-LOG-23, SMART-1/2/12-28/30-33

DSSD_26_Unsafe_Shutdowns_Verification_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID 2h and get Unsafe Shutdowns field value

2. Surprise power cycle the drive 10 times

3. Do GetLogPage for LID 2h and get Unsafe Shutdowns field value and verify it increased by 1

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-2/3/18/23, SLOG-1/3/4/5/11

DSSD_26_Unsupported_Command_Verification_Test_Case.py

This script will run the following tests:

1. Verify reserved Admin and NVM opcodes in the table return an “invalid command opcode” error

2. Verify unsupported optional Admin and NVM opcodes in the table return an “invalid command opcode” error

3. Verify unsupported vendor unique Admin opcodes in the table return an “invalid command opcode” error

4. Verify every supported vendor unique Admin opcode that requires challenge-response action to unlock returns an error

5. Verify unsupported vendor unique NVM in the table return an “invalid command opcode” error

6. Verify every supported vendor unique NVM that requires challenge-response action to unlock returns an error

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SEC-19

DSSD_26_Unsupported_Feature_Verification_Test_Case.py

This script will run the following tests:

1. Do GetFeatures and SetFeatures for every reserved FID in the table and verify “invalid field” error is returned

2. Do GetFeatures and SetFeatures for every unsupported optional FID in the table and verify “invalid field” error is returned

3. Do GetFeatures and SetFeatures for every unsupported vendor unique FID in the table and verify “invalid field” error is returned

4. Do GetFeatures and SetFeatures for every supported vendor unique FID that requires challenge-response action to unlock and verify an error is returned

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SEC-19

DSSD_26_Unsupported_Log_Pages_Verification_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for every reserved LID in the table and verify “invalid log page” error is returned

2. Do GetLogPage for every unsupported optional LID in the table and verify “invalid log page” error is returned

3. Do GetLogPage for every unsupported vendor unique LID in the table and verify “invalid log page” error is returned

4. Do GetLogPage for every supported vendor unique LID that requires challenge-response action to unlock and verify an error is returned

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

SEC-19

DSSD_26_Unsupported_Requirements_Log_Page_Test_Case.py

This script will run the following tests:

1. Verify Unsupported Requirements Log Page, LID = C5h, default values are set to values as specified in OCP document.

   1. Reserved fields “URLP-2” and “URLP-4” are cleared to zero.

   2. Log Page Version field “URLP-5” is set to one.

   3. Log Page GUID field “URLP-6” is set to C7BB98B7D0324863BB2C23990E9C722Fh

2. Collection Unsupported Count, “URLP-1.” Verify that nonzero values in Unsupported Requirement list matches with Unsupported Count.

3. Verify that Requirement IDs in Unsupported Requirements list matches with Unsupported Requirement ID passed in Adaptation Parameters file.

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.6 requirements referenced by this script:

URLP-1/2/3/4/5/6

DSSD_26_Write_Read_Command_And_Data_Verification_Test_Case.py

This script will run the following tests:

1. Do GetLogPage for LID 2h and get values of various fields

2. Perform 4KB random reads and writes for 65 minutes

3. Do GetLogPage for LID 2h and verify the various fields increased

Pass/Fail: Script passes if all tests pass

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

STD-LOG-2/3/18/23, SLOG-1/3/4/5/11

DSSD_26_Write_Uncorrectable_Test_Case.py

The objective of this test case is to verify the NVME IO requirements NVMe-IO-10 and NVMe-IO-14

1. The device’s support for NVMe Write Uncorrectable command is verified by issuing the NVMe Write Uncorrectable command.

2. LBAs that were written using the Write Uncorrectable command should fail read operations. These read errors should not increase the value of the SMART/Health information field Media field.

3. The case where the WUSL field in the Identify Controller dataset(CNS==6) is 0 and bit-1 of the ONCS field in the Identify Controller dataset(CNS==1) is also 0 shall be treated as a controller error and test case failure.

4. In the case where the WUSL field in the Identify Controller dataset(CNS==6) is greater than 0, WUSL shall be used to set the value of MAXLBAS using Identify Controller(CNS==1) and Identify Namespace(CNS==0) data as 2^(WUSL + 12 + CAP.MPSMIN) / 2^LBA Format[FLBAS].

5. Verify that when the WUSL field in the Identify controller dataset(CNS==6) is greater than 0 and bit-1 of the ONCS field in the Identify Controller dataset is 0 and the host sends a Write Uncorrectable command with an NLB value greater than that specified by the value of WUSL, the controller shall abort the Write Uncorrectable command with Invalid Field in Command.

6. The case where the WUSL field in the Identify Controller dataset(CNS==6) is 0 and bit-1 of the ONCS field in the Identify Controller dataset(CNS==1) is 1 shall be treated as the controller is not specifying a maximum size. In this scenario, MAXLBAS shall be computed using Identify Controller(CNS==1) and Identify Namespace(CNS==0) data as 2^(MDTS + 12 + CAP.MPSMIN) / 2^LBA Format[FLBAS].

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-IO-1/3/4/5/6/7/8/9/10/11/12/13/14, GETF-2

DSSD_26_Write_Zeroes_Test_Case.py

The objective of this test case is to verify the NVME IO requirements NVMe-IO-4, NVMe-IO-5, NVMe-IO-6 and NVMe-IO-7.

1. The device’s support for NVMe write zeroes commands is checked by issuing NVMe Write Zeros command.

2. Verify that the NVMe read command send after the NVMe Write Zeroes command with DEAC=0 and FUA=0 returns all zeros.

3. Verify that the NVMe read command send after the NVMe Write Zeroes command with DEAC=0 and FUA=1 returns all zeros.

4. Verify that the NVMe read command send after the NVMe Write Zeroes command with DEAC=1 and FUA=0 returns all zeros.

5. Verify that the NVMe read command send after the NVMe Write Zeroes command with DEAC=1 and FUA=0 returns all zeros.

6. Verify that the NVMe Write Zeroes command with DEAC=1, FUA=0, can deallocate the full capacity of the DUT in less than 1 minute.

7. The case where the WZSL field in the Identify Controller dataset(CNS==6) is 0 and bit-3 of the ONCS field in the Identify Controller dataset(CNS==1) is also 0 shall be treated as an error and test case failure.

8. In the case where the WZSL field in the Identify Controller dataset(CNS==6) is greater than 0, WZSL shall be used to set the value of MAXLBAS using Identify Controller(CNS==1) and Identify Namespace(CNS==0) data as 2^(WZSL + 12 + CAP.MPSMIN) / 2^LBA Format[FLBAS].

9. Verify that when the WZSL field in the Identify controller dataset(CNS==6) is greater than 0 and bit-3 of the ONCS field in the Identify Controller dataset is 0 and the host sends a Write Zeroes command with an NLB value greater than that specified by the value of WZSL, the controller shall abort the Write Zeroes command with Invalid Field in Command.

10. The case where the WZSL field in the Identify Controller dataset(CNS==6) is 0 and bit-3 of the ONCS field in the Identify Controller dataset(CNS==1) is 1 shall be treated as the controller is not specifying a maximum size. In this scenario, MAXLBAS shall be computed using Identify Controller(CNS==1) and Identify Namespace(CNS==0) data as 2^(MDTS + 12 + CAP.MPSMIN) / 2^LBA Format[FLBAS].

Open Compute Project Datacenter NVMe SSD Spec v2.5 requirements referenced by this script:

NVMe-IO-1/3/4/5/6/7/8/9/10/11/12/13/14, GETF-2