From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Sherrill To: egcs@cygnus.com Cc: elix@sources.redhat.com Subject: Re: subset of EL/IX for DSPs Date: Tue, 15 Aug 2000 07:03:00 -0000 Message-id: <39994C7E.2A916E5B@OARcorp.com> References: <39981826.CCE898A6@dial.pipex.com> X-SW-Source: 2000-q3/msg00005.html Jwusheng Hu wrote: > > Julian Rose 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