cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
2,767 Views
Registered: ‎05-18-2018

Artix 7 - Output current Limitation per Bank

Jump to solution

Hello,

 

Let me start by saying that I am new to Xilinx FPGA's. I just had a new design using Artix-7 XC7A15T-FTG. I discovered very strange behavior where 2 logic outputs assigned to motor driver chips were stuck at 1.1V and 1.6V respectively. I reworked the board and reassigned 2 other pins from another bank in the FPGA then the problem was solved. The problem is on at least 2 prototypes so far. I checked for continuity and shorts and the previous assigned pins were fine. Also it is highly unlikely to be caused by the PCB fab since 2 boards have the same symptom. 

The only explanation I can come out with is that I may have exceeded the output current capability of that FPGA bank. It is Bank 15 where I have set the outputs to LVCMOS33 with 35 outputs and 13 inputs assigned including a global MMCM clock.

I read in a small print in one of the app notes about 200mA limitation per bank........ I would appreciate if I can get more detailed information about the current limitation per bank and whether my assumption is correct......

 

Regards,


Zee

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
2,711 Views
Registered: ‎05-18-2018

Thanks for all the suggestions trying to solve this problem. I found the problem and it was caused by a setup parameter in the constraints file. The 2 pins that were stuck at DC level have a configuration function RS0 and RS1 as well. So when I selected in the Settings Configuration "Prohibit usage of the Configuration pins as user I/O and persist after configuration" to ENABLE, it set the Persist to YES in the Constraints file. From the description of this setting you would think Vivado should have prevented me from using I/O's that are controlled by the Persist such as these 2 pins. It blocked some multi-function pins but not all of them for some reason which I think it is a Vivado bug. The RS0 and RS1 are used to ID FPGA's in a daisy chain.....

 

So the problem was caused by setting the Persist to YES and I am very confident about it.

 

Thanks 

 

Z

View solution in original post

0 Kudos
13 Replies
Highlighted
Moderator
Moderator
2,746 Views
Registered: ‎04-18-2011

You could set all the IOs in a bank to be output and set the drive setting to be the highest setting and you would not damage the IO as long as you were driving some sensible load. 

What are the IOs that are stuck connected to?

 

Is there a chance that they are coming into contact with something and being damaged by ESD?

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
2,736 Views
Registered: ‎05-18-2018

Thanks for the reply...The assigned pins are H14 and G15 with 12mA drive strength.... Also to note that I have other driver chips are driven the same way directly from the FPGA without any issues...

 

 

As for ESD damage, I have 2 prototype boards exhibit the same exact behavior and the same stuck voltage amplitude so it is unlikely that it is PCB fabrication or ESD. The problem was fixed when I reassigned 2 other I/O pins on the FPGA!  

 

Z

0 Kudos
Highlighted
Explorer
Explorer
2,724 Views
Registered: ‎05-08-2018

e,

 

An IO pin driving a load does so through a transmission line formed by the PCB traces, and any cable and connectors.  A signal integrity analysis should be done to confirm there is no over shoot or under shoot.  Over shoot will damage the IO if beyond the absolute max ratings in table 1 of the data sheet.

 

Put a > 1 GHz bandwidth oscilloscope probe at the pin with both signal and ground leads less than 1/2" (12 mm) to see your over or under shoot.  You can build a SI probe using 50 coax, with a 50 ohm termination, a series 1K to the IO pin (see Howard Johnson's signal integrity book).

 

The max current is 100 mA per IO bank, 200 mA for all banks.  This is the latch up specification.  DO NOT EXCEED.

 

A stuck at fault as you describe is likely ESD damage.  Less likely signal integrity damage, but certainly possible.

 

The built in (intrinsic) protection diodes can only stand so much abuse.  You may need additional external diodes, or a zener diode clamp.  Such diodes will also protect against ESD.

Tags (1)
0 Kudos
Highlighted
Observer
Observer
2,718 Views
Registered: ‎05-18-2018

I get the point about signal integrity but the signals I am driving are only about 1KHz..... The main frequency is only 16MHz.

 

I can try to drive the previous pins high or connect other signals to them and test but I was hoping I can get some ideas on what could be causing this behavior such as the current limitation.

 

Thanks,

 

Z

0 Kudos
Highlighted
Explorer
Explorer
2,697 Views
Registered: ‎05-08-2018

e,

 

