Xilinx Timing Constraint Questions

I need some help making sure I constrain a design properly. The input clock to the front end logic runs at 312 MHz. This is input to a DCM that produces clocks on CLK0, CLK90, and CLKDV (div by 8). I am using Xapp861 as an oversampler example so I use both edges of the CLK0 and CLK90 clocks. Data is clocked in on 8 phases by using these clocks (see the app note if you want details). Anyways, after some logic, I eventually end up with recovered data bits on the CLK0 rising edge.

I clock these bits into an 8-bit shift register, using the CLK0 clock, to make a byte of recovered data...essentially deserializing the input data. I am forwarding these bytes on to another module. That module clocks in bytes using the CLKDV clock...which is CLK0 / 8. So the byte register running at 312 MHz in the front end is input to a shift register running at 39 MHz. The front end byte register is constantly shifting in bits at 312. And the slower logic is constantyl shifting in the bytes at 39 MHz.

I have built the design with a Chipscope ILA core included that I monitor logic with. I can set a parameter to include Chipscope or not. If I use it, I can't run at 312 MHz due to the limitations of Chipscope. So I set the input clock to as high as I can to pass timing and everything works as I expect. The fastest I have used so far is 250 MHz. However, if I don't use Chipscope and crank up the clock to 312 MHz, I get errors (incorrect recovered data bytes). These are the timing constraints that I am using. This is for the 250 MHz case. I change the values for other clock speeds.

##CLK0 Constraint NET "*clkgen_clock0_out_i*" TNM_NET = "clk_0"; TIMESPEC "TS_clk_0" = PERIOD "clk_0" 250MHz HIGH 50 % INPUT_JITTER 70 ps;

##CLK90 Constraint NET "*clkgen_clock90_out_i*" TNM_NET = "clk_90"; TIMESPEC "TS_clk_90" = PERIOD "clk_90" "TS_clk_0" PHASE + 1 ns HIGH 50 % INPUT_JITTER 70 ps;

##CLKDV Constraint NET "*clkgen_clock0_div8_out_i*" TNM_NET = "clk_0_div"; TIMESPEC "TS_clk_0_div" = PERIOD "clk_0_div" "TS_clk_0" / 8 HIGH 50 % INPUT_JITTER 70 ps;

My concern is that I need to constrain paths between the front end byte that interfaces to the slower end logic. However, since the CLKDV is derived from the DCM I thought that the CLK0 and CLKDV would be phase aligned and I could be assured that even though the front end byte is changing at 312 MHz (or whatever the fast clock is) it is safe to use the CLKDV to clock those bits in at 1/8th the fast clock speed. Am I wrong? Do I need more specific constraints?

Jeez, this ended up being longer and more confusing than I had first thought. I hope it makes sense.

Thanks in advance!

Reply to
motty
Loading thread data ...

I did not research the DCM lately, so perhaps someone can correct me if I am misinformed... but I have heard rumors that for example if one uses the CLK0 and CLK2X outputs, that the outputs are phase coherent but may have significant clock skew that is a function of their respective clock loading. If this is true, perhaps the same can be said for CLK0 and CLKDV. A back-annotated timing sim may or may not reveal this.

---------- Question When chipscope was not used and errors were detected, was chipscope removed or just not exercised? If it was removed, then that would tend to support the clock skew loading theory. I suspect that if it is clock skew, one would have to change the method of how the data is transferred to the slower clock domain.

My 2 cents.

-Newman

Reply to
Newman

I have a parameterizable generate statement that controls the inclusion of Chipscope. So when I said it isn't used, it is not included in the design at all. But, I spoke too soon!

I found some problems with my recovery logic. I was able to make it fail at low speed and observed in Chipscope what is wrong. Now I need to figure out a good way to get recovered bits out of my phase bytes. My simple algorithm didn't hold up!

Reply to
motty

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.