Cypress USB3 4603 HX3 DVK Violating PENDING_HP_TIMER

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
MoNa_2346666
Level 1
Level 1

Based on the 3.1 Standard (Table 7-7), the PENDING_HP_TIMER has a 3 us value.  However, I see certain cases that Cypress Hub violates this timer marginally by about ~100-200ns. In our test setup, these recoveries happen quite frequently and eventually hit another condition where four of them happen consecutively forcing the link into Inactive.

I’ve attached a LeCroy’s trace to this post. This trace was collected where the Cypress Hub(1) is immediately after a Host and our device is connected to one of the Hub’s downstream port. In this trace, packet 784 (LGOOD_5 for the first of three Header Packets) is seen 3.110 us after packet 779 (the first of three Header Packets waiting for LGOOD).  As the result, the timer has violated the Standard by 110ns.

The setup is:

Host ('See Note1) -- Cypress Hub(1)  --- LeCroy Analyzer -- Our Testing Unit --- Cypress Hub(2) ---Other Devices(See Note2)

Host runs camera app for the camera device, and burning tests on other devices

Note1: Windows 10 Version: 1803, OS build: 17134.471 running on Asus Prime Z370-A, Core i5-8400 with 16Gb DDR4 Ram

Intel USB 3.0 eXtensible Host Controller – 1.0, Version: 10.0.17134.1

Note2:  i) Samsung T5 SSD, Kingston Datatraveller G4, Verbatim Dog Tag 2.0 Flash Drive, Intel Realsense Camera D415

Has anyone else seen similar issue, and could someone explain what possibly is going on in this setup forcing the timer to fire?

Thanks,

Mohsen

0 Likes
1 Solution

Hi Mohsen,

Your calculations are correct. However, we would have gone into Recovery state if it really would have been a violation as per the Spec. I think this could be because of the timeout value being within the tolerance limit of the PENDING_HP_TIMER.

We have carried out Compliance tests for HX3 in the past which also include the Link Layer tests on various systems and havent seen any failures.

Best Regards,

Sananya

View solution in original post

0 Likes
5 Replies
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Mohsen,

The traces you attached show a LGOOD_5(784) sent by the host for the Transaction Packet(779) sent by device after 3.110us. Hence the violation even if it exists seems to be from the host side. The latest USB 3.2 standard mentions a timeout value of 10us in Table 7-7.Our assumption is that the traces were taken between the host and Cypress Hub(1).

Best Regards,

Sananya

0 Likes

Hi Sanaya,

It seems I have not been quite clear in my post.  The trace has been collected between Cypress Hub(1) and Our Testing Unit. I have now edited my original post to show this explicitly.  The fact that the LecCroy trace marks the packets as H and D is how it shows which packet is from a Downstream Port (H) and which one is from the Upstream Port (D).

Therefore, based on my testing results, I can confirm that it is Cypress Hub sending LGOOD_5, violating the 3 us timer.

On the USB 3.2 having a 10 us for this timer, I'm aware of it. However, the Hub we are using is a 3.0 and our system is a 3.1. As such, we are not assuming a larger than 3 us value for this timer.

Thanks,

Mohsen

0 Likes

Hello Mohsen,

Thanks for the clarification; it makes the trace clear now and we have identified the LGOOD_5 packet sent by the hub which exceeds 3 us.

However, if we consider USB 3.0 timer value itself, it is mentioned in the Spec under section 7.2.4.1.13 that the timer period is calculated between the last symbol of the header packet and the last symbol of LGOOD sent. Since we cannot check for the difference in the two symbols from the trace, and it is only exceeding by around 100 nanoseconds, we cannot conclude definitely that it is a violation.

Best Regards,

Sananya

0 Likes

Hi Sanaya,

Thanks for your feedback. It is great that you have identified the portion of the trace pointing to the potential violation.

On your uncertainly to conclude the violation from trace, I'm not sure if I understand your point.  From the trace (the Trace View), and especially from the Link Tracker View of the trace, here is my understanding:

1) TP Packet (packet 779) is sent from our testing unit to Cypress Hub (1) at time stamp (a=5113.471 025 244). This is the time for the first symbol of the packet. From the same view, the duration of the packet is 40.100 ns. That means the time at the end of this packet is b=a+40ns

2) LGOOD_5 (packet 784) is sent to acknowledge by the Hub at time stamp (c=5113.471 028 354). This is the time for the the first symbol of the packet.  From the same view, the duration of this packet is 16.040ns. That means the time at the end of this packet is d=c+16ns

3) Difference between the two packets above (taken at the end symbols of each packet -based on your reference to the Standard-) is: d-b= c+16ns-a-40ns. From the trace and the time stamps c-a=3.110us. Thus, the PENDING_HP_TIMER has been violated by 86ns (=3us-3.11us+16ns-40ns)

Please correct my above calculations and understanding if they are wrong.

Kind Regards,

Mohsen

0 Likes

Hi Mohsen,

Your calculations are correct. However, we would have gone into Recovery state if it really would have been a violation as per the Spec. I think this could be because of the timeout value being within the tolerance limit of the PENDING_HP_TIMER.

We have carried out Compliance tests for HX3 in the past which also include the Link Layer tests on various systems and havent seen any failures.

Best Regards,

Sananya

0 Likes