subset of EL/IX for DSPs

subset of EL/IX for DSPs

[Julian Rose]

Hello,

Could anyone point me to info regarding a subset of EL/IX
or POSIX that targets DSPs? Or if anyone else is thinking
about this then their suggestions would be welcome. The
context of the question is the kernel I'm developing, please
see " http://www.jhrose.dial.pipex.com/dsp_K.htm ". Thanks.

cheers
julian

Re: subset of EL/IX for DSPs

[Joel Sherrill]

Julian Rose wrote:
> 
> Hello,
> 
> Could anyone point me to info regarding a subset of EL/IX
> or POSIX that targets DSPs? Or if anyone else is thinking
> about this then their suggestions would be welcome. The
> context of the question is the kernel I'm developing, please
> see " http://www.jhrose.dial.pipex.com/dsp_K.htm ". Thanks.

RTEMS supports about 85% of POSIX 1003.1b and includes a port
of the FreeBSD TCP/IP stack.  That pretty closely matches 
EL/IX.  RTEMS has been ported to the TI C3x/4x and 62xx series
and there is a port underway to the Lucent 16000 DSPs.  

I would think that if the goal is to have functionality
in a timely manner, you would be better off porting RTEMS
to the desired architectures.  Given the code base you
have, this should not be difficult.  

Feel free to ask me questions about RTEMS. :)

> cheers
> julian

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

Re: subset of EL/IX for DSPs

[Nick Garnett]

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

> Hello,
> 
> Could anyone point me to info regarding a subset of EL/IX
> or POSIX that targets DSPs? Or if anyone else is thinking
> about this then their suggestions would be welcome. The
> context of the question is the kernel I'm developing, please
> see " http://www.jhrose.dial.pipex.com/dsp_K.htm ". Thanks.
> 

Nobody has put any real thought into the requirements of DSPs yet.
Embedded and real-time systems have proven to be difficult enough to
pin down. I suspect that DSPs would require a subset of the RT subset
of EL/IX, perhaps with special schedulers and variations of some
communications primitives. Whether we need to provide a specific DSP
subset, or whether this would just be a version of the real-time
subset I don't really know yet.

Suggestions and comments about what would be good for DSPs are very
welcome. This would at least help to ensure that the next version of
EL/IX is not actively DSP-hostile.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: subset of EL/IX for DSPs

[Joel Sherrill]

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

Re: subset of EL/IX for DSPs

[Julian Rose]

Hello,

Further to the recent posting on EL/IX for DSPs, I have prepared
a profile statement as attached. If people have problems reading it,
please visit " http://www.jhrose.dial.pipex.com/dsp_Kelx.htm ".
The aim is to ask people what they think more than to speak with
authority :-)

cheers
julian