This is a known issue and has been fixed in ISE Design Suite 12.3.
To work around the problem:
- Place a TIG constraint on the path
- Remove the IODELAYE1 BEL from the PERIOD time group.
In both cases, the IODELAY DATAOUT path will not be analyzed as a synchronous starting point.
The latter work-around is preferred, however, it becomes complicated when the TIMEGRPs that the IODELAYE1s are being added to are tool-generated.
To work around this, most of the tool-generated constraints need to be replaced by user-defined constraints so that the IODELAYE1s can then be removed from the groups.
If the tool-generated constraints remain in the design (the IODELAYE1 BELs are left as members of these time groups), then these paths are incorrectly analyzed.
# Preexisting TNMs previously used with a PERIOD constraint
NET "tx_channel_1_rx_bufr_clk" TNM_NET = "tx_channel_1_rx_bufr_clk";
NET "tx_channel_2_rx_bufr_clk" TNM_NET = "tx_channel_2_rx_bufr_clk";
# Add IODELAYE1 BELs to a new TIMEGRP
INST "tx_channel_1/IODELAYE1_0" TNM = "iodelaye1s_chan1";
INST "tx_channel_2/IODELAYE1_0" TNM = "iodelaye1s_chan2";
# Build new TGs w/o the IODELAYE1 BELs
TIMEGRP "wa_tx_channel_1_rx_bufr_clk" = "tx_channel_1_rx_bufr_clk" EXCEPT "iodelaye1s_chan1";
TIMEGRP "wa_tx_channel_2_rx_bufr_clk" = "tx_channel_2_rx_bufr_clk" EXCEPT "iodelaye1s_chan2";
# Redefine these PERIODs using the TIMEGRPs that do not have the IODELAYE1 BELs
TS_tx_channel_1_rx_bufr_clk = PERIOD TIMEGRP "wa_tx_channel_1_rx_bufr_clk" 10 ns HIGH 50%;
TS_tx_channel_2_rx_bufr_clk = PERIOD TIMEGRP "wa_tx_channel_2_rx_bufr_clk" 10 ns HIGH 50%;