cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
k-50
Explorer
Explorer
5,495 Views
Registered: ‎08-16-2008

Timimg problem with teo clock domains

Hi! I get  clocks using 2 casceded PLLs (1ts - 65Mhz, 2nd -100Mhz).  

I use fifo to transfer data from one clock domain to another. I have constraint with PERIOD parameters for both clocks. After timing analysys I got:  Slack (setup path): -4.847 ns. How can I solve this problem? If I clock all design with the same clock (100 or 65) I have no timing issues, but I have to transfer data with  this different rates. 

 

0 Kudos
1 Reply
gszakacs
Professor
Professor
5,481 Views
Registered: ‎08-14-2007

Look at the failing path in the timing analyzer.  If it is going from one clock to another

(source and destination clocks are different) then you can probably ignore it.  You can

add clock-crossing constraints to your design like:

 

NET "clk_65M" TNM_NET = TMGRP_M65CLK;
NET "clk_100M" TNM_NET = TMGRP_M100CLK;

TIMESPEC TS_M100_M65 = FROM "TMGRP_M100CLK" TO "TMGRP_M65CLK" 10 ns DATAPATHONLY;
TIMESPEC TS_M65_M100 = FROM "TMGRP_M65CLK" TO "TMGRP_M100CLK" 10 ns DATAPATHONLY;

In this example, the clock nets should have the name of the actual global

nets in your design.  You should see these in the timing report.  Instead

of ignoring the paths, I usually put a cap of 10 ns or whatever can be easily met,

and add the "DATAPATHONLY" keyword to prevent hold time analysis on these

nets.  This should clear up your timing errors.

-- Gabor
0 Kudos