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

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

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

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

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

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

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

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

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