- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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会有不同的现象。
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Chee,
Edit AnswerThere 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
please change the name from project_database.001.zip to project_database.zip.001 and unzip the 4 files together
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
please change the name from project_database.002.zip to project_database.zip.002 and unzip the 4 files together
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
please change the name from project_database.003.zip to project_database.zip.003 and unzip the 4 files together
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page