- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-19-2011 02:48 AM
Hi,
I experience a strange behavior when trying to cross two related clock domains. I use the following VHDL code to pass a flag from a fast to a slow domain:
-- capture incoming flag in fast domain via holded signal
gen_holded : process(clk_fast)
begin
if rising_edge(clk_fast) then
if i_data = '1' then
data_in_holded <= not(data_in_holded);
end if;
end if;
end process;
-- sync with slower clock domain, avoid metastability
sync_domains : process(clk_slow)
begin
if rising_edge(clk_slow) then
data_out <= data_in_holded;
data_out_d1 <= data_out;
data_out_d2 <= data_out_d1;
end if;
end process;
-- recreate the flag
o_data <= data_out_d2 xor data_out_d1;
The clocks are specified as follows:
# System clock, 125 MHz
NET "clk_slow" TNM_NET = FFS(*) "SYSCLK0";
TIMESPEC "TS_SYSCLK0" = PERIOD "SYSCLK0" 125.00 MHz HIGH 50%;
# Fast clock, 200 MHz, Derived from system clock via DCM
NET "clk_fast" TNM_NET = FFS(*) "FASTCLK0";
TIMESPEC "TS_FASTCLK0" = PERIOD "FASTCLK0" "TS_SYSCLK0" * 1.6;
I tried to define a FROM-TO constraint between the two clocks for the path between "data_in_holded" and "data_out", however, all variants are ignored during timing analysis or result in an error. I tried:
Variant 1
NET "data_in_holded" TNM_NET = "FX_IN" ;
NET "data_out" TNM_NET = "SYS_OUT" ;
TIMESPEC "TS_FX2SYS" = FROM "FX_IN" TO "SYS_OUT" 10ns;
--> Ignored during p&r, path does not meet timing, tries to meet timing for 1ns
Variant 2
NET "data_in_holded" TNM_NET = "FX_IN" ;
NET "data_out" TNM_NET = "SYS_OUT" ;
TIMESPEC "TS_FX2SYS" = FROM "FX_IN" TO "SYS_OUT" TIG;
--> Ignored during p&r, path does not meet timing, tries to meet timing for 1ns
Variant 3
NET "clk_fast" TNM_NET = "FX_IN" ;
NET "clk_slow" TNM_NET = "SYS_OUT" ;
TIMESPEC "TS_FX2SYS" = FROM "FX_IN" TO "SYS_OUT" 10ns;
--> Results in a warning about unallowed FROM-TO constraints for related clocks in ngdbuild, which will be ignored.
Variant 4
NET "data_in_holded" TIG ;
--> Works, path is ignored, but there should be a better solution.
The tool version is always ISE 13.1, the device is a Virtex 5 SX240t. Does anyone have an idea why the FROM-TO constraints are ignored during p&r?
Regards,
Henning
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-19-2011 07:23 AM
I would have though Variant 3 would work, but if you don't have other loads on the
net that need tighter timing then try this:
NET "data_in_holded" TNM_NET = "FX_IN" ;
TIMESPEC "TS_FX2SYS" = FROM "FX_IN" TO FFS 10ns;
This is similar to the TIG constraint but sets a limit of 10ns to the D input of other flip-flops
on any clock.
HTH,
Gabor
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-19-2011 08:08 AM
# System clock, 125 MHz
NET "clk_slow" TNM_NET = FFS(*) "SYSCLK0";
TIMESPEC "TS_SYSCLK0" = PERIOD "SYSCLK0" 125.00 MHz HIGH 50%;
# Fast clock, 200 MHz, Derived from system clock via DCM
NET "clk_fast" TNM_NET = FFS(*) "FASTCLK0";
TIMESPEC "TS_FASTCLK0" = PERIOD "FASTCLK0" "TS_SYSCLK0" * 1.6;
The fast clock looks to have a longer period, shouldn't it be 'divide by 1.6'?
Is the TS_FASTCLK0 a propagated constraint?
Is system clock input to a DCM, which generates fast clock?
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-19-2011 08:29 AM
ajmir wrote:
# System clock, 125 MHz
NET "clk_slow" TNM_NET = FFS(*) "SYSCLK0";
TIMESPEC "TS_SYSCLK0" = PERIOD "SYSCLK0" 125.00 MHz HIGH 50%;
# Fast clock, 200 MHz, Derived from system clock via DCM
NET "clk_fast" TNM_NET = FFS(*) "FASTCLK0";
TIMESPEC "TS_FASTCLK0" = PERIOD "FASTCLK0" "TS_SYSCLK0" * 1.6;The fast clock looks to have a longer period, shouldn't it be 'divide by 1.6'?
Is the TS_FASTCLK0 a propagated constraint?
Is system clock input to a DCM, which generates fast clock?
This is the sort of confusion that ensues from specifying a "PERIOD" in MHz...
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-19-2011 09:41 AM
No, as the PERIOD is specified in MHz, this is absolutely fine. However, the key problem is not the clock definition but the clock domain crossing. Both clocks are DCM outputs of the same DCM. System clock is fed back to the DCM in the clkfb input. The original input clock "clk_raw" is not listed and comes from a PCIe Endpoint Block Plus.
Hope that information helps.
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-16-2012 11:01 AM
Did you resolve this problem? I have exactly the same problem, and i am using ISE 13.1 also.
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-19-2012 12:48 AM
NET "data_in_holded" TNM_NET = "FX_IN" ;
Blocks for Timing group "FX_IN": data_in_holded , data_out;
NET "data_out" TNM_NET = "SYS_OUT" ;
Blocks for Timing group "SYS_OUT": data_out_d1
So the path from FF "data_in_holded" to FF "data_out" is not constrained by the From...To constraint
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-19-2012 01:05 AM
You should know that "NET XX_1 TNM_NET = group1" will include all the sychronous components driven by "XX_1" into timing group "group1".
Re: Clock domain crossing for related clocks
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-22-2012 03:23 PM
Did you review the BLD (NGDBuild Report) for more insight to why this constraint is being ignore?











