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

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 pm, rickman <gnu...@gmail.com> 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.

with the same hardware limitations?  or do you mean the 5.23 bit word?

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

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

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.

>  Do 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 pm, robert bristow-johnson <r...@audioimagination.com>
wrote:
> On Oct 24, 2:09 pm, rickman <gnu...@gmail.com> wrote:
>
> > 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?

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?


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


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

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.  but they
> qualify as DSPs, even if their tools don't let you do anything.
>
> >  Do 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 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?

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 am, rickman <gnu...@gmail.com> 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.
>
> 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

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 am, emeb <ebromba...@gmail.com> wrote:
> On Oct 24, 10:11 am, rickman <gnu...@gmail.com> 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.
>
> > 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
>
> 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