Timing analyzer with Virtex 4

Hi,

I am designing with Virtex 4, which needs DCM output clk0/90/180/270 at more than 300MHz. I use a ibufg to connects the fpga input clock and connects ibufg output to DCM input directly. Then I set this constraint with period 3.2ns. I output clk0/clk90/clk180/clk270 with bufg. Unfortunately I failed timing. I checked with Timing Analyzer and got such information:

================================================================================ Timing constraint: TS_clk_90_in = PERIOD TIMEGRP "clk_90_in" TS_clk_ibufg_out PHASE 0.8 ns HIGH 50%;

2 items analyzed, 1 timing error detected. (1 setup error, 0 hold errors) Minimum period is 4.972ns.

-------------------------------------------------------------------------------- Slack: -0.443ns (requirement - (data path - clock path skew + uncertainty)) Source: u_datarecovery_a6_i/FF0 (FF) Destination: u_datarecovery_c5_i (FF) Requirement: 0.800ns Data Path Delay: 1.040ns (Levels of Logic = 0) Clock Path Skew: -0.003ns Source Clock: clk_180 rising at 0.000ns Destination Clock: clk_90 rising at 0.800ns Clock Uncertainty: 0.200ns

I am confused by the slack: (requirement - (data path - clock path skew

  • uncertainty)), Can any body help me to explain this? And how to reduce this data path dealy? Seems my design fails with this.

for anothe path, I got:

-------------------------------------------------------------------------------- Slack: 1.399ns (requirement - (data path - clock path skew + uncertainty)) Source: u_datarecovery_d5_i (FF) Destination: u_datarecovery_d4_i (FF) Requirement: 2.400ns Data Path Delay: 0.801ns (Levels of Logic = 0) Clock Path Skew: 0.000ns Source Clock: clk_180 rising at 1.600ns Destination Clock: clk_90 rising at 4.000ns Clock Uncertainty: 0.200ns

why the requirement is different between these two data path? I need them both works at the same frequency.

Thanks.

Reply to
skyworld
Loading thread data ...

--------------------------------------------------------------------------------

You've got a FF clocked by clk_180 feeding a FF clocked by clk_90. There's only 800ps between these two edges, which is your clock period, 3.2ns * (180 - 90)/360 degrees. That leaves you a slack of 0.800 - 1.040 - 0.003 -

0.200ns. Just like it says. HTH, Syms.
Reply to
Symon

Hi,

I th snipped-for-privacy@k78g2000cwa.googlegroups.com...

---------

a FF clocked by clk_180 feeding a FF clocked by clk_90. There's

Reply to
skyworld

Yes. Don't try and clock two FFs 800ps apart.

No. Change the path to something that's easier to meet.

HTH, Syms.

Reply to
Symon

Hi Symon,

thanks for your reply. I'm sorry I still have questions on your reply.

1=2E Don't try and clock two FFs 800ps apart. I have used two seperated clocks from DCM with 90 degree phase=20 seperate, why this is not correct?

2=2E Change the path to someth snipped-for-privacy@p10g2000cwp.googlegroups.com...

Don't try and clock two FFs 800ps apart.

to something that's easier to meet.

Reply to
skyworld

Are you still trying to sample data with 4 phase offset clocks? At the speed you are talking about, you are effectively making paths that need to run at a little over 1 GHz. Look at the jitter specs for the DCM clocks. That number is a pretty big portion of a ~800ps period. You may want to consider another method of doing what you need.

Reply to
motty

Hi,

My design is like this: the data is a serial data stream with data=20 rate at 312MHz. The sampling circuitry works at 312MHz also, but there=20 are four clocks to sample the data; each clock works at 312MHz, with=20 equal spaced phase shift, i.e., 312MHz with 0 degree, 312MHz with 90=20 degree, 312MHz with 180 degree and 312MHz with 270 degree. A logic=20 cell will be used to detect the transition between these four clocks=20 and determines which clock will be used to sample the data. The rule=20 is to choose the clock which is at the center of "sampling window".=20 This IP has been tested with a Spartan FPGA and works at 156MHz. Now=20 I need to migrate this to Virtex 4 and works at 312MHz. The problem I=20 met is that there is timing violation as mentioned above. I'm not=20 familiar to multi-clock designs, and I'm not familiar to set these=20 constraints with Xilinx tools, so I came here to ask for some help.=20 Xilinx's docs just give some descriptions on those aspect, but it is=20 not enough for guys like me to know how to set these constraints and=20 pass the timing. Thanks for your help and reply.

skyworld

Reply to
skyworld

Well, I recommend using Google before reinventing the wheel. XAPP224. :-) HTH, Syms.

Reply to
Symon

Hi,

Thanks for your help. I have checked the XAPP224 before, from Xilinx=20 AN documents. It is good and helpful, but not enough. Our company has=20 developed IP to sample data from high speed data rate, now my problem=20 is to verify it with 300MHz clock -- the problem focus on synthesis=20 and P&R.

snipped-for-privacy@v33g2000cwv.googlegroups.com...

mmend using Google before reinventing the wheel. XAPP224.

Reply to
skyworld

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.