So truncate is actually kind of hard to decide on. In general, I've had
mixed results with regard to using round-to-even, versus "truncate, but
use one extra bit". I think that the round choice is more important on
a coherent application, but this is still guesswork.
Saturate is much easier. Anytime you saturate, your snr is basically
ruined. It's like clipping your ADC. In DSP land, it's like adding a
huge delta function at each saturate/wrap point (bigger delta for a
wrap). Do it once in a thousand times and your SNR is instantly down to
~30 dB. That being said, the rule of thumb is "never, EVER clip any
part of your signal chain". So its reasonable to use wrap... since once
you saturate, it's so bad (and obvious) that using saturate isn't even
important anymore.
With bit growth, I used to go for an analytical solution -- or even just
a strong rule-of-thumb. I have a few of the latter nowadays, but I
pretty much just do robust SNR analysis against expected values, reduce
until I'm just marginal and then add back 2-3 bits to be safe.
On 04/08/2013 09:44 PM, David MacMahon wrote:
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>
