suggestions on 32-bit dsp

On Wednesday, April 13, 2016 at 4:05:37 PM UTC-4, rickman wrote:
> On 4/13/2016 3:33 PM, Randy Yates wrote:
> > robert bristow-johnson <rbj@audioimagination.com> writes:
> >
> >> On Monday, April 11, 2016 at 12:08:47 PM UTC-4, Randy Yates wrote:
> >>> robert bristow-johnson <rbj@audioimagination.com> writes:
> >
> >>>> 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.
> >>
> >> well, it *is* a DSP, it's just that all of the instructions are
> >> inline.
> >
> > In my book that's not a DSP. If you want to call it one, then we'll have
> > to disagree. It is a device that performs digital signal processing, but
> > it's not a "digital signal processor" in the classical sense (IMO).
> 
> What *is* your definition of a digital signal processor then?  If it is 
> designed to primarily do digital signal processing, in my book, it is a 
> digital signal processor.   The sigmaDSP parts are not only designed to 
> do digital signal processing, it is hard to do much else with them!
> 

at least here, Rick has a point.

if you wanted to, you could use the SHArC to run a financial analysis program or a word processor.

what i consider to be a DSP is something that is optimized to do Multiply-Accumulate operations that you would find in FIR, IIR, and correlation kinda algs.  to do that with one MAC per clock, you need to be able to do the MAC and fetch two operands from different memory spaces in one clock.  double-wide accumulator, guard bits on the left, automatic saturation and rounding are also part of a DSP on a chip.  also needed is a way to do circular addressing in at least one of the memory spaces without overhead.  otherwise, any of us can do DSP on any old Intel or ARM CPU.  or an FPGA.  we just have to do all of that "manually" with our code.  lotsa shifting instructions, lot'sa masking instructions, lotsa testing or comparison instructions.  a DSP is meant to take care of that trouble for you.

r b-j


r b-j

On Wednesday, April 13, 2016 at 3:33:16 PM UTC-4, Randy Yates wrote:
> robert bristow-johnson <rbj@audioimagination.com> writes:
> 
> > On Monday, April 11, 2016 at 12:08:47 PM UTC-4, Randy Yates wrote:
> >> 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:
> >> >> 
> >> > ...
> 
> Yes, of course that's the way to do it. I had gotten confused on the
> discussion and thought you were referring to floating-point.

listen, i can think in both worlds.  i just would prefer to do coefficient calculation in floating point and i would prefer to do all of the math in a similar paradigm.  so i don't usually worry to much about sample processing in floating point even though i know, for the same word width, i can do it cleaner in fixed.  but one of the things we like to do regarding quantization, that is noise shaping, can also be done in floating point when one is forced to cast a longer word (like 40 bits in the SHArC) into a shorter word (like a standard 32-bit float).  we can still do "fraction saving" and do it efficiently, but maybe not as efficiently as we would with fixed-point.


> 
> >> > 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.

note to Rick: i ain't gonna learn how to program an FPGA to work like a general-purpose CPU or a DSP with conditional branches.  an inline-instruction processor without branches is too restrictive for my tastes.

> >> 
> >> I've heard of that device but didn't know all this about it. I still
> >> prefer the cozy familiarity of a DSP.
> >
> > well, it *is* a DSP, it's just that all of the instructions are
> > inline.
> 
> In my book that's not a DSP. If you want to call it one, then we'll have
> to disagree. It is a device that performs digital signal processing, but
> it's not a "digital signal processor" in the classical sense (IMO).
> 
> >> > 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. 
> 
> Where does headroom come from?

headroom is how much room you have above your signal before it clips.  with IEEE float with 8-bit exponents, a 32-bit float beats a 32-bit fixed (as far as quantization error is concerned) only if you require 40 dB headroom or more.

> Are you talking about bit growth
> during the multiply-accumulate? Or are you talking about dynamic
> range?

talking about dynamic range, which in dB is the sum of dB of S/N plus dB of headroom (for a fixed-point word).  if you're willing to lose 6 dB of headroom, you can gain 6 dB of S/N with a fixed-point word.  but a floating-point word has S/N determined solely by the bits of the mantissa (plus the hidden 1 bit and the sign bit, so IEEE-754 single-precision is 25 bits) no matter what the headroom is (which is like 764 dB, essentially unlimited headroom).  but the 25 bits that determine S/N is not as good as a 32-bit fixed-point, unless you demand an unreasonable 40 dB of headroom or more.

> 
> > [...]
> >> > 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?
> >
> > isn't that what using a processor that does both 32-bit fixed and
> > 40-bit float is?
> 
> Again, I thought you were advocating floating-point MACs. My mistake.
> 
> Yes, the more I look at the choices, it looks like the SHARC is just
> about the hands-down winner. Beckmann's AES presentation did a lot to
> confirm that.

might not be the most MIPS per dollar.  but if you do this with an ARM or something like that, you have to put in all of that code to take care of circular addressing, guard bits (or sufficient word width), saturation and rounding.

i would stick with a DSP also.  and as ugly as many things are in the SHArC (some of which i have learned 20 years ago and relearned this last year), it's probably the DSP with the most future in it.  still never did any TI yet in my life.

