1. Home
  2. Field-Programmable Gate Arrays
  3. Xilinx V-II BUFGMUX oddities..

Xilinx V-II BUFGMUX oddities..

Hello, I was wondering if someone with a bit more experience in these things than me could maybe explain this..

I have a design that has to have two versions, with very minor functional differences and one of them works, the other hes very messed up clocks, with clocks missing or very badly screwed up... Both have the same pin constaints and timings. As far as i can see the only major difference between the two in the place and route of them is as follows...

For X board (NON working..)

| clk_ret_i | BUFGMUX0S| No | 2172 | 0.272 | 1.188 |

+-------------------------+----------+------+------+------------+-------------+ | cclk_in_aux | BUFGMUX4S| No | 33 | 0.069 | 1.157 | +-------------------------+----------+------+------+------------+-------------+ | cclk_in_g | BUFGMUX3S| No | 3 | 0.000 | 1.136 | +-------------------------+----------+------+------+------------+-------------+ | dclk_g | BUFGMUX6S| No | 10 | 0.007 | 1.150 |

For Y board (working..)

| clk_ret_i | BUFGMUX2S| No | 2171 | 0.272 | 1.188 |

+-------------------------+----------+------+------+------------+-------------+ | cclk_in_aux | BUFGMUX4S| No | 33 | 0.029 | 1.167 | +-------------------------+----------+------+------+------------+-------------+ | cclk_in_g | BUFGMUX7P| No | 5 | 0.138 | 1.161 | +-------------------------+----------+------+------+------------+-------------+ | dclk_g | BUFGMUX6S| No | 10 | 0.005 | 1.111 |

These were where I let the xilinx tools (6.2 Patch 3 under linux) do the placing of the BUFGMUX's .. However it always seemed ot chose those positions..

I got round the issue by forcing them to be the Y board configuration, but i was wondering what could be the issue with the X board version above?? It wasnt a dodgy chip, as every single one of our 30 boards had the same issues..

Was just curious as to what could be causing this.. (and how to avoid it again...)

Cheers..

/\/\arc

Reply to
Marc Kelly
Loading thread data ...

Odd ....

Given the above BUFGMUX locations, I think Board X should be working and Y should have bad clocks.

Board Y BUFGMUXs for cclk_in_g and dclk_g are using adjacent BUFGMUXs which is not correct.

-Vikram.

Reply to
Vikram

Hi,

I got confirmation today that the whole system of 24 board (all with the y board clock configuration) has worked and passed the initial testing. Its part of a hep physics experiment so kind of important that it works :)

I would have though that given control over clock placing that the place &route tool wouldn't choose a non-working combination ( be that the x or y above...) but then you live and learn..

/\/\arc

Reply to
Marc Kelly

Marc, You need to consult the design considerations section of the Virtex-II data book.

Assuming you have listed all the global clocks in your design there a NO clock

conflicts. Conflicts can only exist between primary & secondary pairs (P & S, e.g.

0P & 0S may compete for the same clock resources). It is why the they are named that way.

What I see as the primary difference is that cclk_in_g is 7P (board Y) or

3S (board X). These are on different edges of the die. 7P top, 3S bottom. Given that configuration Y works I will venture an educated guess that its being driven by a input (or DCM) also in the top of the die. And in configuration X you have the same source but are now routing the global clock input to BUFGMUX3S on general interconnect all the way across the die (less than ideal at best).

Marc Kelly wrote:

Reply to
Chris Ebeling

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.