DP83TC812S-Q1: SGMII Interface

Hello Norio,

What is the test setup you have used to create these findings, for instance is it in SGMII back to back? Can you send me a block diagram with the main items of this setup?

Regards,
Avtar

Hi Avtar,

Thank you for your reply.

Diagram is bellow.

PC →(100Base-TX)→　DP83TC811EVM → (100Base-TX)  →　{DP83TC812S-Q1　→ (SGMII) → (uPC:RH850)}   

・{}:On Bord

・Operation Mode

  　DP83TC811EVM:Master Mode

  　DP83TC812S-Q1:Slave Mode                                                                                   

・Send a ”Ping” form PC to uPC,  but uPC detects "CRC error" and "Residual-bit frame receive"

Regards, 

Norio

Sorry, I mistake diagram

Please let me correct it

PC →(100Base-TX)→　DP83TC811EVM → (100Base-T)  →　{DP83TC812S-Q1　→ (SGMII) → (uPC:RH850)}   

Hello Norio, 

To isolate the issue, please perform these two tests on the EVM's by sending packets from the PC to the EVM's in the same orientation as you described.

First do Analog loopback on the DP83TC811 EVM by writing to this Register BISTCR Register 0x0016 – BIST Control Register. 

As you can see here:

You can select analog loopback here .

Next if the analog loopback performs as expected, run reverse loopback on the DP83TC812 EVM by writing to this register  BISCR Register (Address = 16h) [Reset = 0100h] as you can see here: 

You can select reverse loopback here.

Please perform these two tests and let me know the results.

Regards,

Avtar

Hi Avtar,

Thank you for your  help.

※I try two tests.  

※I will  provide you with additional information

・PC＆DP83TC811EVM is not Power Down

