Spartan® Family FPGAs

[nickagian]

I have the following situation. An input signal of 125MHz enters the FPGA and goes through a buffer "IBUFG" and then through a buffer "BUFIO2". I then use this signal to sample to I/O flip flops input signals that are synchronized with this input clock. But I also need to use the clock for other FPGA logic. I have seen in the UG382 (Fig. 1-12 and 1-13) two possible solutions to my case (I guess it resembles my case quite much). Could someone simply explain to me why would someone choose the one over the other implementations? Since in the first figure there is some delay introduced  by the BUFG buffer, I guess I should directly go to Figure 1-13. Is that correct? What's the disadvantage of Fig. 1-13. 

Thank you in advance!

Nikos

[eteam00]

I have seen in the UG382 (Fig. 1-12 and 1-13) two possible solutions to my case (I guess it resembles my case quite much). Could someone simply explain to me why would someone choose the one over the other implementations?

Simple.  IO clock buffers have higher frequency limits than BUFG buffer.  See DS162 Tables 48 and 49.

• If fabric (rather than IOB) logic is used, you have no choice -- you must use BUFG for clock distribution for fabric logic.  As Figure 1-13 indicates, BUFG is entirely sufficient (up to its frequency limit) for both IO and fabric use.

• If BUFG is not fast enough, then you must deserialise in the IOB logic (using either ISERDES2 or IDDR2) to a lower operating frequency.  Either BUFIO2 or BUFPLL will serve this purpose, providing high-frequency IO clock (for deserialisation) and lower-frequency (divided) clock.  The divided clock must then be buffered with a BUFG for fabric use.

NOTE:  In Spartan-6, BUFG = BUFGMUX in the DS162 datasheet, for purposes of this discussion.  BUFG is in fact a BUFGMUX with some BUFGMUX capabilities unused.  BUFG -- rather than BUFGMUX -- is used for purposes of simplicity.

-- Bob Elkind

[austin · Accepted solution]

Nikos,

If you need to synchronize logic inside the FPGA, it is best to get onto the BUFG resource, which is also able to get to IO blocks, too (you do not need to only use BUFIO, you may equally use a BUFG).

If you use both the BUFIO, and a BUFG, then you are using more power, when you do not need to.  You may need the BUFIO for other reasons (features) so that is up to you.  I am assuming you don't need to use the BUFIO here.

1-13 also means that it will be easier for the tools to meet timing, as the IOB DFF and the logic both have the same phase (no added delay of the BUFG as in 1-12).

This is commonly known as "system synchronous" design (all signals are referenced to one system clock).  As clock speeds get higher, people usually change to "source synchronous" design, where each set of data inputs, data outputs, have their own clocks (which may all be the same clock, but may have different phases to make recovery of the data possible at the receiving ends).

[nickagian]

Thank you both for your fast replies. Perhaps these things are obvious for you, but I don't have yet so much experience in using FPGAs!

Austin,

So you're actually suggesting me that after the IBUFG I should use a BUFG directly and then clock all my logic. To be honest I took this idea of the BUFIO buffer from the XILINX RTL written for the Spartan6 device for the RX part of gigabit ethernet (this is actually my application too). But there the internal logic is clocked by internal clock of same frequency. So no BUFG buffer is needed in that case.

Personally I'm not yet so familiar with the available resources and how/when to use each one of them. However your comment about the tools and the timings is what I was more or less thinking when I said before that the phase difference introduced in 1-12 makes this solution not preferable (at least to me).

Regarding the "source synchronous" design I'm not quite sure right now why this approach would have benefits against the other one, but I'll do my research to try to understand this better.

Nikos

[eteam00]

To be honest I took this idea of the BUFIO buffer from the XILINX RTL written for the Spartan6 device for the RX part of gigabit ethernet (this is actually my application too).

MII/RGMII interface used for GbE PHY uses a 125MHz clock, well within the capabilities of the Spartan-6 BUFG buffer.  So yes, BUFG is the correct choice for clock distribution to both IO logic and fabric logic.

-- Bob Elkind

[nickagian]

Bob,

thanks for your anwer. One last clarification, so that I understand completely what you're saying! With IO logic do you mean input flip-flops? And fabric logic all the other logic? And do I have to take some special care so that some of my flip-flops described in VHDL are mapped to IO FFs? Or is this automatically done by the tools? If that's the case, how is this situation recognized? Just by detecting which flip-flops have their inputs connected to IO pins?

thanks again,

Nikos

[eteam00]

With IO logic do you mean input flip-flops?

And output flip-flops as well.   IO logic is not limited to flip-flops of course (serdes, iodelay, iddr/oddr, etc.)

And fabric logic all the other logic?

Yes, excepting PLL/DCMs, etc.

And do I have to take some special care so that some of my flip-flops described in VHDL are mapped to IO FFs?

You can direct the mapper in a number of ways.

• XST process property (in ISE shell Process window, select Synthesize - XST process, right-click, select "process properties", then select option for Pack I/O Registers into IOBs).

• MAP process property (in ISE shell Process window, select MAP process, right-click, select "process properties", then -- under Xilinx Specific Options -- select option for Pack I/O Registers/Latches into IOBs).

• .UCF / .NCF constraint

• Verilog/VHDL/Schematic constraint

See Constaints Guide UG625 IOB section (in version 13.4, this begins on page 125).

Or is this automatically done by the tools?

If you enable this MAP or XST process default, yes.

If that's the case, how is this situation recognized? Just by detecting which flip-flops have their inputs connected to IO pins?

For input FFs, probably...  Different for output FFs.

-- Bob Elkind

[bassman59]

---

nickagian wrote:

thanks for your anwer. One last clarification, so that I understand completely what you're saying! With IO logic do you mean input flip-flops? And fabric logic all the other logic? And do I have to take some special care so that some of my flip-flops described in VHDL are mapped to IO FFs? Or is this automatically done by the tools? If that's the case, how is this situation recognized? Just by detecting which flip-flops have their inputs connected to IO pins?

---

If your clocking requirement is such that the 125 MHz clock you have is the only one needed in the design, then you don't need to do anything special at all. No buffers need to be instantiated and certainly no DCM or PLL is required.

All you need to do is write VHDL describing the logic, making sure it's all synchronous to that 125 MHz clock. The tools will take care of the rest. Any inputs or outputs that can be registered in the IOB will be, and your input clock will be put on a BUFG for proper distribution throughout the chip.

-a