We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 29751

9.2i Spartan-3E MAP - Implementation of IBUF_DELAY_VALUE and DRC checking are inconsistent with documentation


I have specified a value for IBUF_DELAY_VALUE in my design. When I examine the resulting configuration, it does not appear to be consistent with the User's Guide documentation on the subject. The Initial Delay mux configuration is not configured for some delay values where it would be expected. Also, when I use the editor to change the configuration, DRC check reports an incompatibility between the pre-delay and delay values that are unexpected.

Spartan-3 Users' Guide, page 322:


"ERROR:PhysDesignRules:1047 - Improper DELAY programming. The comp TAP_6_IN has pre delay programming. This programming requires an instance of the PRE_DELAY block. Either lower the DELAY_VALUE setting or modify the connectivity for PRE_DELAY."

"ERROR:PhysDesignRules:1048 - Improper DELAY programming. The comp TAP_6_IN has PRE_DELAY connectivity without pre delay programming. Either increase the DELAY_VALUE setting or modify the connectivity to exclude PRE_DELAY. "


For Spartan-3E, the delay configuration needed is more complex than the representation in the User's Guide and is dependent on the placement location in the device, something the tools were not designed to handle well. The implementation tools have been modified to accept only supportable configurations, but the resulting configuration might appear incorrect. In the end, the Initial Delay configuration does not matter because BitGen does not use it. BitGen configures the delay value appropriately based on the component placement and the delay value requested.

To work around any DRC errors encountered in FPGA Editor, configure the Initial Delay however necessary to satisfy the DRC checking, then, depend on BitGen to configure the Initial Delay appropriately depending on the delay requested and the placement location.

AR# 29751
Date 12/15/2012
Status Active
Type General Article
Page Bookmarked