cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
6,288 Views
Registered: ‎12-07-2010

Virtex-5 Clock IOB Placement Error - LVDS Clock placed on a CC P/N pin

Jump to solution

Hello,

 

I am trying to implement XAPP485 (V1.3) 1:7 deserialization on a Virtex-5 XC5VSX95T. The app note is targeted to the Spartan-3E, so I built it for a randomly chosen Spartan-3E device, just to see what it looked like and to make sure I understood the design.

 

After I targeted my Virtex-5 device. I had to make a few primitive changes in order for it to compile due to the differences, but those were pretty minor. The input clock is LVDS with signal names rxclkina1_p & rxclkina1_n. Under the UCF I made the following pin assignments:

 

net "rxclkina1_p" loc = "L34" ;        #IO_L10P_CC_11    
net "rxclkina1_n" loc = "K34" ;        #IO_L10N_CC_11

 

Now when I try to compile, I get the following error:

 

ERROR:Place:645 - A clock IOB clock component is not placed at an optimal clock
   IOB site. The clock IOB component <rxclkina1_p> is placed at site
   <IOB_X0Y179>. The clock IO site can use the fast path between the IO and the
   Clock buffer/GCLK if the IOB is placed in the master Clock IOB Site. If this
   sub optimal condition is acceptable for this design, you may use the
   CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a
   WARNING and allow your design to continue. However, the use of this override
   is highly discouraged as it may lead to very poor timing results. It is
   recommended that this error condition be corrected in the design. A list of
   all the COMP.PINs used in this clock placement rule is listed below. These
   examples can be used directly in the .ucf file to override this clock rule.
   < NET "rxclkina1_p" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Pack:1654 - The timing-driven placement phase encountered an error.

 

I am at a loss as to why I would be getting this error and I'm hoping someone can give me more of an explanation. I could always add the override mentioned in the error, but that seems like bad practice.

 

Looking at the Sparatan-3E schematic (I edited the pic by removing unrelated signals to make it easer to read) in the floorplanner below, you can see that the rxclkina1_p/n clock goes into an IBUFDS, where it connectes to both the CLKIN of the DCM and a D port of an IDDR2. It's not until the clock leaves the DCM that it touches a BUFG primitive and finally has access to the global buffer. If this is acceptable for the Spartan-3E, why would I have an issue with a Virtex-5?

 

Untitled.jpg

 

Thanks,

Peter.

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Guide
Guide
9,379 Views
Registered: ‎01-23-2009

The problem is that you are using "CC" pins and not "GC" pins. In Virtex-5, the "CC" pins are only able to clock the BUFIO and BUFR in the region. Only the "GC" clocks can clock the DCMs.

 

If you move the clock inputs to a "GC" pin, this error will go away.

 

By the way, this differs from family to family. In Virtex-6, some of the "CC" pins can also reach the clock management stuff in addition to the "GC" pins, and in the 7 series there are no more GCs - all the CCs can reach the MMCMs.

 

Avrum

View solution in original post

0 Kudos
1 Reply
Guide
Guide
9,380 Views
Registered: ‎01-23-2009

The problem is that you are using "CC" pins and not "GC" pins. In Virtex-5, the "CC" pins are only able to clock the BUFIO and BUFR in the region. Only the "GC" clocks can clock the DCMs.

 

If you move the clock inputs to a "GC" pin, this error will go away.

 

By the way, this differs from family to family. In Virtex-6, some of the "CC" pins can also reach the clock management stuff in addition to the "GC" pins, and in the 7 series there are no more GCs - all the CCs can reach the MMCMs.

 

Avrum

View solution in original post

0 Kudos