I need a low jitter clock mux in logic cells

[Altera_Forum]

In my application, I need to select one of 4 recovered clocks (GXB CRU outputs) to act as timing reference for other PLLs on my system. Quartus 8.1 or StratixII GX won't allow me to use the clock control block for the clock mux (because that has to be sourced from a pin or PLL), so I am forced to implement the mux in logic. 

 My problem is that Quartus is trying to be too "smart" with it's mux implementation and keeps giving me high jitter generation on the output clock. The structure of the logic blocks in the FPGA has 4 data inputs that each feed 4 LookUpTables, and two inputs that act as mux select between the 4 outputs of the LUT's. The tool keeps using my clock inputs as selects of the mux, and the select lines I want to use as data inputs (I guess because those pins have the fastest latency). The logic works out fine, but the timing sucks because the different paths through the LUTs have different latencies (sometimes 1LUT, sometimes 1MUX, sometimes 1LUT+1MUX). These different latencies and the fact that my "select" lines are thrashing around wildly (the recovered clocks are not phase aligned) introduce jitter on the output clock which gets amplified through the system, and violates my required network timing.  I've tried everything I can think of to get the tools to use the MUX atom for what it's best at, but cannot get what I'm after.  So does anyone have any idea how to get a 4:1 mux implementation that will use my static signals for the select, and the clock signals with fixed latency per input?  Thanks

[Altera_Forum]

What other methods have you considered for accomplishing your end goal? A clock mux in logic will most likely have high jitter. May I ask what protocol is the data on the GXB receivers? 

 Jake

[Altera_Forum]

The GXBs are SONET (OC48).  

 I've tried:   - hand modify the LU to implement the mux (F0 = a, F1 = b, F2 = c, F3 = d) but the Resource Property Editor won't let me move the inputs to different LU ports. Warning about being unable to modify global nets.  - synthesize the Mux structure alone and hand-stitch. Resource property editor still won't let me move the ports.  - put the 4:1 mux into its own design partition, set it to post-fitting (strict) preserve netlist & routing, accept the screwed up port placement, and re-stitch the verilog that instantiates the mux to map the function I want. Quartus still synthesized the mux, and gave me a different instantiation, with clock nets still connected to the select.

[Altera_Forum]

I've also tried several different ways to use the clock control block, but for some reason I can't figure out, CRU outputs are not legal inputs to that (at least for dynamic selection).

[Altera_Forum]

1 - Do you have any way to adjust the frequency of your reference clock to match the CRU clock? What is your reference clock source? 

2 - Do you have any feedback clock paths connected on the PCB?  FPGAs do not make very good crosspoint switches. To this date this has always been the situation with FPGA transceivers. There is no way to use a recovered CRU clock as the reference clock for a transmitter. And the reason for it is specifically jitter. They don't provide a path because the jitter is too high. I'm hoping this changes in upcoming FPGA families.  Now in the video world there is the concept of genlock. Basically what we do is have a tunable reference clock source (VCXO, DDS, etc.). We then use a phase-frequency detector to track the difference between the CRU clock and the reference clock. We can then tune our reference clock to match the frequency of the CRU clock.  Depending on what you have on the board, you might be stuck unless you can rev the board. Now you can spend the time trying to produce a low-jitter mux in logic but I suspect the jitter will still be too high to meet spec.  Jake

[Altera_Forum]

http://www.altera.com/literature/manual/stx_cookbook.pdf?gsa_pos=3&wt.oss_r=1&wt.oss=cookbook 

 Chapter 16 talks about clock synchronization.  They discuss how to build a clock multiplexer in logic cells with minimal jitter. There are also reference examples you can download at :  www.altera.com/literature/manual/cookbook.zip  Don't know if you have seen this or not yet, but might be a good start. You might have to also work with your timing analysis to break certain paths and restrictions that it might be over-analyzing. It might also be harder if you have logic both before and after the clock mux that need to be in sync with each other, but if you don't life should be easier.   Just my .02  Kevin

[Altera_Forum]

Thanks for the link. A diagram in chapter 16 seems to show a 4 input mux with stable select lines. That's exactly what I want, but I can't seem to get Quartus to give it to me. 

 I know that the logic mux is not ideal, and I'll be able to get what I need on the next rev of the board, but I've got to get something working now. So any help on synthesis constraints or whatever would be very much appreciated.  Thanks, Dave.

[Altera_Forum]

This has been quiet for a while, but I still need to be able to implement a mux in logic that has fixed latency for each of the "data" inputs, and uses my "select" inputs as the actual selects for the mux. Does anyone have ideas of synthesis constraints or verilog coding styles that can give me such a mux? 

 It turns out that the clkctrl block has some severe limitations that prevent me using it everywhere I need a clock mux.  Thanks, Dave.

[Altera_Forum]

Dave, 

  I am facing similar problem as you did with clock control block. I need to use a clock mux with dynamic switching. How did you solve your issue? If you have an example, Please post it.  Thanks, Hari.

[Altera_Forum]

Hi Hari, 

I'm sorry, but my issue here was never resolved to my satisfaction. I ended up reving the board to add clock feedback paths on the PCB, then I use a 2 input PLL as a 2:1 clock mux. I had to forget about the feature requiring 4 inputs to the mux. If you are able to rev the PCB, make sure you fully understand all the constraints about which pins are allowed to feed which kind of clock control block or pll inputs - I ended up having several wasted clock feedback routes because the input pins were un-useable for clock selection.  Hope this helps, Dave.