sigmaDSP and similar devices

Started by rickman October 24, 2010
I have been watching the sigmaDSP from ADI and the similar part from
TI.  These parts seem ideal for a lot of applications but the problem
I have is with the tools.  They don't let you write your own code.
You can only string together modules from their library.  They are
mostly filters and similar functions and I don't see how to do a lot
of very basic stuff that any other processor can do.

I've contacted both TI and ADI support and they both say their tools
still don't support user written code and I don't see where that is
much of an issue with them.  Is this  because the parts are hard to
program or because the parts are limited and they would be hard to use
to implement control functions for example.

I wrote about this a couple of years ago and someone said I was
mistaken and they did support assembly language programming by the
user.  Anyone know anything about that?  Am I asking support the wrong
questions?

Rick

rickman wrote:
> I have been watching the sigmaDSP from ADI and the similar part from > TI. These parts seem ideal for a lot of applications but the problem > I have is with the tools. They don't let you write your own code. > You can only string together modules from their library. They are > mostly filters and similar functions and I don't see how to do a lot > of very basic stuff that any other processor can do.
DAPs are not the general purpose processors; there is a very limited set of things that DAPs can do. All of the processing has to be done in the period of the one clock of the sample rate; there is no conditional branching; etc. etc. If you want some functionality that is not in the library, then DAP is not the right part for you. Use a general purpose DSP.
> I've contacted both TI and ADI support and they both say their tools > still don't support user written code and I don't see where that is > much of an issue with them.
IIRC the AKM did allow you to program their DAPs at low level. The programing of those was a misery.
> Is this because the parts are hard to > program or because the parts are limited and they would be hard to use > to implement control functions for example. > > I wrote about this a couple of years ago and someone said I was > mistaken and they did support assembly language programming by the > user. Anyone know anything about that? Am I asking support the wrong > questions?
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
On Oct 24, 1:32=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote:
> rickman wrote: > > I have been watching the sigmaDSP from ADI and the similar part from > > TI. =A0These parts seem ideal for a lot of applications but the problem > > I have is with the tools. =A0They don't let you write your own code. > > You can only string together modules from their library. =A0They are > > mostly filters and similar functions and I don't see how to do a lot > > of very basic stuff that any other processor can do. > > DAPs are not the general purpose processors; there is a very limited set > of things that DAPs can do. All of the processing has to be done in the > period of the one clock of the sample rate; there is no conditional > branching; etc. etc. =A0If you want some functionality that is not in the > library, then DAP is not the right part for you. Use a general purpose DS=
P. There are no general purpose DSPs with the same hardware characteristics of these parts. If there is no way to implement conditional branching, then this is indeed a very limited family of parts. Still, I would like to try to implement my algorithms on the parts. The time limitation is not really a limitation at all that I can see. Don't you have that constraint on all MCU/DSPs? If you haven't finished processing one sample before the next comes in, it will fail, no? Are these parts not really DSPs, but just programmable filters? Do they have a stored program that is executed sequentially?
> > I've contacted both TI and ADI support and they both say their tools > > still don't support user written code and I don't see where that is > > much of an issue with them. > > IIRC the AKM did allow you to program their DAPs at low level. The > programing of those was a misery.
I looked at the AMK parts and most are "not recommended for new designs". The few remaining are not great candidates for my sockets. If no one makes a DSP with embedded stereo CODEC, they should make one. Rick Rick

rickman wrote:

