eric.jacobsen@ieee.org (Eric Jacobsen) writes:> On Tue, 12 Apr 2016 11:55:16 +0200, Roman Rumian > <rumian_usun_to@agh.edu.pl> wrote: > >>Hi Tim, >> >>W dniu 2016-04-09 o 05:54, Tim Wescott pisze: >>(...) >>> Basically, I know that the Cortex-A7 has the instructions, and goes fast >>> enough to do what you want. Whether it's the right choice is for you to >>> cypher out. >> >>have a look at Paul Beckmann from DSP Concepts presentation comparing >>SHARC and Blackfin signal processors with ARMs Cortex-M and - A. >> >>http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf >> >>Best regards >> >>Roman > > > That makes the point pretty well....which is the M7 (as well as other ARM offerings except the A15) still lags significantly behind a "true" DSP like the SHARC. Yay DSPs! -- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
suggestions on 32-bit dsp
Started by ●April 8, 2016
Reply by ●April 12, 20162016-04-12
Reply by ●April 12, 20162016-04-12
On 4/12/2016 12:24 PM, Randy Yates wrote:> eric.jacobsen@ieee.org (Eric Jacobsen) writes: > >> On Tue, 12 Apr 2016 11:55:16 +0200, Roman Rumian >> <rumian_usun_to@agh.edu.pl> wrote: >> >>> Hi Tim, >>> >>> W dniu 2016-04-09 o 05:54, Tim Wescott pisze: >>> (...) >>>> Basically, I know that the Cortex-A7 has the instructions, and goes fast >>>> enough to do what you want. Whether it's the right choice is for you to >>>> cypher out. >>> >>> have a look at Paul Beckmann from DSP Concepts presentation comparing >>> SHARC and Blackfin signal processors with ARMs Cortex-M and - A. >>> >>> http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf >>> >>> Best regards >>> >>> Roman >> >> >> That makes the point pretty well. > > ....which is the M7 (as well as other ARM offerings except the A15) still > lags significantly behind a "true" DSP like the SHARC. Yay DSPs!Performance is actually a black and white requirement. "More" is not better, only "enough". The various flavors of the ARM processors have many advantages over many DSPs which make them the preferred solution in many products. Interesting that they benchmarked the chosen processors in floating point except for the Blackfins which used fixed point. Also interesting that the Blackfin 5xx did not really excel against any of the ARMs and the ARM A15 was the clear winner based on speed alone running up to 3 times faster than the SHARC. I haven't been keeping up with the Cortex R series lately. I assume they have not been getting the benefit of DSP type instructions? The only company I know making them is TI where they seem to be targeted to automotive and high-rel apps. Looks like ARM lines will be narrowing to the M and the A. -- Rick
Reply by ●April 12, 20162016-04-12
On Friday, April 8, 2016 at 1:40:35 PM UTC-7, 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.comHas anyone worked with the TI Keystone II ARM/DSP SoC? I have really wanted to get the eval board to play around with. I keep looking for a cheap uATCA chassis on ebay which would make it more useful. Mark
Reply by ●April 13, 20162016-04-13
On Tue, 12 Apr 2016 13:36:44 -0400, rickman wrote:> On 4/12/2016 12:24 PM, Randy Yates wrote: >> eric.jacobsen@ieee.org (Eric Jacobsen) writes: >> >>> On Tue, 12 Apr 2016 11:55:16 +0200, Roman Rumian >>> <rumian_usun_to@agh.edu.pl> wrote: >>> >>>> Hi Tim, >>>> >>>> W dniu 2016-04-09 o 05:54, Tim Wescott pisze: >>>> (...) >>>>> Basically, I know that the Cortex-A7 has the instructions, and goes >>>>> fast enough to do what you want. Whether it's the right choice is >>>>> for you to cypher out. >>>> >>>> have a look at Paul Beckmann from DSP Concepts presentation comparing >>>> SHARC and Blackfin signal processors with ARMs Cortex-M and - A. >>>> >>>> http://www.dspconcepts.com/sites/default/files/white-papers/PD8_Beckmann.pdf>>>> >>>> Best regards >>>> >>>> Roman >>> >>> >>> That makes the point pretty well. >> >> ....which is the M7 (as well as other ARM offerings except the A15) >> still lags significantly behind a "true" DSP like the SHARC. Yay DSPs! > > Performance is actually a black and white requirement. "More" is not > better, only "enough". The various flavors of the ARM processors have > many advantages over many DSPs which make them the preferred solution in > many products. Interesting that they benchmarked the chosen processors > in floating point except for the Blackfins which used fixed point. Also > interesting that the Blackfin 5xx did not really excel against any of > the ARMs and the ARM A15 was the clear winner based on speed alone > running up to 3 times faster than the SHARC. > > I haven't been keeping up with the Cortex R series lately. I assume > they have not been getting the benefit of DSP type instructions? The > only company I know making them is TI where they seem to be targeted to > automotive and high-rel apps. Looks like ARM lines will be narrowing to > the M and the A.The new hot-off-the-fab Xilinx Zynq devices have a pair of Cortex R5 on die (in addition to four A53 cores, a bunch of other hard IP and a big whack of Ultrascale+ FPGA fabric). Regards, Allan
Reply by ●April 13, 20162016-04-13
On 4/13/2016 6:35 AM, Allan Herriman wrote:> On Tue, 12 Apr 2016 13:36:44 -0400, rickman wrote: >> >> Performance is actually a black and white requirement. "More" is not >> better, only "enough". The various flavors of the ARM processors have >> many advantages over many DSPs which make them the preferred solution in >> many products. Interesting that they benchmarked the chosen processors >> in floating point except for the Blackfins which used fixed point. Also >> interesting that the Blackfin 5xx did not really excel against any of >> the ARMs and the ARM A15 was the clear winner based on speed alone >> running up to 3 times faster than the SHARC. >> >> I haven't been keeping up with the Cortex R series lately. I assume >> they have not been getting the benefit of DSP type instructions? The >> only company I know making them is TI where they seem to be targeted to >> automotive and high-rel apps. Looks like ARM lines will be narrowing to >> the M and the A. > > The new hot-off-the-fab Xilinx Zynq devices have a pair of Cortex R5 on > die (in addition to four A53 cores, a bunch of other hard IP and a big > whack of Ultrascale+ FPGA fabric).Do they give any indication of how the R5 are intended to be used? Is this chip targeted to high safety/reliability designs? -- Rick
Reply by ●April 13, 20162016-04-13
On Wed, 13 Apr 2016 10:58:33 -0400, rickman wrote:> On 4/13/2016 6:35 AM, Allan Herriman wrote: >> On Tue, 12 Apr 2016 13:36:44 -0400, rickman wrote: >>> >>> Performance is actually a black and white requirement. "More" is not >>> better, only "enough". The various flavors of the ARM processors have >>> many advantages over many DSPs which make them the preferred solution >>> in many products. Interesting that they benchmarked the chosen >>> processors in floating point except for the Blackfins which used fixed >>> point. Also interesting that the Blackfin 5xx did not really excel >>> against any of the ARMs and the ARM A15 was the clear winner based on >>> speed alone running up to 3 times faster than the SHARC. >>> >>> I haven't been keeping up with the Cortex R series lately. I assume >>> they have not been getting the benefit of DSP type instructions? The >>> only company I know making them is TI where they seem to be targeted >>> to automotive and high-rel apps. Looks like ARM lines will be >>> narrowing to the M and the A. >> >> The new hot-off-the-fab Xilinx Zynq devices have a pair of Cortex R5 on >> die (in addition to four A53 cores, a bunch of other hard IP and a big >> whack of Ultrascale+ FPGA fabric). > > Do they give any indication of how the R5 are intended to be used? Is > this chip targeted to high safety/reliability designs?IIRC the Cortex-R is intended for high reliability applications. I'm only passingly familiar with it -- it's passed across my bench in a couple of short-lived down-hole projects that never really got off the ground. -- www.wescottdesign.com
Reply by ●April 13, 20162016-04-13
On 13 Apr 2016 10:35:04 GMT, Allan Herriman <allanherriman@hotmail.com> wrote:>On Tue, 12 Apr 2016 13:36:44 -0400, rickman wrote: > >> On 4/12/2016 12:24 PM, Randy Yates wrote: >>> eric.jacobsen@ieee.org (Eric Jacobsen) writes: >>> >>>> On Tue, 12 Apr 2016 11:55:16 +0200, Roman Rumian >>>> <rumian_usun_to@agh.edu.pl> wrote: >>>> >>>>> Hi Tim, >>>>> >>>>> W dniu 2016-04-09 o 05:54, Tim Wescott pisze: >>>>> (...) >>>>>> Basically, I know that the Cortex-A7 has the instructions, and goes >>>>>> fast enough to do what you want. Whether it's the right choice is >>>>>> for you to cypher out. >>>>> >>>>> have a look at Paul Beckmann from DSP Concepts presentation comparing >>>>> SHARC and Blackfin signal processors with ARMs Cortex-M and - A. >>>>> >>>>> http://www.dspconcepts.com/sites/default/files/white-papers/ >PD8_Beckmann.pdf >>>>> >>>>> Best regards >>>>> >>>>> Roman >>>> >>>> >>>> That makes the point pretty well. >>> >>> ....which is the M7 (as well as other ARM offerings except the A15) >>> still lags significantly behind a "true" DSP like the SHARC. Yay DSPs! >> >> Performance is actually a black and white requirement. "More" is not >> better, only "enough". The various flavors of the ARM processors have >> many advantages over many DSPs which make them the preferred solution in >> many products. Interesting that they benchmarked the chosen processors >> in floating point except for the Blackfins which used fixed point. Also >> interesting that the Blackfin 5xx did not really excel against any of >> the ARMs and the ARM A15 was the clear winner based on speed alone >> running up to 3 times faster than the SHARC. >> >> I haven't been keeping up with the Cortex R series lately. I assume >> they have not been getting the benefit of DSP type instructions? The >> only company I know making them is TI where they seem to be targeted to >> automotive and high-rel apps. Looks like ARM lines will be narrowing to >> the M and the A. > >The new hot-off-the-fab Xilinx Zynq devices have a pair of Cortex R5 on >die (in addition to four A53 cores, a bunch of other hard IP and a big >whack of Ultrascale+ FPGA fabric). > >Regards, >AllanYeah, that's a very interesting part. Google "Zynq snickerdoodle".
Reply by ●April 13, 20162016-04-13
On 4/13/2016 12:24 PM, Tim Wescott wrote:> On Wed, 13 Apr 2016 10:58:33 -0400, rickman wrote: > >> On 4/13/2016 6:35 AM, Allan Herriman wrote: >>> On Tue, 12 Apr 2016 13:36:44 -0400, rickman wrote: >>>> >>>> Performance is actually a black and white requirement. "More" is not >>>> better, only "enough". The various flavors of the ARM processors have >>>> many advantages over many DSPs which make them the preferred solution >>>> in many products. Interesting that they benchmarked the chosen >>>> processors in floating point except for the Blackfins which used fixed >>>> point. Also interesting that the Blackfin 5xx did not really excel >>>> against any of the ARMs and the ARM A15 was the clear winner based on >>>> speed alone running up to 3 times faster than the SHARC. >>>> >>>> I haven't been keeping up with the Cortex R series lately. I assume >>>> they have not been getting the benefit of DSP type instructions? The >>>> only company I know making them is TI where they seem to be targeted >>>> to automotive and high-rel apps. Looks like ARM lines will be >>>> narrowing to the M and the A. >>> >>> The new hot-off-the-fab Xilinx Zynq devices have a pair of Cortex R5 on >>> die (in addition to four A53 cores, a bunch of other hard IP and a big >>> whack of Ultrascale+ FPGA fabric). >> >> Do they give any indication of how the R5 are intended to be used? Is >> this chip targeted to high safety/reliability designs? > > IIRC the Cortex-R is intended for high reliability applications. > > I'm only passingly familiar with it -- it's passed across my bench in a > couple of short-lived down-hole projects that never really got off the > ground.Yes, the TI version of the CPU is certainly intended for high rel tasks. But it is not as clear that the Cortex R CPU is intended for that itself. I don't have the link handy, but I saw an ARM document which showed the various functional blocks in the ARM R processors and none of them were reliability related except for the ECC/Parity on internal (and external?) memory. The rest of the chip functions were just speed enhancement unless I missed something. Looking for that link just now I found Spansion also sells R4/R5 processors. I see one of those lines includes the "Secure Hardware Extension... for network security". Is that an ARM R series feature? "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. -- Rick
Reply by ●April 13, 20162016-04-13
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: >> >> >> > ... >> >> > if your DSP is doing coefficient calculation, it might be easier with >> > float than fixed. >> >> Why not utilize the best of both worlds? > > well, i sorta thought that was *my* point.I don't follow you here. Seems like it's just the floating-point world you're stressing here.>> 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. > > how 'bout fast convolutions with an FFT? rather do *that* in fixed?For now I am assuming using direct convolution, not frequency domain filtering.>> I.e., somewhere along the way, convert your resulting coefficients to fixed-point. >> > > well, in the same foreground (or whatever low rate) process when you > calculate your coefficients using floating-point math, division, and > calls to functions like cos(), whatever process does that can also > scale and convert to fixed-point format. (and, really to do things > right, you have to ping-pong the new coefficients, so you're always > writing them into the "inactive" ping-pong buffer. that way none of > the asychronicity matters a twit.) converting to fixed is just part of > the coefficient update thingie. > >> > 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? > > so the range of the fixed-point numbers are from -8.000000 to > +7.999999 . the accumulator has an extra 28 bits on the right and i > think 16 extra bits on the left, i think. there's no loss of > information until the wide word is written back out and it deals with > rounding and saturation about the same as a 56K (i.e. the logical way, > i think Bob had really good judgement on that).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.>> > 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).>> > 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? Are you talking about bit growth during the multiply-accumulate? Or are you talking about dynamic range?> [...] >> > 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. -- Randy Yates, DSP/Embedded Firmware Developer Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●April 13, 20162016-04-13
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! -- Rick
