Forum Discussion
Cyclone10GX Temperature Issue
Hi,
I use a cyclone 10 gx fpga (10CX150YF780C5G) on my pcie card. One transceiver is used as a 10Gbps fiber link and other 4 transceivers are used as Gen1 Pcie X4 lanes. No external memory interface. The total power consumption is about 2W.
The problem is when fpga's die temperature rises above about 55C, the transceiver that is used to connect the fiber link(SFP) has occurred missing word error in transmitting side. I use the transceiver loopback function to monitor the data both at a remote receiver output and at the local loopback receiver output. They show exactly same fault. It tells us the PCS stage in the transmitter side has something wrong. The reference clock to the transceiver ATX-pll is 644.53125MHz. Other functions in the fpga is working well.
When I lower the temperature by add a fan to blow it, it works normally. Is there any one knowing how to fix it?
Thanks a lot!
25 Replies
- SengKok_L_Intel
Regular Contributor
If further support is needed in this thread, please post a response within 15 days. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.
- SengKok_L_Intel
Regular Contributor
By right, both fPLL (core mode) can IOPLL can be used. However, the physical locations are different between both PLLs, so the routing difference may slightly impact the timing if the design is not optimized.
Usually, this is recommended to use IOPLL if this can generate the expected frequency for the core logic, and preserve the fPLL for high-speed transceiver usage.
- YYang79
Occasional Contributor
Thanks for having been going through this issue so long time with me!
Appreciated!
- SengKok_L_Intel
Regular Contributor
If the LL 10G MAC IP + PHY is working fine in various temperatures range, then it could be due to your custom logic/design timing is not optimize.
- YYang79
Occasional Contributor
Just make it clear, after changing the fPLL to a IOPLL in my code according to the LL 10G MAC IP example design, this is the only change, we have got this temperature issue solved.
My question is what is the difference between these two PLLs when put them into this application?
- SengKok_L_Intel
Regular Contributor
Yes, it sounds good to use the LL MAC 10G MAC IP example design. If the PMA value is not optimal, you may see the high bit error rate when you vary the temperatures.
- YYang79
Occasional Contributor
In LL MAC 10G MAC IP example design rev19.1 an IOPLL is used to generate 156.MHz and 312.5MHz, while in my design I use an fpll instead following the transceiver design guide line. That is the only difference. The example design works well on my board. So I changed my design to use IOPLL . The result is that it can work at high temperature now without error! It is 73C now but it used to fail at 57C.
It looks it is a big improvement at least.
My question is why is like that?
- SengKok_L_Intel
Regular Contributor
For the Bit Error Rate (BER), you probably can play around with the PMA setting. e.g increase the VOD of transmitter
- YYang79
Occasional Contributor
Since there is no bit error by using Toolkit, I don't think we need to adjust the PMA settings. Am I right?
I am currently working on Intel's "Low Latency Ethernet 10G MAC Intel® Cyclone® 10 GX FPGA IP
Design Example" trying to implant it into our board to see what it happens.Do you have any suggestion?
Anyway, thanks a lot.
- SengKok_L_Intel
Regular Contributor
Please do let me know if more help is needed here. Thanks.
- YYang79
Occasional Contributor
Yes. We are still struggling with this thermal issue. We have checked all VCC power supplies to the Cyclone 10. They are all within the specific ranges and there is no big change with the temperature increasing (less than 60mV). We have used Toolkit to test the PMA layer of the transceiver. The result is that there is no bit error under 65C (our problem occurs usually at 64C and below) .
We don't have any obvious clue to fix it now. Any further suggestions are definitely welcome!
- SengKok_L_Intel
Regular Contributor
Hi,
Since this problem can replicate with internal loopback, can you please change the pin assignment as below and determine if there is channel dependency?
set_location_assignment PIN_AF25 -to "SFP_RXD0(n)"
set_location_assignment PIN_AG27 -to "SFP_TXD0(n)"
set_location_assignment PIN_AF26 -to SFP_RXD0
set_location_assignment PIN_AG28 -to SFP_TXD0
Besides, please refer to the attached screenshot, add the interface signals of native PHY to signal tap, and then compare the "tx_parallel_data" and "rx_parallel_data" to determine if there is a mismatch. The data drop may happen before this module.
- YYang79
Occasional Contributor
Hi,
We always test the data at these points. We usually call them xgmii interface. Only difference is a logical conversion of words from big endian to little endian between Native PYH parallel and xgmii. The data at xgmii shows OK.
I will add "tx_parallel_data" and "rx_parallel_data" into my signaltap to see if there is any difference.
- SengKok_L_Intel
Regular Contributor
I found that there is a setup timing violation in your design. I would suggest cleaning the timing first, and determine if the problem still persists.
- YYang79
Occasional Contributor
No improvement with clean timing result.
- SengKok_L_Intel
Regular Contributor
You can click on the Message icon (top right), and then click compose to create new message, from the “send to”, you can find my name over there.
Regards -SK
- SengKok_L_Intel
Regular Contributor
Please refer to the following link (table 1), and check the GXB power supply (e.g. Vcct_GXB, Vccr_GXB, and Vcch_GXB), and determine if there is any difference between a pass and fail case. The FPGA is supposed to work at above 55C, and since you encounter it on multiple boards, so it is suspicious if there is a board issue.
Besides, you can send me a private message with the simple design, so that I can have a sanity check on it. Thanks.