Proper Design approach: Buffering of I/O on an FPGA - Page 1
Forum section: electronics / general

author: Pack34
author_rank: Frequent Contributor
timestamp: February 03, 2016, 09:41:31 pm
content: One thing I noticed when working with Vivado is that some generated code always seems to add a buffer on the input and the output. Is this a more proper design approach than just wiring the signal out?The main reason I ask this is that I'm currently debugging a design and when I probe one of the outputs it seems to have an effect on the overall timing of a portion of the logic. Almost as if the added capacitance of the probe is slowing something down and causing a race condition to occur.Should all I/O have a simple buffer to protect the internal logic of the FPGA?

author: andre_teprom
author_rank: Regular Contributor
timestamp: February 03, 2016, 10:47:48 pm
content: According to pag. 21 of this datasheet, you can disable that option:Vivado Design Suite - User GuideQuote

author: Pack34
author_rank: Frequent Contributor
timestamp: February 03, 2016, 10:56:00 pm
content: I was more curious if was "better design" to do so.

author: xygor
author_rank: Regular Contributor
timestamp: February 03, 2016, 11:11:35 pm
content: What fpga are you talking about?You can't *not* have an io buffer. The fabric does not have direct access to pins!

author: Pack34
author_rank: Frequent Contributor
timestamp: February 03, 2016, 11:26:26 pm
content: I'm working with a Spartan6.

author: andre_teprom
author_rank: Regular Contributor
timestamp: February 03, 2016, 11:28:17 pm
content: There is perhaps a misunderstanding of the I/O of amoduleor achip.

author: hamster_nz
author_rank: Super Contributor
timestamp: February 03, 2016, 11:39:36 pm
content: Quote from: Pack34 on February 03, 2016, 09:41:31 pmThe I/O buffers are inescapable.To get a signal off of the FPGA fabric and out to a pin it has to go through an output buffer. Likewise to get a signal from the outside world onto the fabric it has to go through an input buffer. If you disable the automatic insertion of I/O buffers then I guess you will get Place and Route failures if your signals lack them.Situations where you must explicitly create the required I/O buffers include using differential I/O standards, or if you want to control the signals I/O attributes from within the HDL source rather than with external constraints.For single ended inputs or outputs I don't explicity add the buffers. For tristate pins I've moved away from using tristate signals in my designs and use explicit tristate buffers. Using tristate signals and leaning on the tools to implement it just doesn't seem to work. I usually end up with placing the tristate buffer in the design's top level design and the having pin_input, pin_output and pin_tristate signals being passed up/down into the deeper level of the design.For me, I find it helpful for the internal design to match the actual physical implementation within the FPGA, but that is just me - I'm sure others will argue I am foolish to not use the tiny level of abstraction that tristate signals gives.As a start for best practice, have a look athttp://www.xilinx.com/support/documentation/sw_manuals/ug949-vivado-design-methodology.pdfQuoteEdit: This also holds true for Spartan 6.

author: nctnico
author_rank: Super Contributor
timestamp: February 04, 2016, 12:21:12 am
content: Also don't forget to add timing constraints between the outside signals coming in to the flip-flops and from the flip-flops to the signals going out. If you don't have these timing constraints you can have severe routing delays and you can get all kinds of weird timing problems with the external devices connected to the FPGA.

author: Pack34
author_rank: Frequent Contributor
timestamp: February 04, 2016, 02:32:11 pm
content: Quote from: nctnico on February 04, 2016, 12:21:12 am.... I will look into this. Thanks!