Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎07-26-2013

Virtex 6, MMCM frequency synthesis



I try to figure out the best configuration for forwarding an internal clock (originating from an MMCM) to differential outputs, of which 6 are connected to 200MHz ADCs and 3 are connected to 200MHz DACs. From what I have read up to now, the best solution to interface differential pins is to drive ODDR with the desired clock with the data ports tied to '1' and '0'. My questions are directed on all the stuff preceding the ODDR.


Here's my setup:


- Virtex 6 device (195T)

- external oscillator clocking the FPGA with 50 MHz


- ADCs and DACs must be clocked with 200 MHz with the clock lines coming from the FPGA (I'm aware that this is bad practice, but unfortunately there is nothing I can do about it)

- 200 MHz clock signal is synthesized of the 50MHz input utilizing an MMCM, the clock signal is used for internal logic and for clock forwarding


So here's my question: What is the most suitable setup to forward an internal clock signal to the external pins with as less as possible jitter. In principle, there are 3 setups of which I can think of (correct me if I'm wrong).


1. one MMCM to synthesize the 200MHz frequency and a second, connected to that first, which is used as a jitter filter (as described in UG362 - clocking resources)

2. one MMCM to synthesize the 200MHz frequency which is directly connected to the ODDRs

3. two MMCMs placed side by side, both of them used to synthesize a 200MHz clock

  - the first one drives internal logic only

  - the second one drives the external hardware


All 3 setups are depicted below.


Note that I've marked BUFGs in question. The clocking resources user guide recommends to directly connect the feedback clock of the MMCMs without instantiating a BUFG in between if used as frequency synthesis or jitter filter. However, I'm getting timing errors in some scenarios if I do so.

The second issue is the BUFG/BUFIO preceding the ODDRs. If I connect the output of the MMCM directly to the ODDRs the tools infer a single BUFG automatically and from that connect to all ODDRs. As to my understanding, this design does not make use of the high-performance clocks. Is it possible to force the use of the HPC? Do I need to instantiate one MMCM per clocking region in order to ensure the use of the HPC? In this case, how do I connect the 50MHz input clock to all MMCMs?





To cut a long story short: Which setup ist the best for forwarding a low jitter clock to ADCs and DACs? In either case, which BUFGs/BUFIOs do I need to instantiate?


Many thanks in advance,


0 Kudos
5 Replies
Community Manager
Community Manager
Registered: ‎07-23-2012

You can refer to to take a call on which path you should choose.
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Registered: ‎07-26-2013

Thanks for your tip. Nevertheless, some of my questions remain unanswered to me:


1. how to use HPC from MMCM to ODDR?

2. why does a BUFG in the feedback path of the first MMCM worsen the timing of the 200MHz that drives the logic?


Refering to the design assistant, setup number 3 should result in the best achievable clock forward. Is this correct?

0 Kudos
Registered: ‎07-26-2013

Additional information:


The input is a 50MHz clock with 2ps maximum jitter (as stated in the data sheet of the oscillator). The clocking wizard shows me an estimated jitter of 118ps after frequency synthesis (50MHz to 200MHz). If I take this value and build a jitter filter (MMCM with direct feedback) the clocking wizard shows me an estimated jitter of 95ps.


Is this information reliable? If yes, this would suggest that taking my first design (MMCMs in a row) is the best suitable for low jitter clock forwarding.


Any suggestions?

0 Kudos
Registered: ‎07-26-2013

Another question that comes to my mind:


If cascading two MMCMs, should I take the estimated peak-to-peak jitter of the first MMCM as a value for the generic port of the second MMCM? In my case this would be 0.024UI (118ps/5ns).


Thanks in advance

0 Kudos
Registered: ‎07-26-2013



as I was playing around a little bit and checking the timing report for each of those design cases I ended up with design number 2 (see depiction above). I do not instantiate a BUFG within the feedback path of the MMCM. A BUFG between MMCM and the ODDRs is inferred by the tools.

However, I have no idea why changing the design in one clock domain (clock forwarding) affects timing of another clock domain (to logic).




0 Kudos