fpga FFT input data type

[Jed_Davidow]

I am using the FFT on a 9076 FPGA, in a single cycle loop, and I will be processing data from both a 9205 and a 9235.

The 9205 FXP is 26,5, while the 9235 is 24,-4.  What is the best way to deal with this?

I am not sure what will fit (I am finally compiling as I type this), but I am hoping to have 4-8 multiplexed FFT pipelines running in parallel.  While I understand FXP, I am a little shaky when it comes to how and when to handle conversions.

Thanks!

[JLewis]

To handle both with the same precision as you would get individually, you would need to use the superset of the two FXP types. One trick to figure that type out is wire a control of each FXP type to the inputs of a Select function and observe the resulting output type (<s,33,5> in this case).

That is likely larger than you need, so options include using a dedicated FFT for each type, reducing the types to the minimum precision required, and/or scaling one of the channels to align with the other. You can check the specs for those two modules to get an idea of what precision they actually provide. A 16-bit module with calibration applied normally needs 20 bits to meet the hardware specs, so you could try a type of <s,20,5> for that one, discarding 5 LSBs.

For the scaling idea, use Reinterpret Number to cast the <s,24,-4> type to <s,24,5> to align with the other type (essentially a free multiply by 2^9). Since the FFT is a linear operation, you can simply correct the output with another cast in the opposite direction by subtracting 9 from whatever the output IWL is.

Finally, keep in mind that all coercions default to saturate and round to nearest even, so use explicit conversions if you want to save resources by truncating when operating on mismatched types.

[Jed_Davidow]

I should have been more explicit; I can use a separate FFT for both types; but I can't seem to understand how the FFT function is setting its input type.

[JLewis]

OK, that's a bit easier! The FFT limits the input word length to 24 bits and output to 32 bits. Inputs greater than 24 bits will be coerced by dropping the lowest bits with round to nearest even rounding mode. A <s,25,5> input becomes <s,24,5> at the FFT node boundary. The easiest way to verify this is to wire the real input, then create a control on the imaginary input to see what its type is.

All FXP nodes use this behavior when inputs or outputs exceed supported limits, and should document when the limit is anything other than 64. I submitted a corrective action request fix (CAR 364863) to document this limitation for the FFT.

Thanks,

Jim

[Jed_Davidow]

Ah, thank you.  I was wondering how that worked.

As for coding practices, is it OK to use the coersion dots there?  Or do I want to convert on my own first?

[JLewis]

In general, for FPGA apps it's better to explicitly convert just so you can clearly identify where a conversion is taking place and whether it is consuming hardware resources or not. In cases where data width is reduced, coercion dots indicate that hardware is being used to implement saturation and/or round to nearest even. In this case, you might want to consider an explicit conversion set to truncate the last 5 or so fractional bits if you find it doesn't affect your results.