UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
280 Views
Registered: ‎03-03-2017

7 series BUFG -> BUFH -> BUFG acceptable?

Jump to solution

I am working on a project in Vivado 2019.1 using an Artix-7 device and I have found that sometimes when I have implementation PLACE errors where it cannot find adjacent BUFGs for my design I can fix the issue by putting a BUFH in between the 2 BUFGs.

According to UG472 table 1-1 a BUFH is not setup to drive a BUFG.

My question is whether this is really acceptable, and if not then why doesn't Vivado complain during implementation?

Thanks.

Tim

0 Kudos
1 Solution

Accepted Solutions
245 Views
Registered: ‎01-22-2015

Re: 7 series BUFG -> BUFH -> BUFG acceptable?

Jump to solution

Hi Tim,

I agree with you that UG472 says a BUFH should not be used to drive a BUFG – because the connection can only be made through the FPGA fabric.  -and routing clocks through the FPGA fabric is usually a bad thing to do.

As you found in Vivado v2019.1, I also found in Vivado 2018.3 for an Artix-7 (xc7a100tfgg484-3).  That is, Vivado allows me to connect the output of a BUFH to the input of a BUFG – and gives no warning nor error during implementation!   However, Vivado does give the following DRC Critical Warning:

REQP-1933: The BUFG I pin should not be driven by a BUFH or else must be properly floorplanned. This connection is not routable in some cases.

As you are, I am surprised that Vivado is only giving us a DRC Critical Warning and not an implementation Critical Warning.  However, the DRC Critical Warning cannot be ignored.  Like UG472, the Critical Warning is telling us that BUFH should not be used to drive a BUFG.

I know from your other recent posts that you are trying to solve special problems related to BUFGs being separated into top-half and bottom-half groups in the Artix-7.  -and that is why you are investigating serial strings of clock buffers.  

However, for others reading this post, it is unusual and generally problematic to connect clock buffers serially (eg. BUFG => BUFH => BUFG).  This is because one clock buffer is usually enough - and adding more buffers can skew clocks in the clock tree and make it difficult for your project to pass timing analysis.

Mark

4 Replies
246 Views
Registered: ‎01-22-2015

Re: 7 series BUFG -> BUFH -> BUFG acceptable?

Jump to solution

Hi Tim,

I agree with you that UG472 says a BUFH should not be used to drive a BUFG – because the connection can only be made through the FPGA fabric.  -and routing clocks through the FPGA fabric is usually a bad thing to do.

As you found in Vivado v2019.1, I also found in Vivado 2018.3 for an Artix-7 (xc7a100tfgg484-3).  That is, Vivado allows me to connect the output of a BUFH to the input of a BUFG – and gives no warning nor error during implementation!   However, Vivado does give the following DRC Critical Warning:

REQP-1933: The BUFG I pin should not be driven by a BUFH or else must be properly floorplanned. This connection is not routable in some cases.

As you are, I am surprised that Vivado is only giving us a DRC Critical Warning and not an implementation Critical Warning.  However, the DRC Critical Warning cannot be ignored.  Like UG472, the Critical Warning is telling us that BUFH should not be used to drive a BUFG.

I know from your other recent posts that you are trying to solve special problems related to BUFGs being separated into top-half and bottom-half groups in the Artix-7.  -and that is why you are investigating serial strings of clock buffers.  

However, for others reading this post, it is unusual and generally problematic to connect clock buffers serially (eg. BUFG => BUFH => BUFG).  This is because one clock buffer is usually enough - and adding more buffers can skew clocks in the clock tree and make it difficult for your project to pass timing analysis.

Mark

Highlighted
Historian
Historian
232 Views
Registered: ‎01-23-2009

Re: 7 series BUFG -> BUFH -> BUFG acceptable?

Jump to solution

It is important to note that the BUFH isn't a completely independent buffer.

In the 7 series device, there are 32 global clock networks. Each of these has a BUFG at the root, with 16 BUFGs in the top half of the FPGA, and 16 in the bottom. All of these BUFGs can (potentially) reach all clockable cells in the FPGA (regardless of whether they are in the top/bottom).

The 32 BUFGs actually only (directly) clock the 32 vertical spines of the global clock networks. These travel from north to south in the middle (left/right) of the FPGA, with the BUFGs in the center.

The FPGA is broken into clock regions with one set on the left and one set on the right. Each clock region is a fixed height - 50 CLBs tall. In the center of these, running horizontally are the horizontal spines of the global clock network - there are 12 of these in each clock region. Where the vertical clock spines run into the horizontal clock spines in each region, there is a connection that can be made to drive the clock on the vertical spine into the region - these are the BUFHs.

So when you put a clock on a global clock network (through a BUFG) it always goes through a BUFH to get to a clocked cell. If you don't directly instantiate a BUFH, then the BUFH remains unnamed, and multiple BUFHs (one in upto each clock region) can connect to the same vertical spine, thus allowing a global clock to drive into any clock region, and allowing a maximum of 12 global clocks in each region.

So when you go BUFG->BUFH, you are, effectively, simply giving a name to the BUFH that is used anyway and making that "branch" of the global clock network different from all others (a different net).

Now the question is what happens if you go BUFG -> BUFG. There are dedicated connections within the grouping of 16 BUFGs in the same half that allow cascading without going onto the vertical clock spine. These, however, can only be used within the same half of the FPGA (in fact, only between adjacent BUFGs). When you force the BUFG->BUFH->BUFG, you are forcing the clock to not take the dedicated cascade route from BUFG to BUFG, but instead to go onto the vertial clock spine, through a BUFH into a horizontal clock spine, and then back to the second BUFG. This is why the north BUFG -> south BUFG  may route with the BUFH, but won't without.

However, ther BUFH has to be the right BUFH. If you want to bring a clock from a north BUFG to a south BUFG, it must use the BUFH in the topmost clock region of the bottom half - the clock region where the south BUFGs live. If it uses any other BUFH, then the connection from the BUFH to the BUFG becomes unroutable.

But, I agree with markg@prosensing.com - none of this is a recommended mechanism of routing clocks.

Avrum

221 Views
Registered: ‎03-03-2017

Re: 7 series BUFG -> BUFH -> BUFG acceptable?

Jump to solution

@avrumw Thank you for the detailed explanation.   Do you know of any training course offered that may help an engineer understand the details of FPGa clocking better?    If this existed I think I would definitely sign up for it.  
Thanks.  
Tim

0 Kudos
Historian
Historian
174 Views
Registered: ‎01-23-2009

Re: 7 series BUFG -> BUFH -> BUFG acceptable?

Jump to solution

The clocking architecture of the 7 series is covered in the Desigining with the 7 Series Families class. However, now that UltraScale/UltraScale+ (which has a completely different clocking architecture) has been out for as long as it has, it may be harder to find someone offering this class (especially with Versal now out).

All of the clocking stuff is also pretty well described in the 7 Series Clocking Resources User Guide (UG472).

Avrum

0 Kudos