# Clear examples of Fixed Point Algorithm Specification Block Diagram for FPGA Implementer

I have been working on converting a simple, floating point algorithm to fixed point and need to create a block diagram to help the guy who will implement this on an FPGA. As often is the case, the output can be represented as a linear combination of (the real and imaginary parts) of some input signals.

I would like to create a clear block diagram that shows bit-widths, rounding vs truncation, saturation at each point, bit shifts (due to multliplying integers with fractions) etc. (Do you use Qmn notation in the diagram?). Most of what I've seen online is either so detailed with HW registers, etc that I can't actually tell what's going on or so high level, that it's essentially a conceptual representation of the algorithm with some annotations containing bit widths.

While I recognize that there is no one right answer, I'm curious to know how others create good diagrams to hand the algorithms off to implementers.

Thanks.

• From a human point of view: I think you should probably just write an email or call your FPGA engineer. He will have a diagram she or he personally really liked. Also, it's not really clear what the "boundary" between your job and their job is; probably it's blurry in reality, because they might have feedback on your proposed architecture (think this: "your fixed-point implementation looks fine, but at step 23, you need a 39 bit multiplier at a high speed, and we can't have one. Can't we do step 20 to 24 in 8bit mantissa and 9 bit exponent floating point?"). Jun 26, 2020 at 7:33
• I hence think that high-level is probably the way you want to go: it's not your job to implement it, so don't make unnecessarily many assumptions on how that needs to be done. The mathematical representation of what should happen inside a block, plus the in- and out bitwidths, truncation/saturation/rounding modes, and necessary minimum rate this should work at would probably make the FPGA engineers' live easier than if you tried to know what they know about how to write good FPGA implementations. Don't overspecify interfaces (Qnm sounds like you want to do that)! Jun 26, 2020 at 7:35
• What they will probably be very happy about is if you can provide them with overall test data, i.e. give them an array of numbers that if given into the whole thing gives you another array of numbers. Their life is mostly writing testbenches, and that's annoying when you don't know what to test. and you then only get to see your code again when someone says "doesn't work in integration". Start small (like, if you feed in only zeros, you should see a constant output 1), then work up (if you insert 1000 zeros, then 1 one, then 999 zeros, you should see a change in output after 1020 zeros). Jun 26, 2020 at 7:39