unexpected output about dblclockfft HOT 3 OPEN

If you take the IFFT of the ouput, and compare it to the input, you can see there were two overflows in the first stage at positions 26 and 90.

Digging a bit further, in timestep 1660, in stage_128.FWBFLY.bfly.do_rnd_right_i.genblk8, you have the input 0x7baafdf4e0. (This is one of two problematic timesteps, but one should be sufficient for discussion.) This gets truncated to 17'h0eabf or rounded to 17'h0eac0, both of which lose the sign bit.

Try adding another bit to your incoming signal, or dropping your amplitude by 2x to avoid overflow.

Dan

from dblclockfft.

Thanks for answering :)

Nice approach, I couldn't find where the overflow was happening. Reducing the amplitude is a good workaround, but I'm not sure if that's enough to be certain that there couldn't be any overflows in some stage. Is that it?

Have you considered that the cpp generator implements the addition of this bit (or the division by 2) in the input so full-range inputs would not cause overflows, without having to take care of that from outside the core? (assuming this bit addition is enough)

Thanks,

K.

from dblclockfft.

Have you considered that the cpp generator implements the addition of this bit (or the division by 2) in the input so full-range inputs would not cause overflows, without having to take care of that from outside the core?

Yeah, I'm looking into that. That's supposed to be what takes place.

At issue is how many bits to drop in the first stage (or any stage thereafter). My general rule of thumb, backed by a lot of math, has been to drop one bit every other stage--since that's the rate the noise accumulates. It's also been appropriate for most of my uses of the core so far. That said, overflow is a bad thing ... so, it's something I'm (now) looking into (again).

Dan

from dblclockfft.