> On Oct 24, 1:32 pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote: > >>rickman wrote: >> >>>I have been watching the sigmaDSP from ADI and the similar part from >>>TI. These parts seem ideal for a lot of applications but the problem >>>I have is with the tools. They don't let you write your own code. >>>You can only string together modules from their library. They are >>>mostly filters and similar functions and I don't see how to do a lot >>>of very basic stuff that any other processor can do. >> >>DAPs are not the general purpose processors; there is a very limited set >>of things that DAPs can do. All of the processing has to be done in the >>period of the one clock of the sample rate; there is no conditional >>branching; etc. etc. If you want some functionality that is not in the >>library, then DAP is not the right part for you. Use a general purpose DSP. > > > There are no general purpose DSPs with the same hardware > characteristics of these parts. If there is no way to implement > conditional branching, then this is indeed a very limited family of > parts. Still, I would like to try to implement my algorithms on the > parts. The time limitation is not really a limitation at all that I > can see. Don't you have that constraint on all MCU/DSPs? If you > haven't finished processing one sample before the next comes in, it > will fail, no?
It is usually a lot more efficient to process data buffer by buffer then sample by sample.
> Are these parts not really DSPs, but just programmable filters? Do > they have a stored program that is executed sequentially?
I'd call them a micro programmable automata for implementing digital filters.
> >>>I've contacted both TI and ADI support and they both say their tools >>>still don't support user written code and I don't see where that is >>>much of an issue with them. >> >>IIRC the AKM did allow you to program their DAPs at low level. The >>programing of those was a misery. > > > I looked at the AMK parts and most are "not recommended for new > designs". The few remaining are not great candidates for my > sockets. > > If no one makes a DSP with embedded stereo CODEC, they should make > one.
There is BlackFin DSP with built-in stereo codec; but it is way over reasonable price. The AVR32 has integrated digital part of the delta-sigma DAC. BTW, there shouldn't be any problems with implementation of the digital part of delta sigma DACs and ADCs on the same silicon with the DSP core. The analog part could be built with few discrete components. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
On Oct 24, 2:09=A0pm, rickman <gnu...@gmail.com> wrote:
> On Oct 24, 1:32=A0pm, Vladimir Vassilevsky <nos...@nowhere.com> wrote: > > > rickman wrote: > > > I have been watching the sigmaDSP from ADI and the similar part from > > > TI. =A0These parts seem ideal for a lot of applications but the probl=
em
> > > I have is with the tools. =A0They don't let you write your own code. > > > You can only string together modules from their library. =A0They are > > > mostly filters and similar functions and I don't see how to do a lot > > > of very basic stuff that any other processor can do. > > > DAPs are not the general purpose processors; there is a very limited se=
t
> > of things that DAPs can do. All of the processing has to be done in the > > period of the one clock of the sample rate; there is no conditional > > branching; etc. etc. =A0If you want some functionality that is not in t=
he
> > library, then DAP is not the right part for you. Use a general purpose =
DSP.
> > There are no general purpose DSPs with the same hardware > characteristics of these parts.
with the same hardware limitations? or do you mean the 5.23 bit word?
> =A0If there is no way to implement > conditional branching, then this is indeed a very limited family of > parts.
i'm pretty sure that such is the case for the sigmaDSP (although i seem to remember Bob Adams telling me that such might change).
> =A0Still, I would like to try to implement my algorithms on the > parts. =A0The time limitation is not really a limitation at all that I > can see. =A0Don't you have that constraint on all MCU/DSPs? =A0If you > haven't finished processing one sample before the next comes in, it > will fail, no? >
different time limitations. and, if you have conditional branching, you can apply different "sampling rates" to different internal signal or parameters and split the computational burden up among many samples. you can't do that with a sigmaDSP.
> Are these parts not really DSPs, but just programmable filters?
i dunno if they cut it as a "Turing Complete" machine. but they qualify as DSPs, even if their tools don't let you do anything.
> =A0Do they have a stored program that is executed sequentially?
i think so.
> > > I've contacted both TI and ADI support and they both say their tools > > > still don't support user written code and I don't see where that is > > > much of an issue with them.
hey Bob (Adams), is this the case? you can't write your own code for the sigma? r b-j
On 10/24/2010 11:09 AM, rickman wrote:
> On Oct 24, 1:32 pm, Vladimir Vassilevsky<nos...@nowhere.com> wrote: >> rickman wrote: >>> I have been watching the sigmaDSP from ADI and the similar part from >>> TI. These parts seem ideal for a lot of applications but the problem >>> I have is with the tools. They don't let you write your own code. >>> You can only string together modules from their library. They are >>> mostly filters and similar functions and I don't see how to do a lot >>> of very basic stuff that any other processor can do. >> >> DAPs are not the general purpose processors; there is a very limited set >> of things that DAPs can do. All of the processing has to be done in the >> period of the one clock of the sample rate; there is no conditional >> branching; etc. etc. If you want some functionality that is not in the >> library, then DAP is not the right part for you. Use a general purpose DSP. > > There are no general purpose DSPs with the same hardware > characteristics of these parts. If there is no way to implement > conditional branching, then this is indeed a very limited family of > parts. Still, I would like to try to implement my algorithms on the > parts. The time limitation is not really a limitation at all that I > can see. Don't you have that constraint on all MCU/DSPs? If you > haven't finished processing one sample before the next comes in, it > will fail, no? > > Are these parts not really DSPs, but just programmable filters? Do > they have a stored program that is executed sequentially? > > >>> I've contacted both TI and ADI support and they both say their tools >>> still don't support user written code and I don't see where that is >>> much of an issue with them. >> >> IIRC the AKM did allow you to program their DAPs at low level. The >> programing of those was a misery. > > I looked at the AMK parts and most are "not recommended for new > designs". The few remaining are not great candidates for my > sockets. > > If no one makes a DSP with embedded stereo CODEC, they should make > one.
My most common architecture for control loops on DSPs is -> Collect data (in hardware or ISR) -> Process a vector of data and decimate -> Run one iteration of the control loop and output Meanwhile, the thing is available to talk to the user or other parts of a larger system, or it's closing more than one loop at more than one rate, etc. So there's always virtually more than one thing going on, and in reality there's context switches and all that fun RTOS stuff (whether or not there's really an RTOS in there). Anything that can only do a per-sample process would be useful only as a smart ADC. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
On Oct 24, 2:31=A0pm, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Oct 24, 2:09=A0pm, rickman <gnu...@gmail.com> wrote: > > > There are no general purpose DSPs with the same hardware > > characteristics of these parts. > > with the same hardware limitations? =A0or do you mean the 5.23 bit word?
I mean the good stuff; built in 16 bit CODEC, very low power (~50 mW II believe), small package size (5 mm sq). I like the part a lot. But I'm not sure it be used for what I want to do. Are there any regular DSPs that fit this bill?
> > =A0If there is no way to implement > > conditional branching, then this is indeed a very limited family of > > parts. > > i'm pretty sure that such is the case for the sigmaDSP (although i > seem to remember Bob Adams telling me that such might change).
Well, ok. If that is how the chips is intended...
> > =A0Still, I would like to try to implement my algorithms on the > > parts. =A0The time limitation is not really a limitation at all that I > > can see. =A0Don't you have that constraint on all MCU/DSPs? =A0If you > > haven't finished processing one sample before the next comes in, it > > will fail, no? > > different time limitations. =A0and, if you have conditional branching, > you can apply different "sampling rates" to different internal signal > or parameters and split the computational burden up among many > samples. =A0you can't do that with a sigmaDSP.
The initial algorithm I want to implement requires levels of decimation as the signal is processed on the receive side and the opposite on the xmit side, digital data is PW modulated then amplitude modulated on a 1 kHz carrier. What can make his tricky is that the xmit side has to be sync'd to the receive side as this is a time code signal. In the current design the main clock to the CODEC is adjusted to keep the xmit signal sync'd to the data. I'm not sure how I would do this in the SigmaDSP. In a regular DSP if I can't adjust the main clock, I would adjust the sine wave frequency which is what I actually care about. Could that be done in the SigmaDSP?
> > Are these parts not really DSPs, but just programmable filters? > > i dunno if they cut it as a "Turing Complete" machine. =A0but they > qualify as DSPs, even if their tools don't let you do anything. > > > =A0Do they have a stored program that is executed sequentially? > > i think so.
I guess I don't see how they could not have conditional branching then.
> > > > I've contacted both TI and ADI support and they both say their tool=
s
> > > > still don't support user written code and I don't see where that is > > > > much of an issue with them. > > hey Bob (Adams), is this the case? =A0you can't write your own code for > the sigma?
Rick
On Sun, 24 Oct 2010 20:23:55 -0700, rickman wrote:

