Thanks for confirming that experiment Joel. As suspected, soft floating
point emulation isn't fast enough even on the 166MHz SF2 processor.
>From a Microsemi employee on hard FPU's:
"We are targeting FPU processors like M4 for the next gen parts but these
wont be out for a few years."
He also mentions a Microsemi employee building a FPU using the MACC blocks
on the SF2. It's possible though he says no one wants to use it without it
being an official ARM floating point core. Makes sense given the changes
you'd have to incorporate for the build toolchain.
As far as optimizations goes, kissfft supports fixed point but I'm sure
switching would cause a ripple of changes throughout the codec2 algorithm.
Going from double to single precision floats could improve things too, but
probably not enough. There's no obvious way to get a 5x improvement on a
fixed-point device without major code and algorithm modifications.
On Fri, Apr 19, 2013 at 7:33 AM, Joel Stanley <j...@jms.id.au> wrote:
> On Thu, Apr 18, 2013 at 5:27 AM, Chris Testa <tes...@gmail.com> wrote:
> > they just came out with their newest offering, the SmartFusion2. It's
> only
> > available in one package right now, with lots and lots of gates on a
> BGA-848
> > socket.
>
> I've been playing around with the SF2 starter kit for the past month
> or so. Most of the time has been spent running bare metal code, but I
> downloaded the emcraft uclinux BSP to see what the FreeDV performance
> was like.
>
> I compiled c2enc for uclinux, with modifications to avoid SEGVs caused
> by excessive stack usage (some patches to be posted). I'm not sure
> what clock rate the M3 is running at, nor if the cache is enabled. The
> system uses a SPI flash for the rootfs and 64MB of DDR as RAM.
>
> The three second voice sample hts1a was used with the codec from svn
> head running in 1600 bits mode.
>
> At -Os
> ~ # ./c2enc 1600 hts1a.raw hts1a.c2_1600
> 16.2 seconds
>
> At -O3
> ~ # ./c2enc 1600 hts1a.raw hts1a.c2_1600
> 15.4 seconds
>
> So with the current implementation, we're 5 times slower than
> real-time for the codec alone (not to mention the modem). I'm sure
> there are to be gains to be made (the double -> float patches showed
> an improvement for the Android port that I'm sure will be relevant
> here), but still that's a lot to be made up. On the list to
> investigate are the CMSIS DSP functions, a faster FFT, and then
> there's the FPGA fabric.
>
> So that answers my question to Bruce about why we're not using the M3
> for FreeDV.
>
> I look forward to seeing your hardware Chris!
>
> Cheers,
>
> Joel
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
