Re: subset of EL/IX for DSPs

[Joel Sherrill <joel.sherrill@OARcorp.com>]

Jwusheng Hu wrote:
> 
> Julian Rose <jhrose@dial.pipex.com> writes:
> 

> It appears that there are two types of requirements here and they are
> related to a fundamental design question: will you design a system
> completely based on DSP? Traditionally, DSP usually acts as a slave
> processor preforming repeated calculations for time-critical algorithms.
> Because of this, DSP chips have very little support of system interface like
> ethernet, LCD etc.., compared with most microcontrollers.

Yes. IO can be quite painful on some DSPs.  I recall that TI C4x VMEbus
boards had weird interfaces to allow true 8 and 16-bit bus accesses.
 
> However, when the MIPS of DSP exceeds the needs of algorithm complexity, it
> is quite natural to use the extra MIPS for system interface and a RTOS would
> be very helpful. However, most DSP algorithms must be coded in assembly to
> fully utilize the computational capability, e.g., zero-overhead looping.

This depends a lot on the RTOS and how much control it gives over
tasking.

If the RTOS only allows for interrupt-driven, preemptive multitasking,
then this is not a good fit as it perturbs pipelines and caching in a
pretty
random manner.  This is bad when you have hand tuned an assembly
language inner loop.

On the other hand, some RTOSes (RTEMS is one) give precise control 
over preemptability and interrupt disable level on a per task basis.  
With this much control, you can avoid seemingly random preemption
in a critical task and maintain throughput in the algorithm.

> This creates a potential threat to RTOS that full control of the CPU
> resource maynot be possible and users can easily crash the kernel by
> mistake. Hence, unless DSP programmers understand the kernel well, she/he
> may have difficulty using other people's RTOS.

I don't know that "understanding the kernel" is the issue as much as 
"conforming to the calling conventions".  Well written assembly 
routines are not a problem for an RTOS.  You do not have to under
the implementation of an RTOS -- just the rules to play nicely. :)

> On the other hand, the master-slave structure is still popular when DSP
> takes on the computing role for software radio. For example, TI has a
> DSP+ARM solution that is targeted for portable wireless devices. In this
> case, the need would be how to have a single RTOS that handles both
> processors together and provides a seamless communication interface between
> them.

This certainly offers interesting application architectural
possibilities.

If the master/slave run the same RTOS, then the communications interface
between them can be managed by the RTOS and services shared.  RTEMS 
support heterogeneous multiprocessing configurations so you could
send messages, share semaphores, etc between the two CPUs at the OS
level.

Another neat alternative would be an integrated toolset that let you
specify on a routine by routine basis something like an RPC that ended
up on the slave.  If the compiler could magically generate two
executables at the same time, this would be incredibly cool.

> Jwusheng Hu, Professor
> Dept. of Electrical and Control Engineering
> Embedded System Design Lab,               http://xlab.cn.nctu.edu.tw
> Director, EECS DSP lab,
>                             http://dsp.cn.nctu.edu.tw
> Executive Consultant, DigiRose Co Ltd,  http://www.digirose.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985