Digital signal controllers

Tim Wescott wrote:


> Try to write optimized assembly code for the ADSP-21xx series, and you'll
> understand.  It has a dozen registers that span four or five sets of
> special features, but each register has it's own unique combination of
> special features that it supports.  So you'll be coding along and find
> that the register you thought was a fine scratch-pad is suddenly
> absolutely necessary for a quick barrel-shift -- this will require you to
> step back ten or twenty lines in your assembly code and choose a
> _different_ register to use for that scratch pad, hoping all the while
> that _it_ won't be needed down the road.


(Grim smile). Try to write a code for PIC, x51 or SH11. BTW those are 
supposed to be "general purpose" processors. I felt a great relief when 
I switched to 21xx. What bothered me with 21xx was the lack of the 
normal stack organization. Also, I still don't know of whether it is 
possible to switch a context for 21xx.

> You can write screaming-fast assembly code for the '21xx, but you can't
> write it screamingly fast.

The assembly coding is slow while you are developing the subroutines. 
Once the library of subroutines is there, the rest of the coding is as 
fast as in any other language.


> Contrast that with the TI 320F2812, which is what we used next.  It's
> register set is mostly orthogonal -- the only special purpose registers
> are the extended accumulator, so it's _much_ easier to write assembly for
> (or to optimize compilation).

I developed the 32 bit biquad for TMS28xx in assembly cursing the stupid 
structure of the darn thing. The architecture and the instruction set 
are the sheer nonsense.  Just one example: there are two different 
instuctions: one gets the 32 MSBs of 32x32 product, the other gets 32 
LSBs of 32x32 product.


>  I suspect the Blackfin is in the same class
> with the '2812, unlike the '21xx.

Blackfin core is neat but the whole architecture looks like they had a 
lot of good ideas but they run out of time and budget. There are the 
rudiments of MMU, etc. and all of that looks unfinished. The number of 
bugs in the Blackfin silicon is tremendous; I can say proudly that I 
have reported of two not previously known. Blackfin set of peripherals 
is not any close to that of TMS28xx.



Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

joggingsong@gmail.com wrote:


>>>What is the  the ease-of-use attributes in
>>>general-purpose microcontrollers?
>>
>>What they meant are the standard stack frames and the base index
>>addressing. The early DSPs didn't have that so the C code was a nightmare.
> 
> Vladimir, could you tell me about standard stack frames? I have seen
> it ever but haven't a deep understanding.

http://en.wikipedia.org/wiki/Call_stack


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Tue, 16 Oct 2007 10:10:36 -0500, Vladimir Vassilevsky wrote:

> Tim Wescott wrote:
> 
> 
>> Try to write optimized assembly code for the ADSP-21xx series, and you'll
>> understand.  It has a dozen registers that span four or five sets of
>> special features, but each register has it's own unique combination of
>> special features that it supports.  So you'll be coding along and find
>> that the register you thought was a fine scratch-pad is suddenly
>> absolutely necessary for a quick barrel-shift -- this will require you to
>> step back ten or twenty lines in your assembly code and choose a
>> _different_ register to use for that scratch pad, hoping all the while
>> that _it_ won't be needed down the road.
> 
> 
> (Grim smile). Try to write a code for PIC, x51 or SH11. BTW those are 
> supposed to be "general purpose" processors. I felt a great relief when 
> I switched to 21xx. What bothered me with 21xx was the lack of the 
> normal stack organization. Also, I still don't know of whether it is 
> possible to switch a context for 21xx.

When we looked at it we found that there are some distressingly shallow
hardware stacks for some of the special-purpose registers (most notably
the state of the zero-overhead hardware loops) that are not accessible
from the user code in any way.  When you interrupt, they get pushed, when
you return from interrupt they get popped.  When you nest interrupts, they
overflow.  When you try to winkle out the value so you can do a complete
context switch -- you're out of luck.

We didn't use an RTOS on that product...

> 
>> You can write screaming-fast assembly code for the '21xx, but you can't
>> write it screamingly fast.
> 
> The assembly coding is slow while you are developing the subroutines. 
> Once the library of subroutines is there, the rest of the coding is as 
> fast as in any other language.

True, and they do go fast once you're done.

