1. Home
  2. Field-Programmable Gate Arrays
  3. Virtex-4 router failures when trying to mux multiple clocks (WARNING:Route:438)

Virtex-4 router failures when trying to mux multiple clocks (WARNING:Route:438)

I have a design where I use a 40MHz input clock to create a 40MHz,

80MHz, and two variable-frequency output clocks. The variable- frequencies are 80/120, 40/60, 20/30, 10/15, 5/7.5, and 2.5/3.75 respectively. The major design utilization is as follows: 9 BUFGMUX_VIRTEX4, 2 BUFG, 1 DCM_ADV, 3 PMCD.

When attempting to integrate this clock generation block into our existing design, I receive a warning #438 during routing. I found Xilinx answer record 23873, which seems to be a problem similar to what I'm seeing. I'm just somewhat wary of the proposed solution, which is using 4 BUFGMUX's as 2:1 clock muxes and then a final 4:1 output mux based on regular logic. Has anyone else had this problem, and, if so, was this proposed fix used to solve it?

Reply to
bwilson79
Loading thread data ...

This is confusing. Are you saying the two clocks are:

Clock 1: 80 40 20 10 5 2.5

Clock 2: 120 60 30 15 7.5 3.75

What are the clocks driving? If they are used inside the FPGA you should use BUFGMUX as the final driver. Generally the frequency generation portion can be based on LUTs and FFs. In fact in the Virtex 2 parts, the BUFGMUX didn't like to have global clocks on its inputs.

In any case it looks like you may have issues if you need the output clock phase to be coincident with your input clock as any method of muxing will create relatively large delays.

HTH, Gabor

Reply to
Gabor

Sorry it was confusing, but yes, you are correct about the two varying clock frequencies. The clocks are driving logic inside the FPGA fabric. The logic does not make any assumptions about the phase of the outputs clocks w.r.t. their inputs. Are you saying I should be able to get away with using standard muxes up front and only use BUFGMUX's at the final stage? The logic is only interested in the rising edges of these clocks so I suppose a little duty cycle distortion wouldn't hurt us.

Reply to
bwilson79

If you're only interested in generating a frequency but not worried about phase, you should use standard muxes and just use the BUFGMUX as a final buffer. Since your clock output frequencies are related, I'm guessing you don't need the glitchless switching properties of the BUFGMUX you'd need when switching unrelated asynchronous clocks.

If your variable clocks are all divided down from a single input frequency (e.g. 240 MHz), it's best to place a register on the output of the mux. This can avoid glitches shorter than the minimum clock period and also help to square up the duty cycle if you need it. The output of the flip-flop can then directly drive the BUFGMUX.

I'm not too familiar with V4 routing, but in the V2 you needed to generate your clock near the edge of the chip to reduce routing delays into the BUFGMUX. If you don't put a LOC constraint on the mux output flip-flop (or LUT) you can have significant timing variation from run to run after place&route. Also important is putting a period constraint on the output clock, as I've found that the tools don't always pick the maximum frequency when attempting to determine the period from the input clock constraints.

Good Luck, Gabor

Reply to
Gabor

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.