cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
gauravjain14
Contributor
Contributor
19,899 Views
Registered: ‎05-25-2015

Using a Global clock buffer at a Clock Capable pin

Jump to solution

When having an external clock as input to the FPGA at clock capable pin, is it required that I add a Global Clock buffer such as IBUFG before using it in my logic or since it is already coming through the clock capable pin and my constraints file has constraints for it, the tool will use it as a clock and drive it through the clock paths?

If the tool will infer it to be a clock and drive it through the clock paths, then what happens if I use the clock capable pin as a general IO? Is it the period constraints that play a decisive role over here

 

Cheers,

Gaurav

1 Solution

Accepted Solutions
avrumw
Expert
Expert
22,243 Views
Registered: ‎01-23-2009

First (and I really wish this name was never created, but...) an IBUFG is not a clock buffer. It is an input buffer - identical to an IBUF. The only thing about the IBUFG is that it can only be given a LOC (or PACKAGE_PIN) of a clock capable pin. This is merely a shorthand in your RTL for "I plan to use this as a clock - don't let me LOC it to a non clock-capable pin".

All inputs must come through an IBUF; it is the only way to bring a signal into an FPGA; the bond site is connected to (and only connected to) the input of an IBUF. If your RTL does not have an IBUF (or IBUFG) instantiated on an input, then the tools will infer one for you.

A clock capable pin is identical to any other pin, with one exception; the output of the IBUF associated with it has an additional dedicated route to the dedicated clock circuitry in the FPGA. Depending on the family this means a dedicated connection to:

  • the BUFIO and BUFR
  • the BUFGs
  • the BUFHs in the same clock region
  • the MMCMs/DCMs/PLLs
    • in some families, only the ones that exist in the same clock region

If you don't connect the output of the IBUF (either instantiated or inferred) directly to the inputs of one of the above resources, then it will take the "normal" fabric route out of the IBUF (normally to be used as a non-clock input).

A signal on general fabric routing resources should not be used as a clock - this would be a locally routed clock, and has a variety of bad characteristics. Clocked resources should always be driven by a dedicated clock network; the output of a BUFIO/BUFR/BUFH/BUFG.

To take a BUFG as an example, this should be directly instantiated, and connected either to:

  • the output of the IBUF/IBUFG of a clock capable pin
  • the clock capable pin (in which case an IBUF will be inferred)
  • the output of a DCM/PLL/MMCM
  • (and a few other rarer connections)

If you have a clock capable pin (with the IBUF/IBUFG directly instantiated or inferred) and it goes directly to clocked cells, the tools will automatically infer a BUFG to place the signal on a global clock network.

So, even if you take a clock capable pin directly to a clocked cell, the tools will infer the IBUF and the BUFG for you. But it is generally recommended to instantiate both of them (or at least the BUFG).

Avrum

View solution in original post

15 Replies
balkris
Xilinx Employee
Xilinx Employee
19,890 Views
Registered: ‎08-01-2008
you can use clock capable pin as general IO other way its not permitted .
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
nupurs
Moderator
Moderator
19,874 Views
Registered: ‎06-24-2015

@gauravjain14,

 

Refer page 22 of this link(if you are using 7 series) to see what all can be driven by CCIO pins:
https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf

Thanks,
Nupur
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (click on the 'thumbs-up' button).
0 Kudos
balkris
Xilinx Employee
Xilinx Employee
19,872 Views
Registered: ‎08-01-2008
check this post as well
https://forums.xilinx.com/t5/Virtex-Family-FPGAs/Is-every-pin-clock-capable/td-p/23005
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
gauravjain14
Contributor
Contributor
19,817 Views
Registered: ‎05-25-2015

Hi @balkris,

I guess my question was not clear enough. 

 

My scenario - 

I have Global Clock pin to which an external clock at 250MHz is being given as input. This is my system clock. Now I have to use this clock in the design. I have this clock as an Input port to the top module of my design. Now do I have to pass it through a Global Buffer (IBUFG) before using it in my design or will the tool automatically add BUFG before routing it in the design?

 