But writing the math processing code -- oy!  And that stupid "easy to use
algebraic syntax" is just an irritant.
> 
>> Contrast that with the TI 320F2812, which is what we used next.  It's
>> register set is mostly orthogonal -- the only special purpose registers
>> are the extended accumulator, so it's _much_ easier to write assembly
>> for (or to optimize compilation).
> 
> I developed the 32 bit biquad for TMS28xx in assembly cursing the stupid
> structure of the darn thing. The architecture and the instruction set
> are the sheer nonsense.  Just one example: there are two different
> instuctions: one gets the 32 MSBs of 32x32 product, the other gets 32
> LSBs of 32x32 product.

Any time I start writing assembly for any new processor I start dreaming
about the instruction set _I'd_ use if I were designing a processor.  It
keeps me from throwing things around the office, mostly.

>>  I suspect the Blackfin is in the same class
>> with the '2812, unlike the '21xx.
> 
> Blackfin core is neat but the whole architecture looks like they had a
> lot of good ideas but they run out of time and budget. There are the
> rudiments of MMU, etc. and all of that looks unfinished. The number of
> bugs in the Blackfin silicon is tremendous; I can say proudly that I
> have reported of two not previously known. Blackfin set of peripherals
> is not any close to that of TMS28xx.
> 
> 
> 
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultant http://www.abvolt.com



-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:
> Try to write optimized assembly code for the ADSP-21xx series, and you'll
> understand.  It has a dozen registers that span four or five sets of
> special features, but each register has it's own unique combination of
> special features that it supports.  So you'll be coding along and find
> that the register you thought was a fine scratch-pad is suddenly
> absolutely necessary for a quick barrel-shift -- this will require you to
> step back ten or twenty lines in your assembly code and choose a
> _different_ register to use for that scratch pad, hoping all the while
> that _it_ won't be needed down the road.
> 
> You can write screaming-fast assembly code for the '21xx, but you can't
> write it screamingly fast.
> 
> Contrast that with the TI 320F2812, which is what we used next.  It's
> register set is mostly orthogonal -- the only special purpose registers
> are the extended accumulator, so it's _much_ easier to write assembly for
> (or to optimize compilation).  I suspect the Blackfin is in the same class
> with the '2812, unlike the '21xx.
> 

The real problem with most of the early DSP instruction sets was the 
lack of proper supporting materials. For example, most of them provided 
a very specific way to make LMS run at high speed, with a couple of 
special instructions. However, it was beneath their dignity to provide 
thorough example code to help you figure out quickly how to make full 
use of the features provided. Each sucker using the chip had to spend a 
day or two figuring it out for themselves.


Regards,
Steve

Tim Wescott wrote:


>>>Try to write optimized assembly code for the ADSP-21xx series, and you'll
>>>understand.

>>What bothered me with 21xx was the lack of the 
>>normal stack organization. Also, I still don't know of whether it is 
>>possible to switch a context for 21xx.
> 
> 
> When we looked at it we found that there are some distressingly shallow
> hardware stacks for some of the special-purpose registers (most notably
> the state of the zero-overhead hardware loops) that are not accessible
> from the user code in any way.   When you interrupt, they get pushed, when
> you return from interrupt they get popped.  When you nest interrupts, they
> overflow.  When you try to winkle out the value so you can do a complete
> context switch -- you're out of luck.

Actually there seem to be tricky ways to switch the context on 21xx, 
like using the self modifying code and such. I don't know for sure if 
there are any legitimate methods and if this is possible or not. However 
it doesn't matter in our days.


> We didn't use an RTOS on that product...

When doing a DSP work, it is often handy to have a system of two tasks + 
interrupt. The interrupt fills a buffer with a data. Once the buffer is 
full, the processing task is activated. When the processing is done, the 
control is returned to the main task. This is much simpler then the full 
blown RTOS.


> 
>>>You can write screaming-fast assembly code for the '21xx, but you can't
>>>write it screamingly fast.
>>
>>The assembly coding is slow while you are developing the subroutines. 
>>Once the library of subroutines is there, the rest of the coding is as 
>>fast as in any other language.
> 
> 
> True, and they do go fast once you're done.
> 
> But writing the math processing code -- oy!  And that stupid "easy to use
> algebraic syntax" is just an irritant.

The algebraic syntax would be convenient for the orthogonal processor, 
but not for the mess like 21xx.

> Any time I start writing assembly for any new processor I start dreaming
> about the instruction set _I'd_ use if I were designing a processor.  It
> keeps me from throwing things around the office, mostly.

 From the CPUs that I know, the 6812 core seems to be the most simple 
