Hi, Ryan, I agree that setting wrap and truncate would probably resolve the timing issue, but I'm not so sure it's generally advisable to do so. Have you done any analysis comparing the effects of wrap and truncate vs saturate and round-to-even?
That said, I do think the implementation could be smarter about bit growth in the twiddle block(s). The twiddle step is simply a rotation in the complex plane, so I think there is no reason to grow more than one non-fractional bit. There is also little reason to grow fractional bits since rotation doesn't increase precision at all, though maybe one fractional bit could be argued for. Dave On Apr 8, 2013, at 7:37 PM, Ryan Monroe wrote: > 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> >>> >> >