I guess I am clear enough this time. I know that Clock pins can be used as IO and the vice versa is not true. 

 

Thank You

Gaurav

0 Kudos
gauravjain14
Contributor
Contributor
19,815 Views
Registered: ‎05-25-2015

Hi @nupurs

Please check my reply to @balkris

0 Kudos
avrumw
Expert
Expert
22,244 Views
Registered: ‎01-23-2009

First (and I really wish this name was never created, but...) an IBUFG is not a clock buffer. It is an input buffer - identical to an IBUF. The only thing about the IBUFG is that it can only be given a LOC (or PACKAGE_PIN) of a clock capable pin. This is merely a shorthand in your RTL for "I plan to use this as a clock - don't let me LOC it to a non clock-capable pin".

All inputs must come through an IBUF; it is the only way to bring a signal into an FPGA; the bond site is connected to (and only connected to) the input of an IBUF. If your RTL does not have an IBUF (or IBUFG) instantiated on an input, then the tools will infer one for you.

A clock capable pin is identical to any other pin, with one exception; the output of the IBUF associated with it has an additional dedicated route to the dedicated clock circuitry in the FPGA. Depending on the family this means a dedicated connection to:

  • the BUFIO and BUFR
  • the BUFGs
  • the BUFHs in the same clock region
  • the MMCMs/DCMs/PLLs
    • in some families, only the ones that exist in the same clock region

If you don't connect the output of the IBUF (either instantiated or inferred) directly to the inputs of one of the above resources, then it will take the "normal" fabric route out of the IBUF (normally to be used as a non-clock input).

A signal on general fabric routing resources should not be used as a clock - this would be a locally routed clock, and has a variety of bad characteristics. Clocked resources should always be driven by a dedicated clock network; the output of a BUFIO/BUFR/BUFH/BUFG.

To take a BUFG as an example, this should be directly instantiated, and connected either to:

  • the output of the IBUF/IBUFG of a clock capable pin
  • the clock capable pin (in which case an IBUF will be inferred)
  • the output of a DCM/PLL/MMCM
  • (and a few other rarer connections)

If you have a clock capable pin (with the IBUF/IBUFG directly instantiated or inferred) and it goes directly to clocked cells, the tools will automatically infer a BUFG to place the signal on a global clock network.

So, even if you take a clock capable pin directly to a clocked cell, the tools will infer the IBUF and the BUFG for you. But it is generally recommended to instantiate both of them (or at least the BUFG).

Avrum

View solution in original post

vemulad
Xilinx Employee
Xilinx Employee
19,782 Views
Registered: ‎09-20-2012

Hi @gauravjain14

 

Which device and tool are you using?

 

IBUFG is an input clock buffer. 

 

BUFG is global clock buffer which connects to global clock network.

 

You can instantiate BUFG on the net to be safer side. Implementation tool is also capable of inserting BUFG on the clock nets in the design. If the BUFG is already instantiated by user, the tool will not infer BUFG on that net.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
gauravjain14
Contributor
Contributor
19,582 Views
Registered: ‎05-25-2015

I agree to your entire answer except the first line which is completely wrong on the facts.

Please refer to this document (Page 158) which clearly says that IBUFG is a dedicated clock buffer. Not only this, every hdl guide from xilinx, from virtex 4 to virtex 7 says that IBUFG is a dedicated clock buffer.

0 Kudos
gauravjain14
Contributor
Contributor
19,581 Views
Registered: ‎05-25-2015

Hi @vemulad

Thank you for the clarification. I have an additional query. Please let me know if I should mark this question as closed and ask that in a new question.

 

The query is, giving input clock to a Global Clock pin is sensible. BUFGs can be used for driving the clock to different regions, where as required the tool uses BUFH for further distribution. 

Now what happens if, instead of using a Global Clock capable pin , I use an MRCC or SRCC clock pin and then use the clock to drive my entire logic? This should throw an error or warning, which does not happen.

0 Kudos
avrumw
Expert
Expert
16,845 Views
Registered: ‎01-23-2009

