I2C Implementation in FPGAs

Thread Starter

jsalvo

Joined Aug 2, 2017
5
Hi Community,

I'm an Application Engineer and I need to design an interposer board that connects to an FPGA module. More specifically, the module is an ALINX AC7100B, which uses Xilinx Artix-7 XC7A100T FPGA.

I heard complaints from my colleagues that some FPGAs do not have pads with Schmitt Triggers nor glitching filters and they observed glitches on I2C SCL (serial clock) line that corrupted the data.

My question is how can I know if the Artix-7 XC7A100T FPGA does have the option to use Schmitt Triggers (and glitching filters) in the regular I/O input pads? I cannot find the FPGA datasheet on the web.

If the FPGA does not support the above, I will need to add Schmitt Triggers in my PCB (like the SN74LVC1G17), but this complicates the design because these kind of buffers are uni-directional.

Thank you in advance for your help.

Regards,
Jorge
 

Irving

Joined Jan 30, 2016
3,843
Welcome to AAC.

Not sure why you can't find XC7A100T datasheet... Google threw up several links including those through suppliers like Mouser and Digikey. Here is the link to AMDs FPGA Portal , and direct to the Artix-7 resources

Back to your question; the DC & AC Switching characteristics datasheet (DS181) does not explicitly give details of schmitt trigger inputs, just quotes input high and low voltage levels ref to VCC. The user guide for SelectIO details how to use/configure pad I/O but again I can't see any reference to Schmitt inputs. However it seems there are specific rules for external clocks as documented in 7 Series FPGAs Clocking Resources User Guide (UG472) which says:

"External user clocks must be brought into the FPGA on differential clock pin pairs called
clock-capable (CC) inputs. Clock-capable inputs provide dedicated, high-speed access to
the internal global and regional clock resources. Clock-capable inputs use dedicated
routing and must be used for clock inputs to guarantee timing of various clocking features.
General-purpose I/O with local interconnects should not be used for clock signals.
"

which may be the reason your colleagues are having issues?
 

drjohsmith

Joined Dec 13, 2021
852
Hi Community,

I'm an Application Engineer and I need to design an interposer board that connects to an FPGA module. More specifically, the module is an ALINX AC7100B, which uses Xilinx Artix-7 XC7A100T FPGA.

I heard complaints from my colleagues that some FPGAs do not have pads with Schmitt Triggers nor glitching filters and they observed glitches on I2C SCL (serial clock) line that corrupted the data.

My question is how can I know if the Artix-7 XC7A100T FPGA does have the option to use Schmitt Triggers (and glitching filters) in the regular I/O input pads? I cannot find the FPGA datasheet on the web.

If the FPGA does not support the above, I will need to add Schmitt Triggers in my PCB (like the SN74LVC1G17), but this complicates the design because these kind of buffers are uni-directional.

Thank you in advance for your help.

Regards,
Jorge
Welcome to the board Application engineer.

I2C, is a very slow protocol, 1 MHz max, normally around 100 KHz.
Artix 7 FPGAs , even the slowest run at 350MHz plus.

The FPGA does not have an I2C interface, just logic pins.
Its only the chips with processors in that have native I2C interfaces.

A standard Schmitt trigger will not remove or prevent the I2C glitch that can happen on any I2C bus , especially one with multiple masters, The I2C glitch is just to slow and to big for a silicon Schmitt to do anything apart form pass the signal through.

If you are using a none processor FPGA, then you will have a lump of IP code,
The IP will have a built in deglitcher circuit, which will take care of the I2C multi master glitch

If your using a built in ARM processor FPGA, a Zynq
then its a little more difficult.
Yes, the early versions of the ARM processor in Xilinx part, used the ARM IP, and that had "missed" the glitch filter!
You don't have a zynq, but for reference, the article and work around on this is here.

https://support.xilinx.com/s/article/61861?language=en_US

But later FPGA versions of ARM fixed that .

BTW:
have you considered posting on the Xilinx forum ?
Applicatoin engineers would expect special access to support .
 

Thread Starter

jsalvo

Joined Aug 2, 2017
5
Welcome to AAC.

Not sure why you can't find XC7A100T datasheet... Google threw up several links including those through suppliers like Mouser and Digikey. Here is the link to AMDs FPGA Portal , and direct to the Artix-7 resources

Back to your question; the DC & AC Switching characteristics datasheet (DS181) does not explicitly give details of schmitt trigger inputs, just quotes input high and low voltage levels ref to VCC. The user guide for SelectIO details how to use/configure pad I/O but again I can't see any reference to Schmitt inputs. However it seems there are specific rules for external clocks as documented in 7 Series FPGAs Clocking Resources User Guide (UG472) which says:

