This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
|
Related to: registerChannelRecord = new SetWriteReadRegisterData(writeCommand, 0x82, 0x40, 0x00
Can you confirm that the write value is 0x00 and the write mask is 0x40?
The routine per the programming guide works, TI have validated it extensively.
A couple of debug questions.
Table 54. Register Writes to Clear PRBS Checker Error Count
STEP |
SHARED/ CHANNEL REGISTER SET |
OPERATION |
REGISTER ADDRESS [HEX] |
REGISTER VALUE [HEX] |
WRITE MASK [HEX] |
COMMENT |
1 |
Channel |
Write |
82 |
40 |
40 |
Reset PRBS counter |
2 |
Channel |
Write |
82 |
00 |
40 |
Un-reset PRBS counter |
Thanks,
Rodrigo Natal
Hi Rodrigo,
Following your questions:
register value
0x01 0xd2
0x27 0x11
0x28 0x6c
0x78 0x30
I can confirm that the write value is 0x00 and the write mask is 0x40.
public void ClearPRBSCheckerErrorCount(int address, int die, int channel, byte commandNumber)
{
SetRegisterData regData;
List<SetRegisterData> registerData = new List<SetRegisterData>();
regData = new SetRegisterData(0x82, 0x40, 0x40);
registerData.Add(regData);
regData = new SetRegisterData(0x82, 0x40, 0x00);
registerData.Add(regData);
USBOption.SetMaskRgisterValues((byte)address, (byte)die, (byte)(channel), commandNumber, registerData);
}
public SetRegisterData(byte address, byte mask, byte data,string remarks=null)
{
this.Address=address;
this.Mask=mask;
this.Data=data;
this.Remarks = remarks;
}
Thank you
Hi Jack,
With 01 =0xD2 this means PRBS pattern was detected and the pattern is PRBS9. Does that sound correct?
The retimer shows signal detected and CDR locked and the reported retimer eye opening values are good, thus I would have expected zero BER at the retimer PRBS checker.
Question: Can you provide a full retimer channel registers dump (i.e. read the retimer register values observed in your system) so that I can see all of the settings you are actually applying?
Thanks,
Rodrigo
Hi Rodrigo,
PRBS9 is correct. Normally, the BRE is 0, when I turn off the signal source, the biggest BRE is 2047. Now I want to clear it, but BRE keeps 2047. When I re-initial it, the BRE is 0;
Could you please give me your email address?
Thanks
Jack
Hi,
Please try the below, and see if it solves the issue.
Table. Register Writes to Re-Load PRBS Checker Pattern Match
STEP |
SHARED/ CHANNEL REGISTER SET |
OPERATION |
REGISTER ADDRESS [HEX] |
REGISTER VALUE [HEX] |
WRITE MASK [HEX] |
COMMENT |
1 |
Channel |
Write |
30 |
00 |
08 |
Set prbs_en_dig_clk=0 to disable the digital clock |
2 |
Channel |
Write |
30 |
08 |
08 |
Set prbs_en_dig_clk=1 to enable the digital clock |
3 |
Channel |
Write |
30 |
10 |
10 |
Force reload of PRBS checker seed |
4 |
Channel |
Write |
30 |
00 |
10 |
Undo force reload of PRBS checker seed |
5 |
Channel |
Write |
82 |
40 |
40 |
Reset PRBS counters |
6 |
Channel |
Write |
82 |
00 |
40 |
Un-reset PRBS counters |
7 |
Channel |
Read |
01 |
Read PRBS status: |
Yes, I know that. But why 2047 can not use simply clear BRE,? Reload patterns needs more time. Another question, How can I accumulate PRBS for a long time without losing PRBS ERR Count as little as possible?
You should be able to run the retimer PRBS checker indefinitely as long as the PRBS pattern doesn't change.
Thanks,
I mean, before I read the BRC, it has reached 2047, which means that a part of the count value has been lost. How to ensure that the BRC is read before it reaches 2047?
The clear PRBS checker sequence per the programming guide should clear the errors. if errors max out again do to PRBS checker losing lock/sync then the only other option is to perform the "reload PRBS checker match" sequence.
Rodrigo Natal
The PRBS test duration would depend on what BER level you are verifying for. As example, assume BER target is 1E-12 with data rate of 25.78125Gbps.
Thanks,
Rodrigo Natal