Updated: April 30, 2021
SW v2.6.0.8558
Revisions
Contact support@protocolinsight.com for the latest test case revisions.
Interpretations
Some sections of the UFS and UniPro spec, especially UFS JESD220C and JESD224A, have ambiguities that require interpretation. In order to complete the development of the Falcon tests Protocol Insight have made certain interpretations but other interpretations could be equally valid. These interpretations could alter the results of the following test cases:
| Test Case | Issue |
| JESD224A 7.3.3 | Protocol Insight interprets the JESD224A Annex A changes to 7.3.3 to mean that the check of the value for BUSY TIMEOUT PERIOD was changed from 0xffff to 0x0000. On page 279 of JESD224A Clause 7.3.3 states that the BUSY TIMEOUT PERIOD was changed from FFFF to 0000h; there is ambiguity in this section since JEDEC did not explicitly use the term BUSY TIMEOUT PERIOD twice in the sentence
Protocol Insight believes that the intention is for the value to be 0000h and thus a value of FFFF will fail. |
| JESD224A 7.4.2 | 7.4.2 tries to change BUSY TIME PERIOD which the 2.1 spec states is not changeable, thus this test case shall not be ran. |
| JESD224A 7.5.4, 7.13.6, 7.15.1, 7.15.2 | In the JESD220C Table 10-12 Flags definition for COMMAND UPIU it says that when R and W are both set to zero then no data transfer is required. Whenever we have a command and we expect only a response with no associated DATA IN then both the flags are set to 0. |
| JESD224A 8.4.15 | JESD224A states ‘Test may be applied if bConfigDescrLock is set to 01h’ which implies that the test can be run if the DUT descriptor bConfigDescrLockis is set to 00h or 01h. However, if the test is run with bConfigDescrLock is set to 00h the test will fail.
If the test fails because bConfigDescrLock is set to 00h the failure should be disregarded. |
| JESD224A 8.6.17 | This test references the dCorrPrgBlkNum attribute that is obsolete in the UFS 2.1 JESD220C specification. However this test was not removed from JESD224A CTS test specification.
Protocol Insight recommends disregarding this test. |
| JESD224A 8.6.28, 8.6.29 | The purpose of these tests is to verify how the device behaves when setting bMaxDataInSize attribute. JESD220C table 14-27 Attributes states that bMaxDataInSize shall not exceed the bMaxInBufferSize parameter (JESD220C table14-3 Geometry Descriptor).
These JESD224A CTS tests stipulate that the attribute bMaxDataInSize be set to a value N where N != the original value read for bMaxDataInSize. If the device has a bMaxInBufferSize of 08h and bMaxDataInSize is also 08h then then we must set it to a LOWER VALUE (in this case something < 08h since that is what bMaxInBufferSize is). Some manufacturers do not support a value of bMaxDataInSize < 08h so the test will fail. Note that this test does not fail if the value of bMaxInBufferSize is less restrictive (much bigger than 08h). If the device does not support smaller legal bMaxDataInSize values than bMaxInBufferSize the failure should be disregarded. |
| JESD224A 8.6.31, 8.6.32 | The purpose of these tests is to verify how the device behaves when setting bMaxDataOutSize attribute. JESD220C table 14-27 Attributes states that bMaxDataOutSize shall not exceed the bMaxOutBufferSize parameter (JESD220C table14-3 Geometry Descriptor).
These JESD224A CTS tests stipulate that the attribute bMaxDataOutSize be set to a value N where N != the original value read for bMaxDataOutSize. If the device has a bMaxOutBufferSize of 08h and bMaxDataOutSize is also 08h then then we must set it to a LOWER VALUE (in this case something < 08h since that is what bMaxOutBufferSize is). Some manufacturers do not support a value of bMaxDataOutSize < 08h so the test will fail. Note that this test does not fail if the value of bMaxOutBufferSize is less restrictive (much bigger than 08h). If the device does not support smaller legal bMaxDataOutSize values than bMaxOutBufferSize the failure should be disregarded. |
| JESD224A 8.11.13 | JESD224A requires that the test steps be executed for all configured logical units, which would include well-known LUs such as REPORT LUNS, UFS Device, Boot, RPMB. Yet per JESD220C the Task Management CMD is not allowed for the well-known LUN and the device response should be an Incorrect LU Number. This is different from Expected output and will cause a failure.
Protocol Insight recommends disregarding failures associated with invalid LUNs. |
| JESD224A 7.8.3 | Protocol Insight believes that it is the UFS host’s responsibility to set task tags such that it can associate all the packets from the device with a given command. Based on the UFS 3.0 spec there can be 32 LUN and up to 255 outstanding tasks per LUN, thus in theory up to ~8160 outstanding tasks. Given that the task tag field can only support 255 unique values the host must find other ways to track incoming packet from the DUT if there are more than 255 outstanding commands.
However, there is some ambiguity interpreting task tag assignment in the spec so Protocol Insight has changed the way task tags are incremented with v1.6.4 so that each outstanding task has a unique task tag. |