两次编译收发器产生不同现象，但时序分析都是过的

[NZhan1]

Hi

有个比较奇怪的现象，Q17.1.2Pro编译出来的A.jic,下载到12块A10板卡上，有一块板子的1G/10GbE and 10Gbase-KR PHY的TX通道测试没有发出数据，而位于同一个PHY的RX通道却是正常的。工程里根据参考设计做了时序约束，只有几条时序违例：JTAG的相关时钟，FPGA给光模块disable信号，link引出的指示灯信号。

再次编译出B.jic，下进去就没有问题了。

两次编译的时序情况一致，​第二次比第一次的slack稍大一点，但都是正值。

请问针对收发器需要做什么特殊约束吗？导致同一个PHY的TX和RX会有不同的现象​。

[CheePin_C_Intel]

Hi,

As I understand it, you observe that by using A.jic into 12 A10 boards, one of the board's TX has no output. However, when you generate a new B.jic and download into the previously failing board, the TX is working fine.

Please see my comments as following:

1. Just would like to check with you if the B.jic generation involved recompilation of design?

2. If new compilation took place, the routing and timing of the design might be different as this is a new compilation, even though the SDC constraints remain the same. This could explain why you are observing differently between compilation.

3. Specific to the XCVR PHY, for your information, generally you would only need to constrain the top level input clocks as start. The PHY would have SDC to take care of the internal constraints. If you observe timing violation related to the other top level ports, you may then slowly constrain from there. 

4. Just wonder if you have had a chance to try with the latest Quartus version ie 20.1? Just to ensure you are using the latest version with the most bug fixed.

Please feel free to let me know if you would require timing expert to further assist on the timing constraint of your design.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

[NZhan1]

Hi Chee, Thanks! Yes, the B.jic is from a recompilation. I understand that recompilation will cause differences on place and route, so there will be timing differences. But the timing analysis results of the two compilations are all met. Only B’s slack is slightly larger than A’s. Currenly customer use 17.1.2 Pro, hasn’t try 20.1Pro I have customer’s project database file, only is too large to transfer. Are you able to received files on Baidu Cloud? Thanks a lot! Regards， Nicole

[CheePin_C_Intel]

Hi Nicole,

Thanks for your update. I understand that two different compilation has led to different observation and the issue is only observed in a specific board. 

To further narrow down the issue of TX no output, just would like to check with you on the following:

1. After you download the A.jic to the failing board, just wonder how do you verify that there is no output signal from TX? Are you using oscilloscope to check?

2. Just wonder if you have had a chance to try downloading the raw A.sof to the failing board to see if there is any different in observation?

3. Just would like to check with you if you have had a chance to check on the tx_analogreset, tx_digitalreset, tx_ready, tx_cal_busy and pll_locked signals to see if there is any anomaly.

4. Please help to check on the tx_clkout and tx_pma_clkout to see if there is any valid clock and what is the frequency.

5. Please help to try with latest Q20.1 to see if you can get consistent builds.

As for the cloud, I believe I am unable to retrieve the file from there. Thanks for your help. However, we shall perform debugging from the above perspectives first. We shall engage timing team after further narrowing down.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

[NZhan1]

Hi Chee Thanks for your suggestions! For 4, there is no timing violation on these two clocks. How can I check tx_clkout and tx_pma_clkout to see if there is any valid clock and what is the frequency? Use a pin out? Thanks! Regards， Nicole

[CheePin_C_Intel]

Hi, You can tap these signals using signaltap or route the signals to an output pin and monitor at the oscilloscope. In signaltap, we are trying to see if there is any clock signal activities. With scope, we can verify the signal as well as if it is of the right frequency. Generally when the clkout is having correct frequency, the TX should be working. Thank you. Best regards, Chee Pin

[NZhan1]

Hi Chee,

Edit Answer

There is slightly difference between PLL setting and Timing analyzer results. The PLL generated clock, with frequency of 156.25mhz, has 6.397ns period, not 6.4ns. Is that ok?

Customer checked the tx_analogreset, tx_digitalreset, tx_ready, tx_cal_busy and pll_locked and none is abnormal.