I agree to your entire answer except the first line which is completely wrong on the facts.

No, its not. Even the manual you shows has this described as a "Dedicated Input Clock Buffer", with the description "The IBUFG is a dedicated input to the device which should be used to connect incoming clocks to the FPGA's global clock routing resources".

It clearly says it is an input (like an IBUF) with a dedicated connection to the "FPGA's global clock routing resources" i.e. the BUFG or the DCM/PLL/MMCM.

Not only this, every hdl guide from xilinx, from virtex 4 to virtex 7 says that IBUFG is a dedicated clock buffer.

Again, this is incorrect. They all say the same thing - it is a dedicated input clock buffer. This is not to be confused with the description for the real clock buffer, the BUFG, which is described as a "Global Clock Buffer". And even if the documentation isn't 100% clear, there is no debate - an IBUFG is just an IBUF that can be LOC'ed to the global clock pin locations.

Avrum

avrumw
Expert
Expert
16,842 Views
Registered: ‎01-23-2009

The query is, giving input clock to a Global Clock pin is sensible. BUFGs can be used for driving the clock to different regions, where as required the tool uses BUFH for further distribution. 

Now what happens if, instead of using a Global Clock capable pin , I use an MRCC or SRCC clock pin and then use the clock to drive my entire logic? This should throw an error or warning, which does not happen.

Again, the nomenclature is a bit messed up.

In the beginning (i.e. before Virtex-4) the only way to bring a clock in to the device was via the "Global Clock Inputs" (GG pins - also called GCLK pins in Spartan series). These had dedicated connections to the clocking resources of the FPGA, which were all global (the BUFG and the DCM).

Virtex-4 introduced the concept of regional clocks. It still had global clock inputs for reaching the BUFG/DCM, but it also had "Clock Capable (CC)" pins for reaching the regional clock resources; the BUFIO and BUFR (only). So it was clear, the GC drove the global resources, and the CC drove the regional resources. You could only LOC an IBUFG to a GC location.

Virtex-5 was pretty much the same, except some pins were both a CC and a GC.

Virtex-6 got more confusing. In V6 there were still GC pins, but there were fewer. In addition, some of the CC pins (those in the inner I/O columns) could also reach the MMCM in the same clock region, so we started to get a blurring between the definition of the GC pins and the CC pins (since now some CC pins could drive global resources). In addition these CC pins could also directly access the BUFH, which was a new resource in the V6 (they were actually always technically there, but only accessible from the BUFGs). Furthermore, not all CC pins were the same, within each bank there were CCs that could only access the BUFIO/BUFR in the same region (hence Single Region Clock Capable I/O or SRCC I/O) and ones that could also access the BUFIO/BUFR in the regions above and below (hence Multi-Region Clock Capable I/O or MRCC I/O). It was now less clear which pins could have an IBUFG LOC'ed to them, since pins could be used for both global and regional clocks - as a result the IBUFG started becoming somewhat meaningless (I mostly gave up on them and use an IBUF all the time - even if the destination is going to a global clock resource).

The 7 series simplified things a bit. There are no longer any GC pins, there are only CC pins. All the CC (SRCC and MRCC) pins can access the BUFIO/BUFR in their region, whereas the MRCC can also access the BUFMR which can then access the BUFIO and BUFR in adjacent regions. Furthermore, all CC pins (SRCC and MRCC) can all access the BUFGs (on the same half of the FPGA), and the MMCM/PLL and BUFH in the same clock region (its a little more complicated for the BUFH - the CC pins in either the left or right clock region can access the BUFH).

So, back to your question. Without knowing which family you are using, its impossible to answer the question. In the 7 series, there are no "Global Clock Capable" pins. In V6, some of the CC pins (SRCC or MRCC) can access the BUFG directly, so using those to drive your entire logic (through a BUFG) is legal - for other CC pins, its not. If you try to route from a CC to a BUFG on a CC that is not capable of reaching the global buffer by a dedicated route you will get a pretty specific Error (or Critical Warning in Vivado), instructing you to use the CLOCK_DEDICATED_ROUTE=FALSE property.

