suggestions on 32-bit dsp

On Sunday, April 10, 2016 at 9:16:42 PM UTC-4, Randy Yates wrote:
> robert bristow-johnson <rbj@audioimagination.com> writes:
> 
...
> 
> > Randy, i can be a fixed-point partisan also (remember i used to be
> > hard-core 56K?), but what is your motivation for doing it fixed?
> 
> Oh yeah, I remember, Robert.
> 
> Simply that I think fixed-point FIR filtering is superior numerically
> (whether or not it's audible) to single-precision float. I know you know
> this: it's been discussed here before. If I were to make this into a
> product, I think this would be a selling point. And I think handling the
> main audio datapath with a 32-bit width is also appealing, both to me
> and as a potential product. 32 bits/fixed-point just kinda feels
> right.

well, you can still do fraction saving (a.k.a. 1st-order noise shaping with a zero at DC) with a SHArC.  i've done it.

say you're doing your FIR or IIR filter with the 40-bit floats.  it ain't quite double precision, but you have 8 bits beyond single precision.  there is a SHArC instruction called "RND" which rounds the 40-bit float to a normal 32-bit float.  you can then subtract the 40-bit float from the 32-bit float and the value that's left is the error signal; literally the fraction your saving.  initialize the accumulator with that (instead of zero) when you start your next sample's IIR of FIR.

if your DSP is doing coefficient calculation, it might be easier with float than fixed.

if i were a silicon guy, i would design an audio DSP strictly without floating point.  i would probably repeat most of the decisions that Bob Adams did with the Sigma DSP (hey, that's an idea for you, but it's still ADI).  he makes the words Q4.28 (or whatever notation you like) and does exactly the right thing with the least significant word after a multiply or MAC.  problem is with the Sigma is that it's too much like an FPGA or some hardware solution.  no branch instruction or conditional branch instruction.  so you can't really process samples in blocks and you can't have processing modes like you need to efficiently do processing alongside analysis.  like what happens in a pitch shifter.

so, i still agree in principle that, for a given word width, fixed beats IEEE float (with 8 exponent bits) in audio.  and that's because we don't need 40 dB of headroom.  6 or 12 dB is enough.  then 32-bit fixed leaves 30 bits for your signal whereas the mantissa (plus "hidden 1 bit" plus sign bit) in IEEE-754 has 5 fewer bits.

but if you wanna do a realtime audio product with a DSP, i think the easiest thing to do is just do it with a SHArC.  especially if you need to do transcendental math, say, to calculate coefficients, you'll have fewer headaches with floating point.

bestest,

r b-j

On Sunday, April 10, 2016 at 10:24:40 PM UTC-4, Randy Yates wrote:
> robert bristow-johnson <rbj@audioimagination.com> writes:
> > [...]
> > surprized Al hasn't piped up here yet.  so he has a little board with
> > an ASDP-21479 SHArC, stereo audio codec up to 192 kHz, DC ADC for
> > knobs, USB interface.  i think it runs at 245.76 MHz.  2560
> > instructions per sample at Fs = 96 kHz.  i thought something like 5
> > M-bit internal RAM and some kinda flash on the board.  fits into a
> > tiny stomp box with room to spare.  can run on 9v battery or just offa
> > the USB.
> >
> >  https://www.danvillesignal.com/landing-pages/snowbird-audio
> 
> PS: Is it out yet? Doesn't quite look like it. Also, can you buy it
> without Audio Weaver and just use it with your own code?

i think it's out.  and you gotta ask Al about the AW.  i dunno if his arrangement with AW is whether it's optional or not.  i have a couple of the boards that i have been diddling with, and i am not using AW.  i have opinions about doing low-level development around AW that i will not be explicit about.

r b-j

robert bristow-johnson  <rbj@audioimagination.com> wrote:

>if i were a silicon guy, i would design an audio DSP strictly without
>floating point.  i would probably repeat most of the decisions that Bob
>Adams did with the Sigma DSP (hey, that's an idea for you, but it's
>still ADI).  he makes the words Q4.28 (or whatever notation you like)
>and does exactly the right thing with the least significant word after a
>multiply or MAC.  problem is with the Sigma is that it's too much like
>an FPGA or some hardware solution.  no branch instruction or conditional
>branch instruction.  

Interesting.  I assume then that there are conditional assignment 
instructions of some variety.

I have designed processors with this characteristic.  It's nice
because there is no possibility of jitter in the run-time; there
are N clock cycles per sample, and you execute a program N instructions
long each sample.  It's also quite simple to write assemblers and 
emulators for such an architecture. 

Despite these advantages I'm a little surprised to learn that
such an approach made it into a DSP designed for general use.

Steve

On 4/10/2016 11:43 PM, robert bristow-johnson wrote:
>
> if i were a silicon guy, i would design an audio DSP strictly without
> floating point.  i would probably repeat most of the decisions that
> Bob Adams did with the Sigma DSP (hey, that's an idea for you, but
> it's still ADI).

I was going to suggest the Sigma or TI's similar processor.  But I can't 
find the details on the ACC.  Some of the info seems to say there are no 
extra guard bits in the ACC.  They expect 24 bits of the data word to be 
input data which leaves 8 for guard bits.  My problem with these devices 
is the way they work to hide all the details from you and require you to 
work with their processing blocks.


> he makes the words Q4.28 (or whatever notation you
> like) and does exactly the right thing with the least significant
> word after a multiply or MAC.  problem is with the Sigma is that it's
> too much like an FPGA or some hardware solution.  no branch
> instruction or conditional branch instruction.  so you can't really
> process samples in blocks and you can't have processing modes like
> you need to efficiently do processing alongside analysis.  like what
> happens in a pitch shifter.

Hmmm... not sure what limitations you think FPGAs have.  I think maybe 
you just don't understand them.

-- 

Rick

robert bristow-johnson <rbj@audioimagination.com> writes:

> On Sunday, April 10, 2016 at 9:16:42 PM UTC-4, Randy Yates wrote:
>> robert bristow-johnson <rbj@audioimagination.com> writes:
>> 
> ...
>> 
>> > Randy, i can be a fixed-point partisan also (remember i used to be
>> > hard-core 56K?), but what is your motivation for doing it fixed?
>> 
>> Oh yeah, I remember, Robert.
>> 
>> Simply that I think fixed-point FIR filtering is superior numerically
>> (whether or not it's audible) to single-precision float. I know you know
>> this: it's been discussed here before. If I were to make this into a
>> product, I think this would be a selling point. And I think handling the
>> main audio datapath with a 32-bit width is also appealing, both to me
>> and as a potential product. 32 bits/fixed-point just kinda feels
>> right.
>
> well, you can still do fraction saving (a.k.a. 1st-order noise shaping with a zero at DC) with a SHArC.  i've done it.
>
> say you're doing your FIR or IIR filter with the 40-bit floats. it
> ain't quite double precision, but you have 8 bits beyond single
> precision. there is a SHArC instruction called "RND" which rounds the
> 40-bit float to a normal 32-bit float. you can then subtract the
> 40-bit float from the 32-bit float and the value that's left is the
> error signal; literally the fraction your saving. initialize the
> accumulator with that (instead of zero) when you start your next
> sample's IIR of FIR.

Meh. Somewhat interesting, but I still plan on sticking with fixed-point.

> if your DSP is doing coefficient calculation, it might be easier with
> float than fixed.

Why not utilize the best of both worlds? If you're doing coefficient
calculation, and/or other math functions, at a low rate, then of course
do that with floats. But by the time you get cranking out the
convolutions, do that with fixed-point. I.e., somewhere along the 
way, convert your resulting coefficients to fixed-point.

> if i were a silicon guy, i would design an audio DSP strictly without
> floating point. i would probably repeat most of the decisions that Bob
> Adams did with the Sigma DSP (hey, that's an idea for you, but it's
> still ADI). he makes the words Q4.28 (or whatever notation you like)
> and does exactly the right thing with the least significant word after
> a multiply or MAC. 

But then wouldn't that introduce more error, instead of doing the whole
group of MACs for a sample, THEN requantize?

> problem is with the Sigma is that it's too much like an FPGA or some
> hardware solution. no branch instruction or conditional branch
> instruction. so you can't really process samples in blocks and you
> can't have processing modes like you need to efficiently do processing
> alongside analysis. like what happens in a pitch shifter.

I've heard of that device but didn't know all this about it. I still
prefer the cozy familiarity of a DSP.

> so, i still agree in principle that, for a given word width, fixed
> beats IEEE float (with 8 exponent bits) in audio. and that's because
> we don't need 40 dB of headroom. 6 or 12 dB is enough. then 32-bit
> fixed leaves 30 bits for your signal whereas the mantissa (plus
> "hidden 1 bit" plus sign bit) in IEEE-754 has 5 fewer bits.
>
> but if you wanna do a realtime audio product with a DSP, i think the
> easiest thing to do is just do it with a SHArC. especially if you need
> to do transcendental math, say, to calculate coefficients, you'll have
> fewer headaches with floating point.

Again, use the best of both worlds, eh?
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

You could consider the Atmel Sam S70:  300 MHz, TCM, SOC, FreeRTOS, Atmel has great support and tools:

http://www.atmel.com/products/microcontrollers/arm/sam-s.aspx


HTH,
-Mike Shonle



On Friday, April 8, 2016 at 4:40:35 PM UTC-4, Randy Yates wrote:
> Folks,
> 
> I'm considering an audio project and I would like to base it on a
> processor (MCU, SoC, whatever) which is capable of natively doing
> fixed-point 32-bit MACs (with a guard bits in the accumulator,
> preferably) and at least 100M MACs/second.
> 
> It looks like the Cirrus Logic CS47048 fits the bill, but if folks had
> suggestions for others I would love to hear them. Particularly,
> processors for which an RTOS (freeRTOS would be great) is available.
> -- 
> Randy Yates, DSP/Embedded Firmware Developer
> Digital Signal Labs
> http://www.digitalsignallabs.com

On Sun, 10 Apr 2016 21:16:38 -0400, Randy Yates wrote:


> That's what I thought too. I really meant in my original post "other
> than ADI," but I really like being reminded anyway about ADI's product's
> capabilities.

Because you're already familiar with ADI, or because you hate 'em with a 
purple passion?

C'mon.  Spill.

What about a 16-bitter that runs fast enough, or has parallel 
operations?  You can do a 32 x 32 FIR in four passes with a 16 x 16 MAC 
plus a bit of patching up at the end.  Ditto IIR, but the code gets a bit 
arcane.  If you can stand 16-bit coefficients with 32-bit data you can do 
it with two passes.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott <seemywebsite@myfooter.really> writes:

> On Sun, 10 Apr 2016 21:16:38 -0400, Randy Yates wrote:
>
>
>> That's what I thought too. I really meant in my original post "other
>> than ADI," but I really like being reminded anyway about ADI's product's
>> capabilities.
>
> Because you're already familiar with ADI, or because you hate 'em with a 
> purple passion?

Because I'm already familiar with them. I think ADI products are
excellent, I just haven't had a lot of experience with them.

> C'mon.  Spill.

> What about a 16-bitter that runs fast enough, or has parallel
> operations? You can do a 32 x 32 FIR in four passes with a 16 x 16 MAC
> plus a bit of patching up at the end. Ditto IIR, but the code gets a
> bit arcane. If you can stand 16-bit coefficients with 32-bit data you
> can do it with two passes.

Why choose that over something like the 21469? What would be the
advantage?
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

On Fri, 08 Apr 2016 16:40:31 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>Folks,
>
>I'm considering an audio project and I would like to base it on a
>processor (MCU, SoC, whatever) which is capable of natively doing
>fixed-point 32-bit MACs (with a guard bits in the accumulator,
>preferably) and at least 100M MACs/second.
>
>It looks like the Cirrus Logic CS47048 fits the bill, but if folks had
>suggestions for others I would love to hear them. Particularly,
>processors for which an RTOS (freeRTOS would be great) is available.
>-- 
>Randy Yates, DSP/Embedded Firmware Developer
>Digital Signal Labs
>http://www.digitalsignallabs.com

FWIW, and this seems odd even to me, the four-core ARMv8 processors,
like what are used on the Raspberry Pi 3, are actually quite good for
this sort of thing.   Even though the ARM is a very inelegant machine,
it has pretty efficient 32 and 64-bit multiply-accumulate functions,
and also hardware floating point that is also pretty efficient. 

On a Raspberry Pi 3 there are four ARMv8 CPUs running at 1.2GHz.

The SoCs on the Pi, and also on the Beaglebone, also have integrated
GPUs that can be accessed if you want gnarlier integer processing
capability.  They're less straightforward to use, naturally, but
they're there if you have some intensive tasks you want to shove off
onto them.

Both the Pi and the BBB platforms are very cheap and very capable.
I'm wondering how long dedicated DSP processors will still have a
market.

On Mon, 11 Apr 2016 13:58:12 -0400, Randy Yates wrote:

> Tim Wescott <seemywebsite@myfooter.really> writes:
> 
>> On Sun, 10 Apr 2016 21:16:38 -0400, Randy Yates wrote:
>>
>>
>>> That's what I thought too. I really meant in my original post "other
>>> than ADI," but I really like being reminded anyway about ADI's
>>> product's capabilities.
>>
>> Because you're already familiar with ADI, or because you hate 'em with
>> a purple passion?
> 
> Because I'm already familiar with them. I think ADI products are
> excellent, I just haven't had a lot of experience with them.
> 
>> C'mon.  Spill.
> 
>> What about a 16-bitter that runs fast enough, or has parallel
>> operations? You can do a 32 x 32 FIR in four passes with a 16 x 16 MAC
>> plus a bit of patching up at the end. Ditto IIR, but the code gets a
>> bit arcane. If you can stand 16-bit coefficients with 32-bit data you
>> can do it with two passes.
> 
> Why choose that over something like the 21469? What would be the
> advantage?

It would only be an advantage if you're doing something high volume and 
it makes for a cheaper bill of materials.  I'm just tossing out 
suggestions: it's your job to evaluate them for fitness.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com