[sdiy] Quality reverb on STM32's?

[Scott Gravenhorst]

Yet another thing to consider is some of the marketing tactics that are employed that may
sound good, but aren't precisely true.  An example is the dsPIC which is said to operate at a
max execution rate of 40 MIPS and is said to run most instructions at 1 clock cycle per
instruction.  However, internally, when running at "40 MIPS" (which is not a falsehood - note
that they spec it as MIPS and not MHz), there is an internal PLL that is actually clocking at
160 MHz.  So in this case, each instruction that is said to operate in 1 clock cycle really is
using 4 of the 160 MHz clocks.  I don't really "get" marketing, but I suppose there is some
psychological advantage to saying "most instructions use only 1 clock", but some of the stuff
that the dsPIC does needs 4 actual clocks (again, 160 MHz) to make them happen.  Just more
stuff to consider when reading a device's specs and trying to compare devices made by
different manufacturers.  There is also the structure of RAM busses which can allow true
parallel operations when DMA is used.  I remember that DEC PDP-11 CPUs would do DMA, but at
the expense of instruction execution which is stalled during DMA.  In the case of dsPIC, it
can move data to/from RAM with DMA while doing other things, even to the point where 2
different sections of RAM are accessed in parallel simultaneously.  It is no simple task to
compare devices with these numbers.  While the numbers can give an estimate of performance,
the way to get a precise comparison is to write the target application for each device and
compare them as a benchmark.  In my opinion...

rsdio at audiobanshee.com wrote:
>Very interesting; both responses. Thanks.
>
>One piece of information that is missing is how many clock cycles 
>each instruction takes. While many of the instructions map 
>directly to DSP opcodes that take a single cycle, I’m most 
>curious about the LOG and EXP functions. In my experience, those 
>are difficult to calculate, and require iterative algorithms. The 
>problem with an iterative algorithm is that it takes way more 
>than one cycle. If the FV-1 is able to compute LOG and/or EXP in 
>a single cycle, then that would be an incredible advantage over a 
>DSP (to my knowledge). Otherwise, if it takes a significant 
>number of cycles then I don’t see how having a special opcode 
>is much different from a subroutine on a DSP. 
>
>The TMS320 has the ability to cache an entire subroutine on the 
>chip, after initially fetching the opcodes, and then loop through 
>those instructions without any further program memory accesses. 
>That alone speeds up things so much that you can flood the data 
>memory busses unless you regroup and reoptimize. 
>
>In there information on the cycle counts for the FV-1 
>instructions? They look very promising. 
>
>Even if they’re equivalent to subroutines, it’s still 
>probably a significant boost for development time since you can 
>say what you need to say for reverb with fewer “words.” 
>
>Brian
>
>In any case, I think that STM32 implementations of reverb will be 
>significantly less efficient in one or more metrics. 
>
>
>On Apr 14, 2018, at 1:43 PM, Richie Burnett <rburnett at richieburnett.co.uk> wrote:
>> Exactly what Eric said. The FV-1 instruction set is 
>specifically optimised for the job of chorus / flange and 
>modulated reverb processing. It is most definitely not suited to 
>many things that you might normally take for granted on a typical 
>DSP. Processing audio in blocks of samples, for example. > > As 
>for the dsPIC, I find it very similar to analog devices' original 
>16-bit fixed point ADSP2181 DSP. Someone once described PICs to 
>me as "almost a decent microcontroller", (...except for things 
>like the quirky paged program memory, banked RAM etc.) In a 
>similar way i'd describe dsPIC as "almost a decent DSP." I've 
>used them in many commercial projects and they hit a certain 
>price/performance point, but they have limitations, and are no 
>TMS320 or SHARC. > > I've got an ADSP21469 4th gen SHARC board 
>here on my desk and it is a flying machine in terms of processing 
>power, I/O bandwidth and flexibility compared to dspic. But they 
>are in different price and complexity brackets of course. > > 
>-Richie, > > ---- Eric Brombaugh wrote ---- >> On 04/14/2018 
>12:23 PM, rsdio at audiobanshee.com wrote: >>> >>> The FV-1 has a 
>DSP at its core. It seems entirely unlikely that it has an 
>instruction set that is any more optimized for reverb than other 
>modern DSP options. >> >> Take a close look at the FV-1 ISA: >> 
>>> 
>http://www.spinsemi.com/Products/datasheets/spn1001-dev/SPINAsmUserManual.pdf 
>>> >> * There are single op instructions specifically constructed 
>to compute >> all-pass filters and LFOs. >> >> * There are 
>built-in exponential and sinusoid lookup instructions. >> >> * 
>The memory architecture has been designed with a built-in >> 
>auto-incrementing offset pointer that allows construction of 
>delay line >> circular buffers with implicit pointer updates. >> 
>>> * The buffer memory is a quirky kind of floating point that's 
>specially >> designed for handling audio. >> >> Granted - you can 
>do all these things with a few instructions in a >> standard DSP 
>from ADI, TI or MCHP, but they haven't been quite so >> strongly 
>focused on reverb applications. >> >> Eric 
>
>
>
>_______________________________________________
>Synth-diy mailing list
>Synth-diy at synth-diy.org
>http://synth-diy.org/mailman/listinfo/synth-diy
>?

-- ScottG
________________________________________________________________________
-- Scott Gravenhorst
-- http://scott.joviansynth.com/
-- When the going gets tough, the tough use the command line.
-- Matt 21:22