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.


  • $\begingroup$ 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?"). $\endgroup$ Jun 26 '20 at 7:33
  • $\begingroup$ 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)! $\endgroup$ Jun 26 '20 at 7:35
  • $\begingroup$ 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). $\endgroup$ Jun 26 '20 at 7:39

I designed a lot of DSP algorithms and I would usually be the one implementing them in an FPGA. I rarely had to explain the internals of an algorithm to other people. That beind said, it is a good idea to represent the number of bits (I usually used the s:m:f notation from Sony Playstation 2) in a block diagram/design document for every components. You should also specify whether or not the FPGA designer must truncate or round.

Otherwise if you leave the number of bits used for the internal calculations up to the FPGA designer, you're looking for trouble. Using an insufficient number of bits can render your algorithm useless or unstable.

It is also a good idea to create a fixed-point model of your algorithm in Matlab/Python/Octave/C++ for 2 reasons. First, you will be able to validate the number of bits needed so that your fixed-point algorithm behaves similarly to the floating-point arithmetic algorithm. Secondly, you will be able to compare the FPGA implementation to your fixed-point model. The FPGA implementation should behave exactly the same as your fixed-point model.

  • $\begingroup$ Do you have an example diagram you can share or point to? What's s:m:f notation? There will be test vectors to increase confidence. $\endgroup$
    – rhz
    Jun 26 '20 at 2:15
  • 1
    $\begingroup$ s: Number of sign bits m : Number of integer bits f : Number of fractional bits 1:15:16 would be a 32-bit signed fixed-point number with one sign bit, 15 integer bits and 16 fractional bits. $\endgroup$
    – Ben
    Jun 26 '20 at 2:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.