and logical (but only untill you can fit into 64k!). BlackFin, SHARC, 
AVR and Z80 are not too bad.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Oct 17, 3:50 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> Tim Wescott wrote:
> >>>Try to write optimized assembly code for the ADSP-21xx series, and you'll
> >>>understand.
> >>What bothered me with 21xx was the lack of the
> >>normal stack organization. Also, I still don't know of whether it is
> >>possible to switch a context for 21xx.
>
> > When we looked at it we found that there are some distressingly shallow
> > hardware stacks for some of the special-purpose registers (most notably
> > the state of the zero-overhead hardware loops) that are not accessible
> > from the user code in any way.   When you interrupt, they get pushed, when
> > you return from interrupt they get popped.  When you nest interrupts, they
> > overflow.  When you try to winkle out the value so you can do a complete
> > context switch -- you're out of luck.
>
> Actually there seem to be tricky ways to switch the context on 21xx,
> like using the self modifying code and such. I don't know for sure if
> there are any legitimate methods and if this is possible or not. However
> it doesn't matter in our days.
>
> > We didn't use an RTOS on that product...
>
> When doing a DSP work, it is often handy to have a system of two tasks +
> interrupt. The interrupt fills a buffer with a data. Once the buffer is
> full, the processing task is activated. When the processing is done, the
> control is returned to the main task. This is much simpler then the full
> blown RTOS.
>
>
      From what you said, it seems that for early DSPs it is hard to
program in C and sometimes
context switch is not easy to implement. But nowadays most code of DSP
is written in C, and sometimes
you have to write code in intrinsics or assembly code. Many DSPs have
MMU. So DSPs can do more control
task than ever.

Jogging
>
> >>>You can write screaming-fast assembly code for the '21xx, but you can't
> >>>write it screamingly fast.
>
> >>The assembly coding is slow while you are developing the subroutines.
> >>Once the library of subroutines is there, the rest of the coding is as
> >>fast as in any other language.
>
> > True, and they do go fast once you're done.
>
> > But writing the math processing code -- oy!  And that stupid "easy to use
> > algebraic syntax" is just an irritant.
>
> The algebraic syntax would be convenient for the orthogonal processor,
> but not for the mess like 21xx.
>
> > Any time I start writing assembly for any new processor I start dreaming
> > about the instruction set _I'd_ use if I were designing a processor.  It
> > keeps me from throwing things around the office, mostly.
>
>  From the CPUs that I know, the 6812 core seems to be the most simple
> and logical (but only untill you can fit into 64k!). BlackFin, SHARC,
> AVR and Z80 are not too bad.
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

On Oct 17, 3:50 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> Tim Wescott wrote:
> >>>Try to write optimized assembly code for the ADSP-21xx series, and you'll
> >>>understand.
> >>What bothered me with 21xx was the lack of the
> >>normal stack organization. Also, I still don't know of whether it is
> >>possible to switch a context for 21xx.
>
> > When we looked at it we found that there are some distressingly shallow
> > hardware stacks for some of the special-purpose registers (most notably
> > the state of the zero-overhead hardware loops) that are not accessible
> > from the user code in any way.   When you interrupt, they get pushed, when
> > you return from interrupt they get popped.  When you nest interrupts, they
> > overflow.  When you try to winkle out the value so you can do a complete
> > context switch -- you're out of luck.
>
> Actually there seem to be tricky ways to switch the context on 21xx,
> like using the self modifying code and such. I don't know for sure if
> there are any legitimate methods and if this is possible or not. However
> it doesn't matter in our days.
>
> > We didn't use an RTOS on that product...
>
> When doing a DSP work, it is often handy to have a system of two tasks +
> interrupt. The interrupt fills a buffer with a data. Once the buffer is
> full, the processing task is activated. When the processing is done, the
> control is returned to the main task. This is much simpler then the full
> blown RTOS.
>
>
>
> >>>You can write screaming-fast assembly code for the '21xx, but you can't
> >>>write it screamingly fast.
>
> >>The assembly coding is slow while you are developing the subroutines.
> >>Once the library of subroutines is there, the rest of the coding is as
> >>fast as in any other language.
>
> > True, and they do go fast once you're done.
>
> > But writing the math processing code -- oy!  And that stupid "easy to use
> > algebraic syntax" is just an irritant.
>
> The algebraic syntax would be convenient for the orthogonal processor,
> but not for the mess like 21xx.
>
> > Any time I start writing assembly for any new processor I start dreaming
> > about the instruction set _I'd_ use if I were designing a processor.  It
> > keeps me from throwing things around the office, mostly.
>
>  From the CPUs that I know, the 6812 core seems to be the most simple
> and logical (but only untill you can fit into 64k!). BlackFin, SHARC,
> AVR and Z80 are not too bad.
   Here is a good passage about DSP/RISC Convergence.
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=164904425
Every time I saw that RISC is control-oriented, I began to find the
architectural features in DSPs, that defeats DSPs in control
applications
contrast with RISC. But I always fail to do that
Jogging
>
> Vladimir Vassilevsky
> DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