Customer update from Q17.1 to Q18,1Pro, and the tx abnormal issue happened everytime when customer do compilation. And the tx_analogreset, tx_digitalreset, tx_ready, tx_cal_busy and pll_locked is as attached file.

Could you help to check the timing constrain?

Thanks!

Regards，

Nicole

[NZhan1]

please change the name from project_database.001.zip​ to project_database.zip.001 and unzip the 4 files together

[NZhan1]

please change the name from project_database.002.zip​ to project_database.zip.002 and unzip the 4 files together

[NZhan1]

please change the name from project_database.003.zip​ to project_database.zip.003 and unzip the 4 files together

[NZhan1]

please change the name from project_database.004.zip​ to project_database.zip.004 and unzip the 4 files together

[CheePin_C_Intel]

Hi Nicole,

Sorry for the delay. Thanks for the update. Please see my response to your inquiries as following:

1. The PLL generated clock, with frequency of 156.25mhz, has 6.397ns period, not 6.4ns. Is that ok?

[CP] There should be no issue with this. This might be due to rounding in the timing analyzer.

2. Customer checked the tx_analogreset, tx_digitalreset, tx_ready, tx_cal_busy and pll_locked and none is abnormal.

[CP] As I check through the signaltap, there is no issue with the TX and the tx_ready is asserted. based on this, there is no issue with the XCVR TX and it is ready to transmit data output.

3. As I understand it, our customer observe this issue on in one of the board. The other 11 boards have no issue. Based on this, this seems to be something specific to the board instead of the design or timing related. Just wonder if our customer has had a chance to look into the board ie power supplies or other components to see if there is any anomaly vs the normal board.

4. To further narrow down the XCVR issue with the failing board, would you mind to create a simple Native PHY test design, place it onto the failing TX channel, then measure the output signal using oscilloscope to see if you are observing similar not TX output issue?

5. Just wonder how do you verify that there is no output signal from TX? Are you using oscilloscope to check?

6. Please help to check on the tx_clkout and tx_pma_clkout to see if there is any valid clock and what is the frequency.

7. Just would like to check with you if our customer has had a chance to build a simple duplex design with 1G/10G PHY IP and then perform internal serial loopback to see if the RX is able to receive data correctly? Just to isolate any potential SI issue.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

[CheePin_C_Intel]

Hi Nicole,

For your information, the project that you are sharing seems of relatively large file. I am unable to download the project. Sorry for the inconvenience.

However, as per my previous note, this seems unlikely to be related to timing as it only occurs in a specific board but not others. Would you mind to share with me the top level SDC file so that I can have a quick look?

Please help to ask our customer to perform the debugging as recommended in my previous notes.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

[NZhan1]

Hi Chee Since I can’t login the Forum right now. So I send the top sdc to your personal email. And currently, customer upgrade the project to 18.1Pro, and the tx failure issue occurs everytime after rerun compilation. And the TX failure issue happens on many other boards. It is not just on one board now. There are some changes of timing constrains requirements between 17.1pro and 18.1pro. will these be the reason of TX failure? Thanks! Regards， Nicole

[CheePin_C_Intel]

Hi, For your information, due to the change in the observation, it is rather difficult to tell what might be wrong. Please help to perform the debug items as in my previous note. You may want to prioritize the serial loopback and the simple native PHY design testing. Also, would you mind to elaborate if our customer is using oscilloscope to check on the TX output signal? If not, how did they check the signal when they are referring to no output. Thank you. Best regards, Chee Pin

[NZhan1]

Hi Chee, Customer uses two boards connected together to test if it has output or not. Thanks! Regards， Nicole

[CheePin_C_Intel]

Hi Nicole, Thanks for your update. For your information, when our customer is connecting two board together, it is rather difficult to tell if it is TX no output or there is other issue which lead to the link not up. Thus, I would recommend our customer to using one board, the probe the output signal with oscilloscope to check on the TX signal. This will be helpful to further narrow down the issue. Thank you. Best regards, Chee Pin