And, again, neither a GC or CC (SRCC or MRCC) are clock buffers, they are clock capable pins. From there you route them to clock buffers (either BUFG, BUFH, BUFIO, BUFR or BUFMR). The reason this can get confusing is that if you go directly from a pin to some clocked devices, the tool will infer a BUFG for you even if you don't instantiate one - but if you go look at the resulting schematic, you will clearly see that the CC pin goes through an IBUF to a BUFG and then to the clock inputs of flop-flops (through the global clock network).

Avrum

drbyte
Observer
Observer
13,261 Views
Registered: ‎03-07-2011

Hi @vemulad could you please let me know how I can instantiate a BUFG inside my VHDL code?

I've a main clock on the pin L17 of my Artyx XC735T CPG236 on a Cmod A7-35T demo board,

Also I've a MMCM module sourced frm this clock in order to generate a 100 MHz clock that I've to use inside the FPGA.

Now, to be correct in my design I suppose to have to do:

 

- instantiate a IBUFG to get the clock from the pin L17 inside the FPGA and the connect the input pin of the MMCM module to the output of this buffer, if I've correctly understand could you please let me know the correct syntax that I've to use in my VHDL code to setup this buffer?

- then I've to route the clock generated from the MMCM module at the input of a BUFG (global clock buffer) in order to use the 100 MHz inside the FPGA and the output of this one to the input of the global clock network then to a know net name inside the FPGA, how to perform this task in VHDL?

 

About the XDC file I've these assignement for the L17 pin then the main source clock that is on my board and is feed to the FPGA clock pin L17.

 

set_property -dict {PACKAGE_PIN L17 IOSTANDARD LVCMOS33} [get_ports sysclk]
create_clock -period 10.000 -name sys_clk_pin -waveform {0.000 5.000} -add [get_ports sysclk]

but know I think that I've do an error because the sysclk is the 12 MHz clock and not the 100 MHz on the MMCM output then I suppose that I've to use instead these declaration:

 

set_property -dict {PACKAGE_PIN L17 IOSTANDARD LVCMOS33} [get_ports sysclk]
create_clock -period 83.33 -name sys_clk_pin -waveform {0 41.66} -add [get_ports sysclk]

Comparing these one with the XDC file provided by the supplier I've:

 

set_property -dict { PACKAGE_PIN L17   IOSTANDARD LVCMOS33 } [get_ports { sysclk }]; #IO_L12P_T1_MRCC_14 Sch=gclk
create_clock -add -name sys_clk_pin -period 83.33 -waveform {0 41.66} [get_ports {sysclk}];

The syntax is slighty different due to the presence of the {} brackets and the ; at the end of each row.

Is an equivalent way to write the constraints or there are difference in writing with and without bracket? What is the purpose of the ; at the end of each row, is equivalent if I write it or not?

 

Another question is about the output of the MMCM clock, I've also to specify some constraints into the XDC file about the 100 MHz clock line generated by the module to instruct the compiler that this one have to be connected to the global clock network or I can avoid it and put a direct declaration inside the VHDL code and how I can do that?

 

Finally I kindly ask what shoud be the better practice between place directives directly into the VHDL source code or inside the XDC file?

 

Be patient I'm going to grow up my knowledge on this systems.

 

Thanks for your time!

 

Best regards

0 Kudos
vemulad
Xilinx Employee
Xilinx Employee
13,188 Views
Registered: ‎09-20-2012

Hi @drbyte

 

Please create a new thread in Synthesis board for your queries. 

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
drbyte
Observer
Observer
13,105 Views
Registered: ‎03-07-2011
Sorry for my wrong board post.
0 Kudos
gauravjain14
Contributor
Contributor
13,073 Views
Registered: ‎05-25-2015

Hi @avrumw
I did not see the notifications on this post and completely agree to your description. Though the post has grown too old now, my understanding of the device specifics have somewhat cleared out and I completely agree with what you have stated. Thank you for the explanation.