・Although I used other Media Converter  (MAC89811_MC2）,   "CRC error"   and   "Residual-bit frame receive"  occur  at uPC .

     Diagram is bellow

      PC →(100Base-TX)→　MAC89811_MC2 → (100Base-T)  →　{DP83TC812S-Q1　→ (SGMII) → (uPC:RH850)}   

   　I think the problem is  DP83TC812S-Q1 or uPC,　So I try  DP83TC812S-Q1 Loopback  first.

※nibble shift 

Regard,

Norio

Hello Norio,

Yes try the DP83TC812 loopback and let me know what you see.

Regards,

Avtar

Hi Avtar,

I am sorry. Loopback has not yet been tested.

--------------------

However, we have observed other phenomena.

I tryed several type of PHY reset,  it looks like below.  

(1)MII reset  adr 0x0000(15)      →  　The niblle misalignment continues.

                                                             (No misalignment condition, I try SGMII reset.  mialignment was occured.)

(2)PCS reset adr 0x3000(15)　  →　　The niblle misalignment continues.

(3)Digital reset　adr 0x001F(14) →　　The niblle misalignment continues.

(4)Software global reset　adr 0x001F(14) → 　The niblle misalignment continues.

(5)RESET_N    →　　The niblle misalignment continues.　

--------------------

(6)SGMII reset  adr 0x0011(11)　→　The niblle misalignment is resolved !.　(9 times try)

         But  no misalignment conditon, I try SGMII reset.  mialignment was occured...                                              

--------------------

What are the possible factors that can cause recovery or error with an SGMII reset?

please give me hints.

Regard,

Norio

Hello Norio,

I am glad SGMII reset fixed your issue, but still let me know the results of the loop back testing. I will consult with my team on the factors of this SGMII reset and get back to you by friday.

Regards,

Avtar

Hello Norio,

Just to clarify, are you seeing this phenomenon on just this board or have you tested this on multiple boards.

Also can you dump the registers 0x0608, 0x0609, 0x060A, 0x060B, 0x060C, and 0x060D when misalignment occurs and when misalignment doesnt occur. 

On a single part, try RESET_N continuously for 100 iterations and let me know how many iterations the misalignment occurs.

Regards,

Avtar 

Hello Norio,

I will consult with my team your findings and get back to you by tomorrow. 

Regards,
Avtar 

Hello Norio,

I see in all the 0x0608 reads sgmii auto neg is disabled, can you please let me know why this is?

Can you try with sgmii auto neg enabled and enable auto neg on the mac side to see if that fixes your issue?

Regards,

Avtar 

Hello Norio,

0x1D56 shows that SGMII auto neg is still disabled the correct value would be 0x1D57. Also I am wondering how Reg 0x0608 value changed from 0x027A to 0x1D56. Either way please ensure bit 0 of the 0x0608 register is set to 1. 

Regards,

Avtar 

Hello Norio,

As seen in the 0x0608 register value being 0x027A, that means that SGMII auto neg is disabled. Change register 0x0608 to 0x027B and retry please. 

Regards,

Avtar

Hello Norio,

From those readings it seems like no error is occurring. Is that the case or is the phenomenon still present after changing 0x0608 to 0x027B. Please run the test multiple times while reading these same registers. If the phenomenon happens again please share the register values for that event.

Regards,
Avtar 

Hello Norio,

For the 2 times that it failed, can you send me the register values from above, the 0x0608, 0x0609, etc

Regards,

Avtar

Hello Norio, 

I will consult with my team on these new findings and get back to you soon. 

Regards,
Avtar

Hello Norio,

Sorry for the delay

I looked into these registers and this looks to be for a good case as there are no errors present, can you please give me the registers for the bad case so we can see the difference between the good case and bad case. 

Regards,

Avtar

Hi Avtar,

Thanks for the comment.

(1）We couldn't see any particular differences.　I retry again several times.

      Please let me know if there are any registers other than the SGMII register that I should check.

(2) SGMII_CTRL_1Register(Address = 608h)

      Could yout tell me  "cfg_align_idx".

(3)Could yout tell me  special requirements for the SGMII startup sequence , if you need.

(4)   We tryed  "SNLA389A  P.9 Table 3-2. Slave Mode Configuration"   as wel.

     　(SNLA389A –DP83TC812, DP83TC813, and DP83TC814: Configuring forOpen Alliance Specification Compliance)

       　When I included  "x0821 to register address  x0873", or  "x0000 to register address  x089E" ,  Link is down．     

　　  These below register are not written datasheets,  Please let me know registers function. Are there reference documents？

　　  Address 0x0523,  0x0834,  0x0873,   0x0896

Regards,

Norio

Hi Avtar,

I retryed SGMII registers.

 I couldn't find the difference.again.

Result OK  w/o autonegotiation 

Result NG  w/o autonegotiation 

Result OK  with autonegotiation 

Result NG  with autonegotiation 

Regards,

Norio

Hello Norio,

Thank you for your quick reply, I will see if I can understand the difference between the Result OK and Result NG. Earlier there were plans to do a loopback test did that ever happen?

Regards,

Avtar

Hi Avtar,

Thank you for your confirmation message.

Loop Back Test was below.

"NG":CPU detected  CRC errer and Residual-bit frame recieve error (Lower Nibble Shift)  sometimes.

------------------------------------------------------------------------

About OK/NG.. (at no loopback)

For Example,  Ping result is here when NG phenomenon.at no loopback. 

In this time,  CPU detected  CRC errer and Residual-bit frame recieve error (Lower Nibble Shift)  

[NG case]

> 　Responce OK

> 　Responce OK

>      Time out.

>     Responce OK

>     Time out.

     ...

[OK case]

> 　Responce OK

> 　Responce OK

> 　Responce OK

    ...  

Regards,

Norio

Hi Norio,

Could you provide a block diagram of your setup for testing loopback (what are the connections and where are the packets being sent). 

Are you able to take a scope capture of the SGMII eye of both the receive and transmit lines? We want to rule out that this is a SGMII signal quality issue. If it is a signal quality issue, we can move on to the layout. 

You can do so by measuring the positive line in one channel1 and the negative line in channel2 and setting the function Channel1-Channel 2 at infinite persistence for a few minutes.

Best regards,

Melissa

Hi Melisa,

Sorry for the late contact.

I tryed SGMII Signals monitor &  8B10B Channel decode, 　I don't know if it's related to this phenomenon, but I noticed one thing.

 (Case1)K27.7(SOP),D21.2-(69times),D21.6-(10times),....

 (Case2)K27.7(SOP),D21.2-(68times),D21.6-(10times),.....

 　　→So,D21.2 is 1sample less.

Regards,

 Norio

Hello Norio, 

Can you explain the K27.7 and other variables in this: 

 (Case1)K27.7(SOP),D21.2-(69times),D21.6-(10times),....

 (Case2)K27.7(SOP),D21.2-(68times),D21.6-(10times),.....

What is the difference between D21.2 and 21.6?

Regards,

Avtar

Hello Norio,

Also can you send me the schematic for the SGMII section?

Regards,

Avtar 

Hi Melisa,

Thanks for the reply.

D21.2 & D21.6 are Ethernet Frame Preamble.

　D21.2: x55, D21.6:xD5　each of them corresponds.

　  Preamnle is {x55,x55,x55,x55,x55,x55,x55,xD5}

When SGMII in 100BASE mode, 

   Expectation：｛(K27.7(SOP),D21.2-(9times),D21.2-(10times) D21.2-(10times),D21.2-(10times), D21.2-(10times),..., D21.6-(10times),....

 Schematic is below.

    DP83TC812S-Q1　→ C(0.1us)→ uPC:RH850

Regards,

 Norio

Hello Norio,

Thank you for your reply and help.

For schematic I meant the design schematic files. If you have those can you send to me?

Regards,

Avtar

Hi Avatar,

Sorry, Schematic file is  confidential information and cannot be uploaded to this site.

So, Would you like to ask for your address?　

※And  can I tell you if the length of the SGMII preamble will be shortened?

Regards,

Norio

Hello Norio,

I will consult with my team and get that information to you shortly.

Thanks,

Avtar 

Hello Norio,

Sorry for the delay, in terms of the SGMII preamble being different is this being set differnet or being altered in a way that you see the error is being produced by the PHY?

Regards,

Avtar

Hi Avatar,

Thanks for the reply.

I haven't changed any of the PHY and Board settings.

Regards,

Norio

SGMII Rx Chanel 8B10B　Decode result

Hello Norio,

Thank you for sharing these details, I will consult these new findings with my team and get back to you.

Regards,

Avtar

Hello Norio,

Apologies for not getting back to you sooner. The SGMII decode result looks normal and without flaw. Are you still running into the CRC error issue? If so we will have to take a different approach. 

Regards,

Avtar 

Hi Avatar

Thanks for the reply.

>The SGMII decode result looks normal and without flaw.

(1)There are 68 cases of Preamble,  So, Is this a device spec (or errata?) or a standard specification?

(2)Is there a range in the number of Preambles?　For example,  Is there  67 or 70 cases?

(3)If it's standard specification, Please tell me referencese.

>Are you still running into the CRC error issue? If so we will have to take a different approach. 

Yes, I still running into the CRC error issue.

So  I could not confirm the shift of the lower nible data to the 8B10B pattern of SGMII,

I feel that it is necessary to confirm whether the fluctuations of Preamble nubmber affect uPC.

Regards,

Norio

Hello Norio,

From my understanding fluctuations of preamble number shouldn't affect uPC I believe the issue lies elsewhere. Are you loading the initialization script found in this app note? 

https://www.ti.com/lit/an/snla389b/snla389b.pdf?ts=1713215215431&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDP83TC812S-Q1

Regards,

Avtar

Hi Avatar,

①We are checking with the uPC  vendor to see if they support Preamble's fluctuations and eop2 duplication.

②We tryed app note 389b with script, few month ago,

      When we set  Register  0x893,x0896,0x89E (P.9 Table 3-2. Slave Mode Configuration ), packet reception is no longer possible.

　  Any hints ?

Hello Norio,

2. Is the link partner in master configuration or slave? 

Regards,

Avtar 

Hi Avtar,

②The link partner (DP83TC811EVM)  is in master configuration.

  Regards,

Hi Norio,

1. SNLA389B has the Config Script for 812

2. This App Note has the config script for 811: https://www.ti.com/lit/an/snla293/snla293.pdf?ts=1713544022753&ref_url=https%253A%252F%252Fwww.google.com%252F

Please make sure you are using correct configurations scripts for both, as they are different.

Best regards,

Melissa

Hi Melissa,

Setting is below.

When we set  812 's register  0x893,x0896,0x89E (P.9 Table 3-2. Slave Mode Configuration ), packet recwe eption is no longer possible.

If you omit these settings, packets can be received.

Does it have anything to do with the Byte shift in nibbles when the SGMII signal received ?

We have sent the explanation file to the Japan subsidiary, so we would appreciate it if you could check it as well.

Regards,

Norio.

Hello Norio,

0x893,x0896,0x89E are more for link up time and arent related to byte shift in nibbles for SGMII.

Can you read register 0x04A0 to see if bit 15-14 are set to high?

Regards,
Avtar

Hi Avatar.

Thank you for your reply.

>0x893,x0896,0x89E are more for link up time and arent related to byte shift in nibbles for SGMII.

I think so too,

>Can you read register 0x04A0 to see if bit 15-14 are set to high?

I'll check it for the time being. but  I don't think there is a problem with the register setting.

・SGMII pattern is not lower nibble byte shift. 

・It is not always misaligned by packets.in NG case. 

*Have you checked the file sent to the Japanese TI Site?

Regards,

Norio.

Hello Norio,

Thank you for clarifying I agree that register 0x04A0 is not the right approach. 

I have no received the file sent to the Japanese TI site, can you email me the file you sent to that site?

Regards,

Avtar

Hi Avatar.

Sure, Please tell me how to send an email  privately.

Regards,

Norio.