"External user clocks must be brought into the FPGA on differential clock pin pairs called
clock-capable (CC) inputs. Clock-capable inputs provide dedicated, high-speed access to
the internal global and regional clock resources. Clock-capable inputs use dedicated
routing and must be used for clock inputs to guarantee timing of various clocking features.
General-purpose I/O with local interconnects should not be used for clock signals.
"

which may be the reason your colleagues are having issues?
Hi Irving,
Thank you for your reply. I received feedback from the digital designers that Artix-7 FPGA does not have Schmitt Triggers inputs, but our engineers implemented a glitch filter following this recommendation from Xilinx:
61861 - Zynq-7000 SoC, I2C - Missing Glitch Filter Implementation in Zynq PS I2C Controller (xilinx.com)
The issue observed by my colleagues was that a glitch on the SDA or SCL line was probably causing a momentary false trigger on the signal line. The filter design recommended by Xilinx in the link below addresses this issue. However, I will still consider adding an external Schmitt Triggers.
Regards,
Jorge
 

Thread Starter

jsalvo

Joined Aug 2, 2017
5
Welcome to the board Application engineer.

I2C, is a very slow protocol, 1 MHz max, normally around 100 KHz.
Artix 7 FPGAs , even the slowest run at 350MHz plus.

The FPGA does not have an I2C interface, just logic pins.
Its only the chips with processors in that have native I2C interfaces.

A standard Schmitt trigger will not remove or prevent the I2C glitch that can happen on any I2C bus , especially one with multiple masters, The I2C glitch is just to slow and to big for a silicon Schmitt to do anything apart form pass the signal through.

If you are using a none processor FPGA, then you will have a lump of IP code,
The IP will have a built in deglitcher circuit, which will take care of the I2C multi master glitch

If your using a built in ARM processor FPGA, a Zynq
then its a little more difficult.
Yes, the early versions of the ARM processor in Xilinx part, used the ARM IP, and that had "missed" the glitch filter!
You don't have a zynq, but for reference, the article and work around on this is here.

https://support.xilinx.com/s/article/61861?language=en_US

But later FPGA versions of ARM fixed that .

BTW:
have you considered posting on the Xilinx forum ?
Applicatoin engineers would expect special access to support .
Hi drjohsmith,

Thank you very much for your complete answer. In fact the link you attached about the de-glitching filter is the same that the digital guys found in my company. They are implementing the filter following the instructions on that web and they think that we will have no issues after that.
Regards,
Jorge
 

drjohsmith

Joined Dec 13, 2021
852
Hi drjohsmith,

Thank you very much for your complete answer. In fact the link you attached about the de-glitching filter is the same that the digital guys found in my company. They are implementing the filter following the instructions on that web and they think that we will have no issues after that.
Regards,
Jorge
Thanks for getting back
It's certainly worked in many designs we've done , it's just a standard circuit we use now.
 

Thread Starter

jsalvo

Joined Aug 2, 2017
5
Thanks for getting back
It's certainly worked in many designs we've done , it's just a standard circuit we use now.
Hi drjohsmith,
you're welcome and thanks for the feedback.

On top of the (de)-glitching filter we discussed, which goes into the FPGA itself, I'm considering to add an external I2C bus accelerator in my board to make the SCL/SDA edges faster and hence less susceptible to noise / fluctuations in the supplies.

I prefer this option rather than the Schmitt Triggers because the latter are uni-directional so I have to implement another line for the SDA data return path. The bus-accelerators, on the other hand, can be connected in parallel. See an example in the link below:
LTC4311 Datasheet and Product Info | Analog Devices

Have you ever used that kind of circuits? Would you recommend them?

Thanks,
Jorge
 

drjohsmith

Joined Dec 13, 2021
852
carefull with buffers,
some arn't buffers at all but analog switches, others can not cope with clock stretching, others need to be wired up to the "master" correctly , and are difficult to cascade.
We use plenty of them, Ti and Analog devices are as you say the ones to look at.
 

Thread Starter

jsalvo

Joined Aug 2, 2017
5
carefull with buffers,
some arn't buffers at all but analog switches, others can not cope with clock stretching, others need to be wired up to the "master" correctly , and are difficult to cascade.
We use plenty of them, Ti and Analog devices are as you say the ones to look at.
Thanks again! finally with the internal glitch-filter I think that external Schmitt triggers are not necessary anymore, but thanks for the heads-up anyway.
 
Top