r b-j

On 4/14/2016 12:40 AM, robert bristow-johnson wrote:
> On Wednesday, April 13, 2016 at 4:05:37 PM UTC-4, rickman wrote:
>> On 4/13/2016 3:33 PM, Randy Yates wrote:
>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>
>>>> On Monday, April 11, 2016 at 12:08:47 PM UTC-4, Randy Yates
>>>> wrote:
>>>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>
>>>>>> 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.
>>>>
>>>> well, it *is* a DSP, it's just that all of the instructions
>>>> are inline.
>>>
>>> In my book that's not a DSP. If you want to call it one, then
>>> we'll have to disagree. It is a device that performs digital
>>> signal processing, but it's not a "digital signal processor" in
>>> the classical sense (IMO).
>>
>> What *is* your definition of a digital signal processor then?  If
>> it is designed to primarily do digital signal processing, in my
>> book, it is a digital signal processor.   The sigmaDSP parts are
>> not only designed to do digital signal processing, it is hard to do
>> much else with them!
>>
>
> at least here, Rick has a point.
>
> if you wanted to, you could use the SHArC to run a financial analysis
> program or a word processor.
>
> what i consider to be a DSP is something that is optimized to do
> Multiply-Accumulate operations that you would find in FIR, IIR, and
> correlation kinda algs.  to do that with one MAC per clock, you need
> to be able to do the MAC and fetch two operands from different memory
> spaces in one clock.  double-wide accumulator, guard bits on the
> left, automatic saturation and rounding are also part of a DSP on a
> chip.  also needed is a way to do circular addressing in at least one
> of the memory spaces without overhead.  otherwise, any of us can do
> DSP on any old Intel or ARM CPU.  or an FPGA.  we just have to do all
> of that "manually" with our code.  lotsa shifting instructions,
> lot'sa masking instructions, lotsa testing or comparison
> instructions.  a DSP is meant to take care of that trouble for you.

I don't think that is a great definition either.  Requiring special 
hardware means FPGAs are DSP chips as they have all the hardware 
required.  If you just need DSP like instructions, then any old 
processor qualifies if it has the instructions without regard to speed 
or hardware.

I think there is not much point to trying to define the term DSP.  The 
newer MCUs are incorporating DSP instructions, just as Intel processors 
have been doing for some time.  I think the focus on doing various DSP 
operations "without overhead" and fetching operands in a single clock is 
not really useful.  Those things are really about performance more than 
user convenience.  DSP assembly language can be some groady stuff with 
lots of details and restrictions.  Much better to let libraries do your 
work if you are just trying to get something done.  Then you only need 
to worry if the processor is fast enough, not if it is optimizing every 
clock cycle.

Heck, once I did signal processing on an FPGA, not because I needed 
speed, but because I had to have an FPGA on the board for the 
interfaces.  So it got used as an 8 kSPS signal processor as well.  lol 
  I could likely have rolled a simple CPU and done the DSP in software 
just as well and maybe had more room left in the FPGA.

-- 

Rick

robert bristow-johnson <rbj@audioimagination.com> writes:
> [...]
> talking about dynamic range, which in dB is the sum of dB of S/N plus
> dB of headroom (for a fixed-point word). if you're willing to lose 6
> dB of headroom, you can gain 6 dB of S/N with a fixed-point word. but
> a floating-point word has S/N determined solely by the bits of the
> mantissa (plus the hidden 1 bit and the sign bit, so IEEE-754
> single-precision is 25 bits) no matter what the headroom is (which is
> like 764 dB, essentially unlimited headroom). but the 25 bits that
> determine S/N is not as good as a 32-bit fixed-point, unless you
> demand an unreasonable 40 dB of headroom or more.

Ah, I see. 6 dB/bit * 7 bits = 42 dB. Thanks for explaining, Robert.

> i would stick with a DSP also. and as ugly as many things are in the
> SHArC (some of which i have learned 20 years ago and relearned this
> last year), it's probably the DSP with the most future in it. still
> never did any TI yet in my life.

Would you be willing to write some of those ugly things you've
(re)learned here? It could be helpful to me.
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

rickman <gnuarm@gmail.com> writes:

> On 4/13/2016 3:33 PM, Randy Yates wrote:
>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>
>>> On Monday, April 11, 2016 at 12:08:47 PM UTC-4, Randy Yates wrote:
>>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>
>>>>> 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.
>>>
>>> well, it *is* a DSP, it's just that all of the instructions are
>>> inline.
>>
>> In my book that's not a DSP. If you want to call it one, then we'll have
>> to disagree. It is a device that performs digital signal processing, but
>> it's not a "digital signal processor" in the classical sense (IMO).
>
> What *is* your definition of a digital signal processor then?  

Pretty much how Beckmann defined it on p.11 here:

  http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf

I would say implied is that it is also a microprocessor, with
instructions for branching, conditionals, etc., an assembly language, a
C compiler available, etc.
-- 
Randy Yates, DSP/Embedded Firmware Developer
Digital Signal Labs
http://www.digitalsignallabs.com

On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:

