General Description: A case has been seen where a XCV2000E design runs through PAR quickly (45 min) and with good QOR (met timing on first route iteration); however, if the following constraints are used, the runtime and QOR degrade dramatically.
NET "U_RD_SLICE/s_rar_enable" USELOWSKEWLINES ; NET "U_RD_SLICE/s_rar_load" USELOWSKEWLINES ; NET "U_RD_SLICE/s_rar_sreset" USELOWSKEWLINES ;
Placer score: 486086 --> 896512 Placer time: 25 min --> 2 hrs Timing score after 1 iter: 0 --> 6603300 Total run time: 45 min --> days
When a signal with the USELOWSKEWLINES attribute is detected, PAR automatically applies a "soft" range constraint to attempt to limit the number of columns spanned by the loads of the signals. In this design, the objects to which PAR was going to apply range constraints already have range constraints that have been set by the user. In this case, PAR should honor the user's constraints and forego introducing additional constraints.
Aside from the placer issue mentioned above, it was also found that routing performance was impacted by the use of the USELOWSKEWLINES constraint. This was corrected when a MAXSKEW constraint was also applied to these signals.
The placer problem is scheduled to be fixed in the first major release following version 3.1i.