Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Xilinx Kintex-7 FPGA Temperature Problem

Status
Not open for further replies.

strahd_von_zarovich

Advanced Member level 4
Full Member level 1
Joined
Sep 25, 2015
Messages
119
Helped
1
Reputation
2
Reaction score
3
Trophy points
1,298
Activity points
2,475
Hi everyone,
I have designed a FPGA board, and started testing it. My problem is that FPGA resets itself when it reaches the temperature of 45 degrees and I can not program bitsream unless the temperature falls down to ~28 degress. Actually, I can program it but as soon as I upload bitsream it resets itself. I monitor the temperature using Vivado and XADC .
I have disabled the over temp protection in configuration register.

Has anyone encountered such a problem?
 

Hi,

45° ad 28° are no critical temperatures, thus I guess the root problem is else where.

If it´s really a temperature problem:
Maybe there is an external short that causes heating of the die. So the internal temperature may be (much) higher than the case temperature .. maybe even only on a part of the die.

A lot of "maybe".

Debugging:
Try to program a different bitfile just all I/Os defined as INPUT_with_PULLUP and see what happens.

Klaus
 

I agree with the comment from Klaus.
I have worked with bitsreams running at a FPGA die temp of nearly 105 degrees (measured using the FPGAs internal XADC), no problems.

Can you elaborate more on "FPGA resets itself"?
How have you interfaces the XADC with your design?
 

I'd rather suspect power supply drop below POR threshold as reset reason. Suggest to monitor supply voltages and currents. If the problem starts with bitstream download, there's probably a programmed short, as already mentioned. Alternatively a non-functional supply may already drop at regular currents. Problems of this kind should be identified during basic hardware verification, before loading a bitstream.
 

Hi,

45° ad 28° are no critical temperatures, thus I guess the root problem is else where.

If it´s really a temperature problem:
Maybe there is an external short that causes heating of the die. So the internal temperature may be (much) higher than the case temperature .. maybe even only on a part of the die.

A lot of "maybe".

Debugging:
Try to program a different bitfile just all I/Os defined as INPUT_with_PULLUP and see what happens.

Klaus
Dear Klaus,
Thanks for the answer. I used different bitstreams even with very simple project(with only one LED). Only temperature rise time changes.

I used very complex project with microblaze and lots of IPs, and also very simple project. The only change is time.

And If I use heatsink with fan, and prevent FPGA from reaching 45 degrees then everything works fine. However, I couldn't figure out why it stops working at 45 degrees, and why I can not program it unless the temp falls down to ~28 degrees(which is much more weird.)

I also monitor power consumption using power supply, I didn't see any suspicious current draw.
 

Just to give you an idea. I had similar problem and it was because one of the resistor of the dcdc converter was not really a resistor but it looks like that. The BOM was wrong and the assembler mount a RTC instead of a resistor. Therefore when the temperature changes, the value of the RTC located in the resistor divider changes and the output of the dcdc converter was not right supplying the fpga wrongly
 

45 degrees where? on the case or on the die? 45 degrees on the die is NOT a problem.

Maybe you’ve got an IO pin shorted? This would only manifest as a problem when the device is programmed.
 

Actually, I can program it but as soon as I upload bitsream it resets itself.

What do you know about this "reset"? I think that if you investigate more about the root of this reset you may have some additional hint. Measure the voltages from FPGA (Core, aux, IO, usually 1.0V/1.8V/3.3V), does any of them fall? If yes, you should investigate why this happens. Or perhaps the PROGRAM_B pin is set?

If you find the reset trigger you can have a better understanding of what is happening.
 

Hi,
I used different bitstreams even with very simple project(with only one LED).
"simple project" is not what you have to care for.

You have to care for the IOs.

If there is an external short to GND on an IO and you drive (maybe by compiler default) the same pin HIGH, you get high temperature. You see the situaltion in the FPGA supply current.

If there is an external short to VCC on an IO and you drive (maybe by compiler default) the same pin LOW, you get high temperature. You don´t even see theis situation in the FPGA supply current. (because it is FPGA_GND current)

Also don´t leave (unused) pins floating. This may also lead to high supply current and high temperature.

Thus I recommended to drive all unused pins "INPUT_PULLUP".

Klaus
 

Hi Everyone,
I found the problem when I was testing the second board. Fortunately, I couldn't program the second board at all. Then I realized that the IC which is connected to the reset circuitry didn't provide right output. Turns out, I did a mistake on the logic level. While the IC was expecting a voltage above 2V at it's input, the voltage was 1.6V. Somehow, the IC on the first board managed to work(not properly obviously) when the board was cold. Then, when the board got heated, probably it's logic high level changes a little which mislead me to think that the problem was about the FPGA.

Thanks everyone.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top