#1

I have a rough idea for a new DSP module I’d like to implement. What I don’t know is if it will ultimately run in realtime.

Is there any technique for estimating how many instances of the various dsp routines (filter_1p, filter_2p, filter_svf, noise, etc) can be run simultaneously? For example could the cost in terms of cycles per tick for a given routine be calculated? What’s the total number of cycles per tick available on the blackfin as currently configured?

Apologies if the above questions don’t make sense. I’m new to the DSP world. My hope was to determine if what I’m imagining is practical before just implementing it in the hope that it will work.

#2

i think so

tagging the ones who know for certain so they’ll see your question more quickly

@zebra @Galapagoose @tehn @kelli_cain

#3
  1. at the moment, the most straightforward and accurate way to gauge CPU load in blackfin is to physically scope the BFIN_WAIT_READY pin, which is connected to PB20 on the avr32. this pin is set high at the start of the blackfin audio ISR and low at the end. since basically all the processing happens in that ISR, the width of this pulse directly shows how much of the available cycles are being used. note that this could fluctuate if lots of parameter changes are being sent, though it’s unlikley for more than one param change to occur per audio frame given that the avr32 is relatively slow.

then you would build a test module where you instantiate many copies of the DSP classes you’re interested in, and toggle their processing based on parameter input.

  1. there is a cycle counting mechanism in the blackfin architecture, (see here: http://blackfin.uclinux.org/doku.php?id=making_the_blackfin_perform) so we could add profling code to the DSP classes and transmit cycle counts back to the avr32 via bidirectional / analysis parameters (which totally work, though we haven’t really used them anywhere yet.)

  2. lastly, you can always get some idea of how heavy a given function is by disassembling it (bfin-objdump -s). of course not all instructions are equal but some familiarity with the bfin ASM can give you a good idea.

i should point out that there are tons of opportunities for optimization. one of the bits of code that i want to get back to finishing, implements block processing on the blackfin main routine instead of per-sample in the audio frame ISR. this would necessitate rewriting any/all DSP classes, but they’re not complicated. i want to get this going for a new delay module (along with interpolated read/writes.) will share the incomplete code with anyone interested in helping.

2 Likes