UniPro: Implementing Power Mode Change completion in Fail Safe way

Ramesh Hanchinal, R&D Engineer at Synopsys and Member of MIPI UniPro Working Group contributed the write up below, describing common question by designers using UniPro about power mode change implementation.

Power Mode Change defined in specification

The Local initiates Power mode change by transmitting the PACP_PWR_req packet. It waits for the reception of PACP_PWR_cnf packet. Once the PACP_PWR_cnf is received, local configures the local MPHY for new settings and closes its transmit burst.
The Local starts the PACP_REQUEST_TIMER with value PA_PACPReqEoBTimeout. This is to wait for reception of EoB. If the Remote PA Layer does not close the burst within this period, the Local PA Layer shall abort the Power Mode request and pass PA_LM_PWR_MODE_CHANGED.ind(PWR_FATAL_ERROR) to the DME. The DME in-turn issues FATAL ERROR to the application layer. If Local receives EoB before timer expiry, then Power Mode Change process completes successfully.
Here EoB is MK2 marker symbol defined by MPHY. Its position marked with red circle in Figure 1 & Figure 2.

Figure 1: Power Mode Change using PACP_PWR_req and PACP_PWR_cnf

Possible out of sync between link partners

As per Figure Local receiving EoB means Remote PA Layer is closing the burst. If UniPro implementation is done as per this understanding, then it can lead to possible out of sync situation between the link partners or between local UniPro & MPHY.
Consider the scenario where link is in HS-G3. Local wants change link from HS-G3 to HS-G1 speed. Hence Local sends PACP_PWR_req with this request. Remote accepts this request and transmits PACP_PWR_cnf accordingly. Refer Figure 2 which shows RX Data RMMI interface to show PACP_PWR_cnf packet reception on Local side. Thus PACP exchange happens perfectly between the link partners. Respective UniPro’s configure their MPHYs for this setting. After that Local sends the EoB and closes the transmit burst (TxBurst). After receiving this EoB Remote transmits EoB and closes it’s transmit burst (TxBurst).
But due to link error or whatsoever reason the Remote transmitted EoB (MK2 symbol) got corrupted. Shown in red circle in Figure 2. Therefore, Local does not receive EoB, but subsequently it observes receive burst (RxBurst) getting closed. Since Local implementation is expecting EoB to be received to consider remote has closed the burst, it will treat this situation as no burst closure. Hence, once the PACP_REQUEST_TIMER expires it issues PowerModeChange status as FATAL_ERROR to the application.
Now this can lead to either of the 2 circumstances.
1. If Local UniPro withdrew the local MPHY configuration considering it as un-successful PowerModeChange then, Local UniPro stack will stay in HS-G3 configuration. Whereas Remote UniPro stack continues to stay in HS-G1. Because for Remote the PowerModeChange process is successful.
2. If Local UniPro does not change the MPHY configuration then, once the RxBurst closes the MPHY will get configured for HS-G1 settings. Whereas UniPro still concludes this as PowerModeChange failure and indicates accordingly to the application layer. Hence remains in HS-G3.
Both the scenarios lead to out of synchronization between the link partners or in the entire system.

Figure 2: Local RX Data RMMI Interface

Fail safe way to deal the issue
Implementation shall not have the restriction that “Reception of EoB is the only way to decide successful completion of PowerModeChange process”. Instead it can expect reception of EoB but if failed to receive the same before RxBurst closure then RxBurst going Low shall take precedence to indicate successful completion of PowerModeChange process.
With such implementation, even if the EoB reception is missed due to whatsoever reason the PowerModeChange process itself completes successfully by watching RxBurst going low. This implementation approach keeps coherence in the system and acts as fail safe mechanism.

Ramesh Hanchinal bio:
Ramesh started his carrier as R&D engineer in RTL development and later worked on validating the IP on FPGA prototyping. This gave Ramesh insights into the big picture about challenges involved in IP development. He transitioned into functional verification engineer. During these various roles, he majorly worked on protocols like PCI & PCI-Express. These protocol knowledge and prototype validation gave him PC system knowledge. Later roles like verification architect & involvement in IP RTL development helped him to deepen his system level knowledge.
Working on UniPro IP exposed to the battery operated hand held devices. This further took him to understand how the UFS solution is evolving in smartphones, mobile and automotive. Ramesh joins MIPI face-to-face meetings and represents Synopsys as MIPI UniPro working group contributing member.

If you like to read this or other previous posts, send this URL to your friends and tell them to Subscribe to this Blog.
To SUBSCRIBE
One option to subscribe is as follows:
• Go into Outlook
• Right click on “RSS Feeds”
• Click on “Add a new RSS Feed”
• Paste in the following “http://feeds.feedburner.com/synopsysoc/sqLy?format=xml”
• Click on “Accept” or “Yes” or whatever the dialogue box says.