Will Fuse support ap_fixed?
Closed this issue · 9 comments
Currently the only way to translate ap_fixed type in HLS benchmarks to represent it in double. Can we add fixed type in Fuse to support that?
Yeah, it shouldn’t be profoundly hard to modify the compiler to generate fixed point numbers.
The only question I have is how subtyping should work. If a function wants a number of the type fix<M1, E1>, should it allow another number of the type fix<M2, E2> where both M2 > M1 and E2 > E1.
The ap_fixed library also comes with a variety of rounding modes for fixed point types. Should we choose a default or expose their interface?
It depends.
If the final goal is to translate *.fuse to *.cpp, I think it would be fine to expose the interface and gcc to care about the type checking.
If the ambition is to generate verilog codes or llvm with *.fuse files, we need to check detailed implementation of ap_fixed (rounding, subtyping). For example, there are corresponding rule (maybe rounding, I don't remember) in "ap_fixed.h" that decides how fix<M2,E2> shrink to smaller capacity.
Check P16-P22 in https://www.csl.cornell.edu/courses/ece5775/pdf/lecture04.pdf
There is a quantization bit and overflow bit to specify which mode to use.
Well, we 'd want to maintain explicit control from Dahlia.
If the final goal is to translate *.fuse to *.cpp, I think it would be fine to expose the interface and gcc to care about the type checking.
So even if we just generate HLS C, we'd want the configuration to happen in Dahlia and translate that to a version of HLS C that'll implement that.
I think we can start off with constrained type rules and create compatible fixed point variables from operations with quantization and overflow.
We are eventually going to compile Dahlia programs to RTL (through FuTIL’s pass infrastructure).
Regardless I think people have worked on separate libraries in RTL so it shouldn’t be a big issue.
While fixed-point types are clearly important, getting the subtyping rules "right" does indeed seem tricky. Designing an ergonomic way to treat variable-precision numerical types (integer, fixed point, and floating point) in the language seems like a substantial mini-project of its own!
@tissue3 is there a specific use case for this (a benchmark suite you'd like to try out)? If so, I can take a look and hack up something quick.
I am trying to write some Fuse code myself just for practice. Since usually the benchmarks include "ap_fixed.h" (e.g. https://github.com/KastnerRG/pp4fpgas/blob/master/examples/cordic.h), I came up with the question. I can also use double to represent the data if the work is large.
Fixed by #257.