cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
10,797 Views
Registered: ‎11-18-2013

Virtex-6 Timing Constraints

Hello,

     I am using the ML605 for interfacing to ADCs that give out data @500MHz DDR (1 Gbps). 

To achieve the same, the data clock DCO_p/n was connected to one of the MRCC pins through the HPC connector (The ADC board is a daughter card connected to the HPC connector). The DCO was made to drive a BUFG after being passed through a IBUFDS (i.e, DCO (MRCC) --> IBUFDS --> BUFG). Further, the following constraint was also placed to help meet timing:

NET "DCO_P_0<1>" TNM_NET = DCO1;
TIMESPEC TS_DCO1 = PERIOD "DCO1" 500 MHz HIGH 50%;

The above design achieved timing closure.

 

The problem is as follows:

The above design had to be ported for working on the LPC connector. The same constraints were maintained, but the DCO was reassigned to another MRCC pin that was connected to the LPC connector. 

Upon re-synthesizing (the complete tool flow), the following error was thrown by the software:

 

WARNING:Place:1154 - A clock IOB / BUFGCTRL clock component pair have been found that are not placed at an optimal clock
IOB / BUFGCTRL site pair. The clock IOB component <dco_p_0<1>> is placed at site <K26>. The corresponding BUFGCTRL
component <......./bufio_inst_clk> is placed at site <BUFGCTRL_X0Y21>. The clock IO can use the fast path between the IOB and the Clock Buffer if a) the IOB is placed on a Global Clock Capable IOB site that has the fastest dedicated path to all BUFGCTRL sites, or b) the IOB is placed on a Local Clock Capable IOB site that has dedicated fast path to BUFGCTRL sites in its half of the device (TOP or BOTTOM). You may want to analyze why this problem exists and correct it.

 

As advised by the tool, I introduced  NET  "DCO_P_0<1>" CLOCK_DEDICATED_ROUTE = FALSE; 

but the timing was not met.

 

I understand that MRCC pins can be used to drive BUFGs in their half (and hence the design worked before).The number of BUFGs used in the design is much less than the total available. 

Is the tool having some sort of memory (since the successful placement) that is not allowing it to replace the BUFG at an appropriate site? The resource utilization in the FPGA is <30% (so I guess routing is not too tight).

Please advise on how to solve this issue.

Thank you for your time in helping me out. 

0 Kudos
8 Replies
Highlighted
Moderator
Moderator
10,717 Views
Registered: ‎01-16-2013

@EnthuMan,

 

Can you try locking the BUFG in the same half Top/Bottom as that of IOB.

Check page 142 in beelow UG to know syntax for Location constraint.

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_4/cgd.pdf

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
10,667 Views
Registered: ‎05-07-2015

HI @EnthuMan

 

Using "CLOCK_DEDICATED_ROUTE = FALSE " is not the ideal way to resolve this.
Please try locking the BUFG to a cloation in the same half as the new MRCC pin of LPC connector as  suggested by syed.

Thanks
Bharath
--------------------------------------------------​--------------------------------------------
Please mark the Answer as "Accept as solution" if information provided addresses your query/concern.
Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
10,662 Views
Registered: ‎11-18-2013

Thanks for your input Syed.

I checked.... Pin K26 is in the top half of the chip and BUFGCTRL_X0Y21 is also in the top half (as per the map report; mentioned in my first post)

Please advise, as now this shouldn't be a problem (the pin and the BUFGCTRL used are in the same half).

 

For others looking for the syntax specifically for constraining BUFGCTRL.. 

https://forums.xilinx.com/t5/Implementation/How-to-constrain-BUFGCTRL-to-top-half-of-chip/td-p/195318

 

0 Kudos
Highlighted
Adventurer
Adventurer
10,651 Views
Registered: ‎11-18-2013

@nagabhar @syedz

