Maybe a stupid question, but I couldn't find it in the datasheet.
Is the fxcore delay memory floating point as in the fv1 or is it just 16bit int?
FXcore delay memory
Re: FXcore delay memory
16-bit linear, not floating point.
Re: FXcore delay memory
Is there a way to estimate how many cycles each delay memory read consumes? I understand it might be different based on the sample rate.
I have a design using large FIRs that may require up to 400 MACs from delay memory and I'm wondering if it would be practical on fxcore.
I have a design using large FIRs that may require up to 400 MACs from delay memory and I'm wondering if it would be practical on fxcore.
Re: FXcore delay memory
400 MACs is a huge number. I doubt the delay read on FXCore would be the limiting factor (internal memory is SRAM so very fast R/W), it would probably be the multiply in each MAC. Multiplies are "slow" as there are many gates to go through. My guess is the FXCore would not work in this case. I am assuming you are trying to do a convolution with that many MAC ops and FXCore was optimized for more general audio effects so it has built in instructions to support all-pass filters, etc. but not parallel multiply type ops.
Re: FXcore delay memory
Yes, sort of a convolution. That sounds right. I can still get close if a few hundred RDDEL instructions will fit. I will give it a shot.
Thanks for your answers.
Thanks for your answers.
Re: FXcore delay memory
Will be interesting to see the results of your test.
FXCores can be run serially, output of one into the input of another. So depending on target function, costs, speed requirements, etc. this may be a solution.
FXCores can be run serially, output of one into the input of another. So depending on target function, costs, speed requirements, etc. this may be a solution.
Re: FXcore delay memory
Here's some results from my testing tonight with the dev board.
I wrote some scripts to generate large programs with a lot of instructions and blink the led at the end to prove that it's still alive. It was quite clear when it gives up: the led stops blinking and i2c becomes unresponsive.
At 48 kHz, I can do about 175 MACID instructions before it gives up. Moving the sample rate down to 12 kHz and we can handle around 400.
Another approach I tried is to instead do a pair of RRDEL + ADDS instructions to accumulate many delay reads without multiplies. At the more usable rate of 32 kHz I was able to run a loop of about 450 of those. That uses most of the instructions and it doesn't overrun.
I wrote some scripts to generate large programs with a lot of instructions and blink the led at the end to prove that it's still alive. It was quite clear when it gives up: the led stops blinking and i2c becomes unresponsive.
At 48 kHz, I can do about 175 MACID instructions before it gives up. Moving the sample rate down to 12 kHz and we can handle around 400.
Another approach I tried is to instead do a pair of RRDEL + ADDS instructions to accumulate many delay reads without multiplies. At the more usable rate of 32 kHz I was able to run a loop of about 450 of those. That uses most of the instructions and it doesn't overrun.
Re: FXcore delay memory
That is very interesting info, we had not optimized the design for convolution but it appears a small one is doable. At 32K it should do over 200 MACIDs bases on the number you gave so 2 FXCores in series each doing 200 MACs should leave some space for pre and post processing of the signal in each FXCore.