DS90UB936-Q1: AEQ_CTL2 Register Bit 4 Clarification

Hey Jared, 

it depends on what is programmed in 0xD2[4]

Hi Sally,

I do not understand your answer. For both questions I was clear that bit 4 has a value of 1...

-Jared

Hey Jared, 

Sorry I didn't catch that sentence. 

1. i need to test this on an EVM and get back to you. 

2. yes 

Hi Sally,

Any updates on this?

Also, I tested this with a set of EVMs on my side: 913 EVM -> 936 EVM

If I assert PDB on the 913 EVM, I see loss of lock in register 0x4D the 936. Then, when I de-assert PDB, lock is re-established. When I check AEQ_STATUS after lock is re-established, it is not always the floor EQ value. It is totally random which value is presented. Then when I manually restart AEQ by asserting bit 3 of register 0xD2, I get the floor EQ value of 0x02 every time. 

This tells me that when lock is re-established, the AEQ algorithm is not re-running, even though bit 4 of register 0xD2 is a value of 1. It is simply landing on which ever EQ setting it is at and sticking with that value.

The quicker the loss of lock by a quick assertion of PDB makes it easier to see the random values in the AEQ_STATUS register.

Can you please check this on your side? If this is the case, I think the bit 4 description is incorrect.

Thanks,

Jared

Hey Jared, 

I'll check this myself and get back to you tomorrow.

Hi Jared, 

Please see my excel spread sheet of a data dump for AEQ. The red highlighted rows are when I PDB. The green highlighted rows are when LOCK is back up. 
you can see in both scenarios AEQ restarts at an initial value. In one case I set AEQ to start at 0, and in another case I set AEQ to start at 4. The script is also in the excel file. AEQ_restart_testing.xlsx

Thanks, 

Sally 

Hi Sally,

Thank you for the information! However, did you try repeating this experiment several times? When I first started doing the same experiment on my end, I received similar results to yours (through I didn't print things out to the excel file). Then after lots of PDB assertions and de-assertions from the 913, I started seeing much more random values in the EQ register after lock was established. I was just looking at the ALP GUI when doing this.

Please let me know if this is something you can try on your end.

Thank you!

Jared

Hey Jared, 

So I did 13 new trials where I kept toggling PDB on the SER without resetting the DES. I had 2 trials that did not seem to start at 0 and 1 trial where it locked at a different EQ but went back to 0. 
1667.AEQ_restart_testing.xlsx

Hi Sally,

I don't see the 13 tries on the attached spreadsheet. Am I reading it wrong?

For the trails that did not seem to start at 0, where did they start and where did they stop?

Thanks,

Jared

sent the wrong attachment; this one has all 13 trials. the start/stop values for those cases in the files labeled "Sheetx_non0"

1581.AEQ_restart_testing.xlsx

Hi Sally.

Thanks for sending. It would appear that you are seeing the same thing as me then.

Can you please provide an explanation as to why the device wouldn't go back to its floor EQ setting every time? I imagine nothing is getting worse regarding the cabling, connectors, or channel in general between PDB resets..

My feeling is that there is some sort of race condition between AEQ and LOCK. If you look at the data you sent, whatever the value is of EQ at the time when lock is re-established (register 0x4D goes from 0xX0 to 0xX3), that is what gets put in as the EQ setting. It does not seem like the device is waiting until lock is clearly established and then runs AEQ. What do you think of this theory? If that is the case then I would say the datsheet description for bit 4 of 0xD2 is incorrect.

Please let me know what you think. 

Thanks!

Jared

Hey Jared, 

I need to check internally and get back to you on this. It's not clear to my why AEQ is not starting at 0. AEQ begins running once link is re-established, and stops once it locks unless there are errors in which case it will increment 

Thanks, S
ally 

Hey Jared, 

just wanted to let you know I have not forgotten this thread and I am still talking to the team internally about this. Hope to have an update in 1-2 days. 

Thanks, 

Sally