I would think, that a floating pt implementation on a soft FPGA
processor core with floating point would take less area that a purely
FPGA fixed point HDL implementation. The reason is that the amount of
work required to do (in terms of computations per cycle) does not really
take advantage of the parallelism of an FPGA . and a basic soft core
with an FPU can easily run fast enough on even the slowest FPGA fabric
around....
However, I suspect that codec2 could easily work within small fractional
integer space (32 to 40 bit) without changes, and not have any scaling
issues and be completely scaling free in a 64 bit fractional integer space.
My usual rule - if it can be run in a high level language in software,
then don't do it in fpga fabric as HDL ... probably applies.
I'm currently implementing codec2 for RISC-V (F) in floating point. In
many RISC-V implementations, there is the facility to generate in the
HDL custom instructions that can be inserted into the code which can
provide , for example, vector speedups.
In my opinion, There's a good reason though not to go too far from
'reference C code' if possible, unless, for example there are struct
power consumption limits----- as changes to the mainline become slower
and more difficult to propagate into different platforms if someone
needs to spend the time to (heavily) optimize.
If the use of fixed point requires regular scaling, it probably becomes
a pain to be linked to the mainline reference code unless the scaling
requirements are scripted and automatic. This breathes light for me
into thinking about a purely 64bit fractional ALU fractional implementation.
In the RISCV -custom instruction support , one could add fractional ALU
instructions that MACRO out the std asm to hide the shifts from the
programmer and compiler.
-glen
On 28/12/2023 7:36 am, Mooneer Salem wrote:
Hi Tomas,
Someone did a FPGA implementation a while back for a university
project. That's the closest we've gotten to a fixed-point
implementation. Right now, there are no plans to port it officially
but this may be revisited later.
Thanks,
-Mooneer K6AQ
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
