public inbox for elix@sourceware.org
 help / color / mirror / Atom feed
From: Nick Garnett <nickg@cygnus.co.uk>
To: Jwusheng Hu <jshu@cn.nctu.edu.tw>
Cc: Julian Rose <jhrose@dial.pipex.com>,
	"elix@sources.redhat.com" <elix@sources.redhat.com>
Subject: Re: ¦^ÂÐ : subset of EL/IX for DSPs
Date: Tue, 15 Aug 2000 03:22:00 -0000	[thread overview]
Message-ID: <pon1ieu8ng.fsf@balti.cygnus.co.uk> (raw)
In-Reply-To: <01C006DF.D5A26FC0@pc14735.cn.nctu.edu.tw>

Jwusheng Hu <jshu@cn.nctu.edu.tw> writes:

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

I agree with all of this. The main contribution that EL/IX can make to
these issues is to provide a uniform programming environment for both
the DSP processor and the control processor. This means that the
programmers do not have to master two sets of APIs and have the option
of moving code back and forth across the divide.

The issue of making a single RTOS that provides a seamless environment
across several processors is probably not something the EL/IX should
address beyond ensuring that the APIs allow it (but with my eCos hat
on, it is somthing that is of interest).

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

      reply	other threads:[~2000-08-15  3:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-15  2:37 ¦^ÂÐ " Jwusheng Hu
2000-08-15  3:22 ` Nick Garnett [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pon1ieu8ng.fsf@balti.cygnus.co.uk \
    --to=nickg@cygnus.co.uk \
    --cc=elix@sources.redhat.com \
    --cc=jhrose@dial.pipex.com \
    --cc=jshu@cn.nctu.edu.tw \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).