How to Address the Top 7 JEDEC-UFS Stack Verification Challenges Using Test Suites

If you are currently using or consider using JEDEC UFS protocol in your next design you might face several verification challenges.  The following blog will talk about 7 of the biggest challenges of UFS stack verification. With the fact that people are moving to reduced pin count and increased speed, an MPHY based stack has picked up momentum and provides an increased number of new applications to leverage the UFS stack. The UFS protocol is being adopted rapidly due to its higher performance, efficiency, concurrent multi-tasking, usage of the complete band width, security, and reliability and longer power life.

Verification Challenges

Let’s talk about the above depicted challenges clockwise, starting from the top.

HCI generic Register I/F

• HCI (Host Controller Interface) is register programming in UFS Host Controller, but leaves it open to the user to decide the register interface. This highlights how important it is to keep the hooks simpler for user to integrate their UFS-Host-DUT in the environment with easy RegToBus and BusToReg conversion APIs. Secondly, it also brings in more challenges to convert a friendly UFS UPIU commands conversion into HCI register/memory RD/WR instructions.

Data taping at L1.5, L2, L3, L4 layers

• Synopsys provides a unique use model of the VIP at the intermediate layers which would help the user to verify the DUT at L1.5, L2, L3 or L4 layer independently. This gives us better layered data flows visibility.

Complex Reset scenarios

• Validating abrupt resets for every feature, creating complex reset scenarios for warm and Cold reset and validate pre-post reset conditions. Main challenge is to exercise the abruptly reset any ongoing process and check the retry of the same process post rest with rigorous data transfers and PMC process.

Data Link layer flow control

• Despite the DME interface hooks, UniPro has intermediate layers namely, Transport layer, Network layer, Data Link layer and Physical Adapter layer. One would of course validate the flow of the data from transport to Physical Adapter layer and vice-versa, but the most challenging part is when control SAPs interrupt these flows in between, it’s important that each layer exit the current process and then acknowledge the next later in a graceful manner.
• It’s know that for a given TC0/TC1 frame an acknowledge frame is scheduled from the device which receives the traffic class’s frame. Now interesting point is that the protocol does not say when to schedule the AFC/NAC, hence the verification should have knobs to control the scheduling of the AFC/NAC within the timeout period to avoid any PA_INIT process.
• Secondly, the verification environment should also check if the DUT is clearing all the frame buffers at data link layer which may contain normal frames, re-transmitted frames and control frames on a reset. Here the idea is to re-invoke the pre-reset frames which were not acknowledge yet.
• Create scenarios where there could be interrupts during the DL_PAUSE request and its confirmation. Such cases would validate the correct pause and resume of the data flow between data link and physical adapter layer during entry to Hibernate state, or initiating PA_INIT process or NAC transmissions especially.

Hibernate Process

• Validating configurations for pre-post hibernate entry and exit, Over-lapping Hibernate requests with L4 data transfers, Hibernate request and PMC request PACP frames within one complete PMC request process generation.
• During Hibernate process the important factor stress test the DUT with least hibernate time specified by the protocol and exit immediately after this period. These rules out any additional delays left out which might be overlooked when the timer is more than the minimum required delay.
• Secondly, while exiting from hibernate whether the data link layer is properly un-paused after PA_TActivate time. This could be achieved by sending immediate data followed by hibernate exit process.

PMC process

• Verifying the power mode change from very low speed like PWM_G1 to HS_G3. In this case how the MPHY handles the configuration changes and with least and maximum allowable PA_SaveConfig timers. In such cases the clock change from PWM_G1 to HS_G3 when MPHY is embedded under UNIPRO in Serial mode, ensures stability of the clocking models inside MPHY. Here the minimum SAVE configuration time mentioned in the UNIPRO specification of (40ns) does not suffice the need as MPHY.
• What happens when PMC request is issued when the compatibility of the feature itself is not advertised in the DUT? How do we ensure that if such a request is initiated from DUT and it’s being honored? If honored, whether the PMC was sent with the feature set in the request frame. Such cases check the initiation capabilities of the DUT.
• Creating PMC requests against the DUT capabilities and creating, different configuration request within retries, PMC process over-lapping with L4 data transmissions etc. and Lots more to be discussed later.

Multi-lane skew variations

• As it is a multilane protocol, another interesting factor is to deal with the alignment of on data multi lanes.
• Generation of random skews on multi-lane environment with positive and negative skew between lane-lane.
• Ensure all the data transfers with minimal configuration times after PMC and Hibernate process especially and initiate next process with maximum skew.

Synopsys UFS Test Suite to address above verification challenges

To address all the above verification challenges, Synopsys provide a unique UFS test suite solution. Figure below depicts the ideal solution for the above challenges in UFS stack.

• Synopsys solution for UFS-Host DUT verification, provides easy steps to integrate UFS-Host Controller DUT in UFS-Host Test Suite. The above example shows a ready conversion model for AXI/APB register interface and memory interface to the Host Controller.
• One of the key differentiators is that Synopsys UFS VIP can be configured as standalone HCI-VIP which converts the UPIU sequence information to the register read/write or memory read/write command conversions in the form of “uvm_reg_item” interface. This makes it more generic for the user to play around with the UVM_REG_OBJECT and use this in the existing environment which has a RAL hooked up already. More interestingly a solution should be able to provide all the necessary knobs to create all UFS traffic and re-use the same when VIP acts as HCI or UFS-Host. This way it becomes easier for the user to maintain the test environment, if a standalone HCI is to be embedded in the existing environment. The solution clearly portrays a clean plug and play model for UFS Host DUT integration. Provides easy hooks for register coverage via “uvm_reg_item” interface.
• For all other challenges like PMC, hibernate process, reset scenarios, Data Link layer flow control, multi-lane skew variations UFS Test Suite solution provides an extensive sequence collection covering all tricky aspects of the verification challenges.
• Scoreboard at different layer provision for user to tap in-case need be for intermediate layer score-boarding as well. In the above diagram scoreboard is show at UPIU level for illustration.

Stay tuned for our upcoming blog on “UFS Multi-lane skew Variations.”

 Authored by Tumuluri SantoshaLakshmi