Glitch free operation post-mux between two asynchronous clock domains

[Altera_Forum]

I have two single-bit signals running in separate clock domains (~39MHz and ~270MHz). Each can be assumed to be arriving from registers. I need to mux these two signals depending on a flag and output the selected signal on the pin of the FPGA (Cyclone IV for anyone interested). Delay to output is not an issue. The hard part is ensuring the output is glitch free (long after the selection is made). I believe that I need an output register post-mux, but the register would need to have the clock switched between the two clock domains to function properly. 

 Using an internal PLL to change clocks is not an option. We've used up just about all of the resources available. Sampling the ~39MHz at the ~270MHz rate is also out as I have some fairly tight jitter tolerance that would fail.  I did note the Verilog example of the glitch-free clock mux in the Quartus II Handbook. I think it may be overkill for what I need, but I'm more concerned about steady state behavior more than start-up transients.  Do you think a simple clock mux behavior with a good timequest timing script would work out (or am I just out of luck)? Any suggestions would be helpful.

[Altera_Forum]

--- Quote Start ---  I have two single-bit signals running in separate clock domains (~39MHz and ~270MHz). Each can be assumed to be arriving from registers. I need to mux these two signals depending on a flag and output the selected signal on the pin of the FPGA (Cyclone IV for anyone interested). Delay to output is not an issue. The hard part is ensuring the output is glitch free (long after the selection is made). I believe that I need an output register post-mux, but the register would need to have the clock switched between the two clock domains to function properly.  Using an internal PLL to change clocks is not an option. We've used up just about all of the resources available. Sampling the ~39MHz at the ~270MHz rate is also out as I have some fairly tight jitter tolerance that would fail.  I did note the Verilog example of the glitch-free clock mux in the Quartus II Handbook. I think it may be overkill for what I need, but I'm more concerned about steady state behavior more than start-up transients.  Do you think a simple clock mux behavior with a good timequest timing script would work out (or am I just out of luck)? Any suggestions would be helpful.  --- Quote End ---    Though not sure why you think glitch will occur at mux output without any clock but I suggest synchronising slow signal onto fast clock through two stages then clock the mux with fast clock.

[Altera_Forum]

--- Quote Start ---  Though not sure why you think glitch will occur at mux output without any clock but I suggest synchronising slow signal onto fast clock through two stages then clock the mux with fast clock.  --- Quote End ---    Like I said before, sampling the ~39MHz signal at the ~270MHz clock is not an option - the resulting jitter is too high when the mux is switched to the signal at the 39MHz domain.  The glitching is from the "mux" not truly existing as a mux, but as a LUT. The LUT is not necessarily stable when it is switching between states. Adding the register stage before the FPGA pin will ensure that there is no glitching.

[Altera_Forum]

--- Quote Start ---  Like I said before, sampling the ~39MHz signal at the ~270MHz clock is not an option - the resulting jitter is too high when the mux is switched to the signal at the 39MHz domain.  The glitching is from the "mux" not truly existing as a mux, but as a LUT. The LUT is not necessarily stable when it is switching between states. Adding the register stage before the FPGA pin will ensure that there is no glitching.  --- Quote End ---    I am not sure I can follow you. if you register the 39MHz signal through two or more stages of 270MHz then that synchronises it to the fast domain glitch-free. Then you apply mux using 270MHz register before the pin on both signals; the synchronised slow and the fast signals.

[Altera_Forum]

The ~39MHz period in time is roughly 25.77 nS, the 270MHz period in time is roughly 3.7 nS. The 270MHz process will sample 6.96 times per 39MHz clock cycle. IF this were a nice even multiple, I agree that converting the 39MHz signal over to the 270MHz clock domain makes sense. Because it is not, the 39MHz signal no longer has a 25.77nS period. It will now have either a 22.22 nS or a 25.92 nS period (depending on the phase relationship between the 270MHz andd 39MHz clocks at the time of sampling.  

This variation between 22.22 nS and 25.92 nS periods is jitter. It falls far outside the allowable jitter to meet specifications.

[Altera_Forum]

--- Quote Start ---  The ~39MHz period in time is roughly 25.77 nS, the 270MHz period in time is roughly 3.7 nS. The 270MHz process will sample 6.96 times per 39MHz clock cycle. IF this were a nice even multiple, I agree that converting the 39MHz signal over to the 270MHz clock domain makes sense. Because it is not, the 39MHz signal no longer has a 25.77nS period. It will now have either a 22.22 nS or a 25.92 nS period (depending on the phase relationship between the 270MHz andd 39MHz clocks at the time of sampling.  This variation between 22.22 nS and 25.92 nS periods is jitter. It falls far outside the allowable jitter to meet specifications.  --- Quote End ---    A non official idea might be worth looking at. Connect output of mux to register clocked by 270MHz. connect a copy of its D input to preset it. Thus the rising edge of signal wouldn't wait for sampling when going from 0 to 1 for both signal.

[Altera_Forum]

I should add that the preset can pass through another slow register enabled only when flag selects slow signal to clean up any glitch