Timing Analysis

[peter.lieber]

I have a design where I have two unrelated clocks coming in and data associated with those clocks.

The design muxes between these two data sources and outputs the data and the selected clock.

Now, I have some logic after the BUFGMUX.  I constrain each input clock and constrain the output clock to have the same period and related to the fastest of the input clocks.

My problem is when the BUFGMUX is selecting the slower clock, the path from the premux register and postmux registers are TIGed and not related. 

How do I constrain the paths between pre and post mux registers such that either BUFGMUX selection won't be plagued by clock skew problems.

The subtle thing about this is that no matter which clock the bufgmux is selecting, there is never an actual clock crossing because the post mux register use the clock that is selected and the data source is changed to the data coming from the selected clock domain.

Right now, I just have a FROM TO Datapath only constraint for the slower clock.  This, however, has build-to-build problems.  Any suggestions?

[peter.lieber]

I was just going over FPGA editor and noticed that some of the nets from R2 to Rm cross a clock region boundary. Could this be the cause of the bit errors/ clock skew that is not being taken into account because of the TIG?

If so, how to I spec a net such that it will not cross a clock region boundary?

[gszakacs]

If you don't need the data from the input register that isn't selected, then

why not clock the input registers with the BUFGMUX as well?  Then everything

will be in the same clock domain.

-- Gabor

[eteam00]

It may be useful to know:

• Which FPGA family have you selected?
• Clk1 and Clk2 frequencies (this would help assess whether or not on-chip clock distribution skews might be a problem).
• If clock distribution skews deserve examination or concern, does your design  have one or two available DCMs or PLLs?

-- Bob Elkind

[avrumw]

This clock structure can definitely pose a problem. We have no information on how you are bringing Clk1 and Clk2 into the chip, and whether or not you are using a BUFG on these clocks. Regardless, though, the MUXed clock is going through an additiona BUFG/BUFGMUX than the other clocks. The delay through the BUFG is fairly significant, and therefore there is a large skew between the unmuxed clocks and the muxed clock. This can cause significant hold time violations, regardless of the constraints.

Gabor's idea of using the MUXed clock for the capture is a good one - it will keep everything on the same clock domain, and hence no skew.

If, however, you do need the data on the "non-muxed" clock, then you will need three BUFGs

  - the first clocks Clk1 at the input - this is used for capturing D1

  - the second clocks Clk2 at the input - this is used for capturing D2

  - the third is a BUFGMUX which selects between Clk1 at the input and Clk2 at the input

This way, all clocks have the same number of BUFGs, and don't have skew.

As for constraints, simply specifying the PERIOD of the two clocks naturally (as unrelated clocks) should work - the tools will not time a path between Clk1 and Clk2, only paths on the same clock.

[eteam00]

Regardless, though, the MUXed clock is going through an additiona BUFG/BUFGMUX than the other clocks. The delay through the BUFG is fairly significant, and therefore there is a large skew between the unmuxed clocks and the muxed clock. This can cause significant hold time violations, regardless of the constraints.

Your concerns, depending on input timing and bit rates, may (or may not) be real issues.  There are effective workarounds, however, using standard (more or less) source-synchronous system clock distribution techniques (e.g. PLL or DCM with MUXed and buffered clock phase-aligned to input clocks).

This way, all clocks have the same number of BUFGs, and don't have skew.

This doesn't solve the possible problem of clock <==> data skew at the FPGA interface.  Again, source clock frequencies and bit-rates are important details.

-- Bob Elkind

[peter.lieber]

Thank you for your responses.  Let me add some details to this discussion. 

1. I definitely need both clocks for pre-muxed logic.  What goes on in these domains determine the selection of the BUFGMUX.

2. I do have BUFGs on both input clocks and the BUFGMUX uses the clock directly from the pins.

3. I left out an important detail that I didn't think was necessary until avrum mentioned the delay through the BUFG.  That is I am actually muxing 3 clocks.  So, two of the clocks actually go through 2 BUFGMUXes whereas the pre-mux version goes through only 1 BUFG.

Below is a more detail schematic of what I am doing.

I believe that it may be the double BUFG delay problem, because I only see the skew errors on clk 2 and 3.  BUT, how do I spec the clock skew between the pre and post mux registers?  I can't let the tool do it because it assumes 1 clock after the mux (in my case, I have given it the same constraint as clk1.

[avrumw]

Peter,

Based on what you have described here, I am fairly confident that the problem you are having is due to the imbalance between the BUFGs.

At these frequencies, it is likely that the problem can't be fixed with a constraint. On a large device, the delay through a BUFG can be fairly substantial, potentially making the 300MHz path impossible to meet (the large skew causes hold time problems that can't be fixed by delay).

One (fairly ugly) solution is to add additional BUFGs so that all paths go through two BUFGs.

Another solution (if latency isn't important) is to go through clock crossing FIFOs at the boundaries. You would need three FIFOs, each with their input on one of the separate domains, and all three with the output on the MUXed domain.

Avrum

[eteam00]

I'm not sure if this is entirely applicable to your design, but it may give you some ideas.

You will need 6 PLLs (or DCMs) to implement this approach.

• You have 3 source clocks, A B C.

• You have 3 sets of  {PLL | BUFG | BUFIOFB}  to regenerate, phase-align, and distribute the 3 clocks.  The 3 distributed clocks are called Ag, Bg, Cg respectively.

• We have another set of 3 PLLs for the 3 source clocks: PLLmA, PLLmB, and PLLmC.

• The outputs of PLLmX are muxed together (cascaded BUFGMUXes, for example).  The 'final' BUFGMUX output clock is called ClkMUX.

• ClkMUX is buffered with a BUFIO2FB (a Spartan-6 primitive, in the absence of specific device family target), and the BUFIO2FB output drives the FB input of all three PLLmX PLLs.

• The ClkMUX clock is therefore phase aligned to the selected source clock, much as the Xg clocks are phase aligned to their source clocks.  ClkMUX should be closely phase-aligned to one of the Xg clocks.

-- Bob Elkind

[peter.lieber]

I agree. I am working on both of your solutions. We'll see which one works best.