ICE5LP4k SG48 voltage feeding through IO pin 48 - Page 1
Forum section: electronics / general

author: hostile
author_rank: Contributor
timestamp: October 07, 2021, 07:04:28 pm
content: The powering up sequence works for my ICE5LP4K device when I have pin 48 of the SG48 package disconnected. When I connect it to another ICE40 device it is communicating with it causes it not to power up. It appears that the IO being driven or pulled up to 3.3V somehow feeds the voltage through the fpga pin to my 1.2V and 3.3V power supplies. There is nothing else connected to the net, so I am unsure how it would be passing to it. Is there something particular about pin 48 that causes it to pass voltage into the voltage supplies when the device has not come up ?Steps to Reproduce (If Applicable):power up board without any voltage on pin48. Apply 2-3.3V on pin 48 and observe 2.1 volts on 3.3 Voltage net and 400mV on 1.2V supply. powering up does not work because the voltages did not come up cleanly.

author: Someone
author_rank: Super Contributor
timestamp: October 07, 2021, 11:30:24 pm
content: From your short description it sounds a lot like back feeding from the pin to the power rails through protection/catch diodes. The IO aren't hot pluggable and must be kept within the Vccio rail voltage (so at 0V when the Vccio rail isn't powered).If there is uncontrolled voltage on the power rails then you may be violating the power sequencing requirements (hence no boot).Solution: only enable the driving source of that pin/interface once all the chips are up.

author: hostile
author_rank: Contributor
timestamp: October 08, 2021, 03:30:55 pm
content: Yes, it seems the voltage is back feeding through the IO pins. The pin that is coming in is a miso that is already being driven by a different board. I do not have a way to guarantee the other board won’t come up before the flag. I could of used a line driver or buffer to keep voltage off the pin, but I wouldn’t of thought that voltage could pass through the fpga IOs before it was powered up. Figured it would be high Z

author: asmi
author_rank: Super Contributor
timestamp: October 08, 2021, 03:45:19 pm
content: Quote from: hostile on October 08, 2021, 03:30:55 pmThe buffer state doesn't matter because backfeeding is likely happening through ESD protection diode (they are there to provide the path for excess voltage if IO voltage is higher than Vccio). Now, the question is - how does that voltage from Vccio rail makes its way to the Vcore rail. Inspect your PDS very carefully, it's probably the culprit. If you can show us schematics, we could possibly provide a more practical advice, but as it stands I can only offer some general thoughts.

author: hostile
author_rank: Contributor
timestamp: October 08, 2021, 04:55:08 pm
content: I am able to reproduce the voltages being passed through with nothing connected to the net other than an IO of the fpga. I have a test pad that comes off of one of the pads. Supplying voltage on this pin, 2-3 volts passes about 2/3rds to my 3.3V rail and 1/3rd to my 1.2V rail. On the original pin there is an ESD diode between that pin and ground.

author: asmi
author_rank: Super Contributor
timestamp: October 08, 2021, 07:25:56 pm
content: Quote from: hostile on October 08, 2021, 04:55:08 pmCheck carefully if there is there a route from Vccio rail to Vcore on your board. It doesn't matter if specific pin is connected to anything else or not, since all pins of a specific IO bank are powered by the same power rail.Quote from: hostile on October 08, 2021, 04:55:08 pmESDs inside FPGA go from pins to the Vccio rail and prevent IO voltage from going much above IO power rail. With that, it's absolutely not a surprise that voltage makes it way from IO pin to it's Vccio rail. The question is how does it manage to get onto Vcore rail, these are not connected internally, so the only way it can happen is if something on your board facilitates it. Typically it's caused by bad design of the PDS, when Vcore rail is derived from 3.3 V which power Vccio rail (this can be very tempting because typically you already have this 3.3V rail, so adding a separate source of the same voltage may seem like a waste - been there done that ), or if components used allow such backflow.

author: Someone
author_rank: Super Contributor
timestamp: October 08, 2021, 11:56:42 pm
content: Quote from: asmi on October 08, 2021, 03:45:19 pmDoesnt matter if the Vcore is properly decoupled from the Vccio, as the power sequencing requires Vcore first (and the back feeding likely brings up Vccio first, violating the power sequencing).

author: asmi
author_rank: Super Contributor
timestamp: October 09, 2021, 03:13:03 am
content: Quote from: Someone on October 08, 2021, 11:56:42 pmI think the problem here is violating Vcore ramp, FPGAs tend to be picky about both ramp shape (it has to be monotonous) and ramp time - there are typically Tramp_min and Tramp_max which have to be met, because FPGA do actually monitor Vcore and so they can latch up if things are not right with it.