I was doing a bit more search and found this shocker! (in Virtex-6 clocking resources ppt, (slide 7 of 27)

Clock capable pins (SRCC & MRCC) ONLY IN THE INNER COLUMNS can drive BUFGs!

So, previously AK19 was used which is in the inner column: it worked; but now K26 which is in the outer column is not able to meet timing.

I think such details should be mentioned in a lucid manner and should not have to be unearthed.

Please advise on what I can do now..... (if my understandig is correct).

 

0 Kudos
Highlighted
Guide
Guide
10,517 Views
Registered: ‎01-23-2009

You are correct - in Virtex-6, only the SRCC/MRCC pins in the inner I/O column have a dedicated connection to the BUFGs. This is in addition to the 8 "GC" pins that are also located in the inner I/O columns.

 

The inner column restriction for the SRCC/MRCC -> BUFG (and MMCM) is stated in a couple of places in the Virtex-6 Clocking User Guide - UG362 (v2.5).

 

On page 10, in the "Global Clocking Architecture" introduction

 

"Additionally, the BUFRs and CC pins in the center columns can directly drive MMCMs in the same region and
indirectly BUFGs through the vertical global clock spins that drive the BUFGs."

 

On page 13, in the descriptions of legal inputs to the BUFG

 

"Clock-capable inputs in the same half of the devices from the inner I/O columns"

 

On page 26, under the description of "Clock Capable I/O"

 

"In Virtex-6 devices, the inner I/O column clock-capable pins can also drive MMCM and BUFG clock inputs."

 

On page 63, in the "Summary of Global Clocking Connectivity", the 2nd and 3rd rows, repeat the restriction, 

 

Unfortunately, none of this helps your system...

 

Using the CLOCK_DEDICATED_ROUTE = FALSE; is going to mess up your timing, and probably won't result in reliable data capture. The only option you have is to change to "ChipSync" clocking; use the DCO on the clock capable pin to drive the BUFIO/BUFR combination - as long as the data pins associated with this interface are in the same bank as the DCO, or distributed within that bank, the bank above, and the bank below (if the DCO is on an MRCC, not an SRCC), you can capture the data with the BUFIO, and transfer it from there to the BUFR domain.

 

The problem with that is that the BUFR domain is restricted to the clock region of the BUFR and the region above and below. If you need to work with this data on a global clock, you will have to use a mesochronous clock domain crossing (CDC) circuit to bring this to a global clock. The global clock can be the DCO brought to the BUFG using the CLOCL_DEDICATED_ROUTE = FALSE, or can be the input clock to the ADC (if it is available) - as long as the two clocks trace back to the same oscillator, they are mesochronous. A shallow clock crossing FIFO is sufficient for the CDC (the distributed RAMs are ideal for this).

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
10,427 Views
Registered: ‎11-18-2013

Hello Avrum,

           Thank you for your input. I should have really read this document in greater detail. 

May I ask you to explain in a little more detail:

Using the CLOCK_DEDICATED_ROUTE = FALSE; is going to mess up your timing, and probably won't result in reliable data capture.

Absolutely true, the jitter between the different channels was quite high.

 

 

The only option you have is to change to "ChipSync" clocking; use the DCO on the clock capable pin to drive the BUFIO/BUFR combination - as long as the data pins associated with this interface are in the same bank as the DCO, or distributed within that bank, the bank above, and the bank below (if the DCO is on an MRCC, not an SRCC), you can capture the data with the BUFIO, and transfer it from there to the BUFR domain.

Do you advise to this usign a FIFO (from BUFIO to BUFR domain). However, I am afraid that this may not help as we are getting data from multiple ADCs on different banks (multiple DCOs) and the phase alignment between them is absolutely critical.

 

The problem with that is that the BUFR domain is restricted to the clock region of the BUFR and the region above and below. If you need to work with this data on a global clock, you will have to use a mesochronous clock domain crossing (CDC) circuit to bring this to a global clock. The global clock can be the DCO brought to the BUFG using the CLOCL_DEDICATED_ROUTE = FALSE, or can be the input clock to the ADC (if it is available) - as long as the two clocks trace back to the same oscillator, they are mesochronous. A shallow clock crossing FIFO is sufficient for the CDC (the distributed RAMs are ideal for this).

 

Isn't the above same as your first point (about not using the dedicated clock route constraint)?

The ADC is generating the DCO from the encode clock (the encode clock is 125MHz while DCO is 500MHz). Using the output of BUFG (with the input being the non dedicated clock route) is not working (huge jitter between the different channels).

 

And thanks again for emphasizing the need for reading the docs with greater attention. 

 

0 Kudos
Highlighted
Guide
Guide
10,393 Views
Registered: ‎01-23-2009

Do you advise to this usign a FIFO (from BUFIO to BUFR domain).

 

No. The whole idea of the BUFIO and BUFR is that they can be used as a synchronous pair. The BUFIO can clock the IOB flip-flop, the IDDR, or the high speed clock of the ISERDES, and the BUFR can clock anything in the clock region, including the low speed side of the ISERDES (this is why the BUFR can do integer division of the clock). The transfer from the BUFIO to the BUFR domain is completely synchronous (the two clocks are in phase with eachother) - no FIFO is needed, just go from the output of the IDDR or ISERDES directly into fabric logic clocked on the BUFR domain.

 

So, assuming each channel provides its own DCO clock, then you use that clock to clock the associated data for that channel - hopefully, each channel is in the same IO bank as its clock.

 

However, I am afraid that this may not help as we are getting data from multiple ADCs on different banks (multiple DCOs) and the phase alignment between them is absolutely critical.

 

This is more of an issue. Once captured and (synchronously) transferred to the BUFR domain, each channel is on its own clock domain. These domains are normally considered independent of eachother. However, if the DCOs of the different ADC are in phase, you may be able to transfer between them synchronously - I covered this before in message 2 of  this forum topic.

 

By the way, I don't see how this is any better using different BUFGs for each DCO vs. BUFRs for each DCO- unless the DCOs are kept (tightly) in phase by the ADCs, you cannot transfer between them on BUFGs either.

 

Furthermore, clocking an input interface with a BUFG clock gives pretty poor timing performance. You don't tell us what bit rate the ADCs are running at - if it is slow enough, then all mechanisms can probably be made to work, but the different clocking mechanisms have different minimum data eye requirements for capture. Take a look at message 2 of this post.

 

As for bringing all the BUFR domains to a global domain without latency uncertainty (using a clock crossing FIFO will always introduce at least one clock of latency uncertainty, and there is no real way to avoid that), that will depend on the frequency of the interface. Below a certain frequency it should be possible - the difference in clock insertion between a BUFG and a BUFR is a couple of nanoseconds (2 or so), so if you can work at slower rates, you may be able to do this in spite of the unkown insertion difference. You may even be able group your samples together into a wider bus (say 2, 4, or 8 consecutive sample), and then do the crossing every 2nd, 4th or 8th clock - at these rates, you should probably be able to accommodate the latency difference... Analyzing this in Vivado is realtively easy and accurate - however, you are using a Virtex-6, so you have to use ISE - ISE doesn't really do proper internal min-max hold time checking...

 

Avrum

Tags (2)
Highlighted
Adventurer
Adventurer
10,334 Views
Registered: ‎11-18-2013

Hello Avrum,

          Thank you very much for your time and effort in answering my query.

It will take me atleast a few days to digest everything that you have written :)

I will work on it and get back to you in a few days.

Thanks again.

0 Kudos