Frequency has (almost) nothing to do with SI: it is the rise & fall times (which are 100 - 200 ps).

 

The frequency is the difference between a hammer (by hand), and a rotary hammer (driven faster).  They both can do damage.  One way is just faster.

 

The reflection  from the rising or falling edge when impedances are mis-matched is what causes over and under shoot (ringing, etc.).

 

 

0 Kudos
Highlighted
2,692 Views
Registered: ‎06-21-2017

You haven't answered @klumsde's question.  What exactly are you driving with these pins?  Related to @alesea's question, are you driving the receiving device through a nice short board trace, or a long, non-impedance controlled cable?

0 Kudos
Highlighted
Observer
Observer
2,685 Views
Registered: ‎05-18-2018

I am driving logic inputs of driver chip TEA3718. The lines go straight from the FPGA to the drivers. The FPGA among other things controls 7 of these driver chips. Only 2 logic lines out of 21 exhibit this problem. All driver chips are connected the same way.... The traces are a bit long roughly about 12 inches. The slew rate is set to slow in the FPGA.

 

Thanks,


Z

0 Kudos
Highlighted
Explorer
Explorer
2,586 Views
Registered: ‎05-08-2018

e,

 

12 inches of uncontrolled impedance, or improper termination results in a potentially destructive return reflection.

 

What does it look like on a 'oscope?

 

0 Kudos
Highlighted
Observer
Observer
2,580 Views
Registered: ‎05-18-2018

The signal is stuck at DC level; one at 1.1V and one at 1.6V... so how can it be a reflection issue if the outputs are not even switching ?!

0 Kudos
Highlighted
2,249 Views
Registered: ‎06-21-2017

What is the voltage of the TEA3718?  This is a bipolar (not CMOS) chip and the input will not be as high impedance as a typical CMOS input and may also be floating higher that the VCCO of the FPGA when the FPGA tries to drive high.

Highlighted
Observer
Observer
2,240 Views
Registered: ‎05-18-2018

The logic VSS of the chip is connected to 5V, the winding power is 24V, and the logic out of the FPGA is 3.3V logic driving the logic inputs of the chip. VIH Min on that part is 2V so that should be fine using 3.3V logic to drive it.... 7 chips are driven the same way and only 2 out of 21 logic lines have this DC stuck issue and the problem was solved by using 2 other pins from another bank instead......

0 Kudos
Highlighted
Scholar
Scholar
2,136 Views
Registered: ‎04-26-2012

@elmassiz  "The logic VSS of the chip is connected to 5V"

 

As mentioned by Bruce, the input stage of your motor driver chip is probably trying to pull your FPGA outputs above the 3.3V VCCO supply rail and damaging the pins, particularly if the 5V power supply rail comes up before the FPGA VCCO does (probe 5V, VCCO, and the failing output pins during power on/off cycles looking for any strange behavior on the output line).

 

Putting a 100 ohm series resistor between the FPGA and the 5V logic should help limit any I/O clamp current to a safe value (but you should then verify that you still meet the stepper motor driver's Vil with series resistor in place.)

 

I usually use an external 3.3V -> 5V translator between my FPGA pins and any high-voltage drivers, because the translators are easier and simpler to replace than the FPGA if something goes wrong.

 

>

> 7 chips are driven the same way and only 2 out of 21 logic lines have this DC stuck issue

>

Symptoms would probably involve gradual pin failures, so if this is a new design maybe you just haven't waited long enough for the other pins and boards to fail yet :)

 

-Brian

0 Kudos
Highlighted
Observer
Observer
2,712 Views
Registered: ‎05-18-2018

Thanks for all the suggestions trying to solve this problem. I found the problem and it was caused by a setup parameter in the constraints file. The 2 pins that were stuck at DC level have a configuration function RS0 and RS1 as well. So when I selected in the Settings Configuration "Prohibit usage of the Configuration pins as user I/O and persist after configuration" to ENABLE, it set the Persist to YES in the Constraints file. From the description of this setting you would think Vivado should have prevented me from using I/O's that are controlled by the Persist such as these 2 pins. It blocked some multi-function pins but not all of them for some reason which I think it is a Vivado bug. The RS0 and RS1 are used to ID FPGA's in a daisy chain.....

 

So the problem was caused by setting the Persist to YES and I am very confident about it.

 

Thanks 

 

Z

View solution in original post

0 Kudos