AR# 45731

RXAUI v2.2 - Timing Failure in Marvell Mode when targeting Kintex-7 and Virtex-7 devices

Description

When targeting Kintex-7 and Virtex-7 devices in ISE 13.4 software, timing errors might be encountered using RXAUI v2.2 with the Marvell mode selected. The symptom is that the design might fail to meet timing with trce reporting a path with large clock skew on a RX path from the GTX similar to the following:

Slack: -2.329ns (requirement - (data path - clock path skew + uncertainty))
Source: rxaui_block/gt_wrapper_i/gt0_gt_wrapper_i/gtxe2_i (HSIO)
Destination: rxaui_block/mgt_rxdata_reg_8 (FF)
Requirement: 3.200ns
Data Path Delay: 3.465ns (Levels of Logic = 0)(Component delays alone exceeds constraint)
Clock Path Skew: -2.029ns (0.678 - 2.707)

Solution

The BUFH component needs to be placement constrained in the UCF near the utilized GTXs. There are three possible work-arounds:

1. Constrain BUFH with a LOC
This could either be done with a LOC (after picking the appropriate LOC in Planahead of FPGA Editor):

INST "rxaui_block/rxclk_buf_i" LOC = "BUFHCE_X1Y36";

2. Constraint BUFH with an AREA_GROUP next to the utilized GTXs (after picking the appropriate clock region) :

NET "rxaui_block/rxclk_buf" TNM_NET = "TN_rxclk_buf";
TIMEGRP "TN_rxclk_buf" AREA_GROUP = "CLKAG_rxclk_buf";
AREA_GROUP "CLKAG_rxclk_buf" RANGE = CLOCKREGION_X1Y3;

3. If clock resources are not an issue for the design, the BUFH in example_design/<compname>_block.v[hd] can be changed to a BUFG.

Was this Answer Record helpful?

AR# 45731
Date	01/10/2012
Status	Active
Type	General Article
IP	RXAUI

Page Bookmarked