> I guess I don't see how they could not have conditional branching then.
The ones that I've seen have a single block of program memory that is entered at the "top" on the sample interrupt, and have an implicit "wait for interrupt" at the bottom. So you get a stored program and read and write data and coefficient memory. You can multiply, add and store, and from that you can build filters of various sorts. You could probably make something that looked like decisions by processing "both branches" and combining the results with a 1,0 or 0,1 mixer, but you don't get to modify the program counter (or even see it.) No loops: no need if the program memory can hold as many instructions as can be executed in one sample period. No conditional instructions and limited program memory size pretty much rule out more complicated algorithms that use multi-rate or buffered block processing. There is quite a bit that *can* be done within the model, though. For example (your example), I can't think of any particular reason why you couldn't modulate the frequency of a sinusoid carrier that you were generating. Cheers, -- Andrew
On Oct 24, 10:11=A0am, rickman <gnu...@gmail.com> wrote:
> I have been watching the sigmaDSP from ADI and the similar part from > TI. =A0These parts seem ideal for a lot of applications but the problem > I have is with the tools. =A0They don't let you write your own code. > You can only string together modules from their library. =A0They are > mostly filters and similar functions and I don't see how to do a lot > of very basic stuff that any other processor can do. > > I've contacted both TI and ADI support and they both say their tools > still don't support user written code and I don't see where that is > much of an issue with them. =A0Is this =A0because the parts are hard to > program or because the parts are limited and they would be hard to use > to implement control functions for example. > > I wrote about this a couple of years ago and someone said I was > mistaken and they did support assembly language programming by the > user. =A0Anyone know anything about that? =A0Am I asking support the wron=
g
> questions? > > Rick
Have you looked at the Spin Semiconductor FV-1? http://www.spinsemi.com/ While aimed primarily at inexpensive audio effects, it does have some of the features you've mentioned, and the development environment is free. It's an odd beast, with 24-bit precision codec and ALU, 128-step stored program, 32k of 'floating point' buffer memory and a 3 channel low-speed ADC for user input. It does have conditional execution (skip) as well, and can load programs from an external I2C EEPROM. Might be worth a look depending on what you're trying to accomplish. Eric
On Oct 25, 11:47=A0am, emeb <ebromba...@gmail.com> wrote:
> On Oct 24, 10:11=A0am, rickman <gnu...@gmail.com> wrote: > > > > > I have been watching the sigmaDSP from ADI and the similar part from > > TI. =A0These parts seem ideal for a lot of applications but the problem > > I have is with the tools. =A0They don't let you write your own code. > > You can only string together modules from their library. =A0They are > > mostly filters and similar functions and I don't see how to do a lot > > of very basic stuff that any other processor can do. > > > I've contacted both TI and ADI support and they both say their tools > > still don't support user written code and I don't see where that is > > much of an issue with them. =A0Is this =A0because the parts are hard to > > program or because the parts are limited and they would be hard to use > > to implement control functions for example. > > > I wrote about this a couple of years ago and someone said I was > > mistaken and they did support assembly language programming by the > > user. =A0Anyone know anything about that? =A0Am I asking support the wr=
ong
> > questions? > > > Rick > > Have you looked at the Spin Semiconductor FV-1? > > http://www.spinsemi.com/
hadn't heard of this chip, nor of the company.
> While aimed primarily at inexpensive audio effects, it does have some > of the features you've mentioned, and the development environment is > free. It's an odd beast, with 24-bit precision codec and ALU, 128-step > stored program, 32k of 'floating point' buffer memory and a 3 channel > low-speed ADC for user input.
i couldn't find the programmer's reference manual (or whatever they call it at Spin). the only instructions the data sheet mentions is LOG and EXP. i usually don't think it's worth much real estate on silicon to implement log() and exp() at such a low level. i have yet to use a log() or exp() at full-bandwidth audio (well, maybe for limiting/compression, i guess i *did* use it once on every sample without skipping).
> It does have conditional execution > (skip) as well, and can load programs from an external I2C EEPROM.
does it have "jump" or "branch" instructions that can be conditionally skipped over? if not, i can't see how to split up the computational burden of a complex algorithm among many samples to spread the work out. r b-j