[snip]
> "High Reliability" is mentioned a lot in the various info, but I don't
> see any features (or many at least) that support this other than ones
> added by the chip maker.

Oh.  I thought the 'R' stood for Real time, rather than Reliable.  The 
Cortex-R page doesn't seem to say either way:

http://www.arm.com/products/processors/cortex-r/index.php?tab=Performance

"The ARM® Cortex-R® real-time processors offer high-performance computing 
solutions for embedded systems where reliability, high availability, 
fault tolerance, maintainability and deterministic real-time responses 
are essential."

Regards,
Allan

Hi,

W dniu 2016-04-14 o 09:31, Randy Yates pisze:
> rickman <gnuarm@gmail.com> writes:
(...)
>>
>> What *is* your definition of a digital signal processor then?
>
> Pretty much how Beckmann defined it on p.11 here:
>
>    http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf
>
> I would say implied is that it is also a microprocessor, with
> instructions for branching, conditionals, etc., an assembly language, a
> C compiler available, etc.

a true signal processor has six features:
1. Single cycle MAC instruction,
2. At least 3 data buses for parallel transfer of next instruction and 
two data operands,
3. Local, zero wait states RAMs or RAM blocks,
4. Hardware loops mechanism,
5. Circular and reverse carry addressing modes,
6. High precision result registers with guard bits.

SHARC has all this features, ARMs not (see page 16 in p.Beckman 
presentation).

I love signal processors programming, because can use assembler or 
C/assembler mix, everything is clear and under control, but ...

... ARM Cortex-M and -A microcontrollers are cheap, have excellent 
software tools (many of them are for free), the program code is safe in 
internal flash memory, have enough DSP power for stereo and even 5.1 
channels applications, and ARM-Cortex A15 (and higher) have 3x bigger 
power than SHARC.
24-bit fractional numbers comfortably fit 32-bit words and 64-bit result 
has 16 guard bits.

The only problem with ARMs is the lack of fifth feature, and CMSIS 
library DSP functions are not optimal.

The new, six generation SHARC is SoC having two DSP cores and ARM 
Cortex-A5. :-)

Regards

Roman

On Thu, 14 Apr 2016 10:06:52 +0000, Allan Herriman wrote:

> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
> 
> [snip]
>> "High Reliability" is mentioned a lot in the various info, but I don't
>> see any features (or many at least) that support this other than ones
>> added by the chip maker.
> 
> Oh.  I thought the 'R' stood for Real time, rather than Reliable.  The
> Cortex-R page doesn't seem to say either way:
> 
> http://www.arm.com/products/processors/cortex-r/index.php?
tab=Performance
> 
> "The ARM® Cortex-R® real-time processors offer high-performance
> computing solutions for embedded systems where reliability, high
> availability,
> fault tolerance, maintainability and deterministic real-time responses
> are essential."

No clue what the "R" is supposed to stand for; I've just seen it's name 
connected with "reliable".

I wonder what makes it more "real time" than the Cortex M?  A more 
deterministic pipeline?

-- 

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

On 4/14/2016 6:06 AM, Allan Herriman wrote:
> On Wed, 13 Apr 2016 13:15:54 -0400, rickman wrote:
>
> [snip]
>> "High Reliability" is mentioned a lot in the various info, but I don't
>> see any features (or many at least) that support this other than ones
>> added by the chip maker.
>
> Oh.  I thought the 'R' stood for Real time, rather than Reliable.  The
> Cortex-R page doesn't seem to say either way:
>
> http://www.arm.com/products/processors/cortex-r/index.php?tab=Performance
>
> "The ARM® Cortex-R® real-time processors offer high-performance computing
> solutions for embedded systems where reliability, high availability,
> fault tolerance, maintainability and deterministic real-time responses
> are essential."

What processors *aren't* real-time?  For that matter, what processors 
aren't "reliable", etc.?  I am asking what features of the R series make 
them more suitable for any task than others?  As you say, they don't 
seem to give much insight.

-- 

Rick

On 4/14/2016 3:31 AM, Randy Yates wrote:
> rickman <gnuarm@gmail.com> writes:
>
>> On 4/13/2016 3:33 PM, Randy Yates wrote:
>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>
>>>> On Monday, April 11, 2016 at 12:08:47 PM UTC-4, Randy Yates wrote:
>>>>> robert bristow-johnson <rbj@audioimagination.com> writes:
>>>
>>>>>> 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.
>>>>
>>>> well, it *is* a DSP, it's just that all of the instructions are
>>>> inline.
>>>
>>> In my book that's not a DSP. If you want to call it one, then we'll have
>>> to disagree. It is a device that performs digital signal processing, but
>>> it's not a "digital signal processor" in the classical sense (IMO).
>>
>> What *is* your definition of a digital signal processor then?
>
> Pretty much how Beckmann defined it on p.11 here:
>
>    http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf
>
> I would say implied is that it is also a microprocessor, with
> instructions for branching, conditionals, etc., an assembly language, a
> C compiler available, etc.

"The Test:  Can you do an FIR filter in roughly 1 cycle/tap?"

I thought the ARM CM4 and higher would pass this test?  Do I have it wrong?
-- 

Rick