joggingsong@gmail.com wrote:

>    Here is a good passage about DSP/RISC Convergence.
> http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=164904425

Marketing spew.

> Every time I saw that RISC is control-oriented, I began to find the
> architectural features in DSPs, that defeats DSPs in control
> applications contrast with RISC.

Bla-bla-bla, how many buzzwords.
All that matters is the bang for the bucks.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Oct 14, 10:52 pm, joggings...@gmail.com wrote:
> Hi,all
>
> Today I see the following over the Internet.
> "Digital signal controllers (DSCs) are a new class of processor that
> combines the best attributes of MCUs and DSPs.
>
> Like MCUs, DSCs have fast interrupt responses, offer control-oriented
> peripherals such as pulse-width modulators and watchdog timers, and
> are programmed in C. They also incorporate DSP features such as single-
> cycle multiply-accumulate (MAC) units, barrel shifters and large
> accumulators. "
>
> I don't understand the fast interrupt response is the attribute of
> MCUs, not of DSPs. Do some architectural feature
> prevent DSPs from fast interrupt response.

Way back, many turns of Moore's law ago, chips had many
fewer transistors, and so were designed and optimized for
a smaller set of targeted application areas.  This led to
a wider segmentation of chip types.  Things called DSP
chips were very different from chips for supercomputers
were very different from chips for cash registers.  Today,
with zillions of transistors available for pennys, chip
vendors can almost throw in the kitchen sink, covering
multiple application types in the architecture of their
newer chip families.

So today you can run a Unix-like OS on chips marketed
towards embedded DSP, real-time audio processing on
chips originally architected for running Basic programs
on home PCs, and your grocer's cash register might well
be capable of far more MFlops than early supercomputers.



IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M

On Oct 18, 4:24 am, "Ron N." <rhnlo...@yahoo.com> wrote:
> On Oct 14, 10:52 pm, joggings...@gmail.com wrote:
>
> > Hi,all
>
> > Today I see the following over the Internet.
> > "Digital signal controllers (DSCs) are a new class of processor that
> > combines the best attributes of MCUs and DSPs.
>
> > Like MCUs, DSCs have fast interrupt responses, offer control-oriented
> > peripherals such as pulse-width modulators and watchdog timers, and
> > are programmed in C. They also incorporate DSP features such as single-
> > cycle multiply-accumulate (MAC) units, barrel shifters and large
> > accumulators. "
>
> > I don't understand the fast interrupt response is the attribute of
> > MCUs, not of DSPs. Do some architectural feature
> > prevent DSPs from fast interrupt response.
>
> Way back, many turns of Moore's law ago, chips had many
> fewer transistors, and so were designed and optimized for
> a smaller set of targeted application areas.  This led to
> a wider segmentation of chip types.  Things called DSP
> chips were very different from chips for supercomputers
> were very different from chips for cash registers.  Today,
> with zillions of transistors available for pennys, chip
> vendors can almost throw in the kitchen sink, covering
> multiple application types in the architecture of their
> newer chip families.
>
> So today you can run a Unix-like OS on chips marketed
> towards embedded DSP, real-time audio processing on
> chips originally architected for running Basic programs
> on home PCs, and your grocer's cash register might well
> be capable of far more MFlops than early supercomputers.
    Thanks. It makes me clear.More transistors can be put on the
chip. Nowadays DSPs can do the job of CPUs, and most DSPs have
OS running on it.So It is the cost which makes DSPs and CPUs two
different kinds of processor.
Jogging
>
> IMHO. YMMV.
> --
> rhn A.T nicholson d.0.t C-o-M