Or set the rounding options on the block to wrap / truncate, which will
probably resolve the issue.
*At the very least, set "wrap".* Any situation which causes a saturate
will be a catastrophe for the system anyways. The fact that a wrap is
twice (or more) as bad is irrelevant at that point. There's no reason
for casper FFT blocks to have a saturate option, in my opinion..
To be clear, the "fanout" issue that Issac and I resolved was atypical.
You probably shouldn't look to that first if you're having timing issues.
On 04/08/2013 04:52 PM, David MacMahon wrote:
Hi, Katty,
The first error report in the timing file shows this:
Source:
tut3_XSG_core_config/tut3_XSG_core_config/tut3_x0/fft_wideband_real_e4c9925378/fft_biplex_real_4x0_3de6c27f63/biplex_core_6535c8c7e0/fft_stage_5_6db5e3967b/butterfly_direct_eff8a62bdf/twiddle_general_4mult_3ae9ad9772/mult/Maddsub_mult_46_56
(DSP)
Destination:
tut3_XSG_core_config/tut3_XSG_core_config/tut3_x0/fft_wideband_real_e4c9925378/fft_biplex_real_4x0_3de6c27f63/biplex_core_6535c8c7e0/fft_stage_5_6db5e3967b/butterfly_direct_eff8a62bdf/twiddle_general_4mult_3ae9ad9772/convert0/convert/latency_lt_4.reg_out/partial_one.last_srl17e/reg_array[3].fde_used.u2
(FF)
This means that this timing error is occurring in the twiddle_general_4mult
block between the multiply-add DSP48 and subsequent convert block. In fact,
all of the timing erros were related to different bits of this same path. The
twiddle_general_4mult block uses the Xilinx convert block which is known to
have sub-optimal timing. The twiddle_general_4mult block should probably be
updated to use the CASPER convert block. That will likely result in better
timing, but could have other undesirable side effects (e.g. using too many
DSP48s).
Until this block is updated, you'll have to somehow ease the timing in some other way. Either use
PlanAhead to manually "pre-place" the design or add some pipelining registers to ease
timing of other tight areas (generate a verbose timing remote using ISE or the "trce"
command from the command line to find other tight areas).
Hope this helps,
Dave
On Apr 5, 2013, at 6:09 AM, katherine viviana cortes urbina wrote:
ERROR: 1 constraint not met.
PAR could not meet all timing constraints. A bitstream will not be generated.
To disable the PAR timing check:
1> Disable the "Treat timing closure failure as error" option from the Project
Options dialog in XPS.
OR
2> Type following at the XPS prompt:
XPS% xset enable_par_timing_error 0
I saw in the system.twr file the error of fanout I think this isn't the case
but if I have an error the timing in some block, someone can help identify and
fix it.
Cheers
Katty
Pd: the clock in the FPGA this is 225 MHz and the ADC 900 MHz
<system.twr>
