Embedded Processor/Compiler Selection

Embedded Processor/Compiler Selection

[Marin David Condic, 561.796.8997, M/S 731-96]

    Embedded Processor/Compiler Selection

    We are currently in the process of trying to select both a
    processor and an Ada compiler for the next generation of engine
    control. We would like to get feedback from the Ada community on
    what is being used, pros/cons of various products, general
    comments and suggestions.

    Here is where we are at right now:

    We are trying to evaluate Ada compilers for the PowerPC, MIPS and
    Pentium processor families. We would like to know of any
    experiences with using these processors as embedded machines with
    Ada as the embedded development language. What type of embedded
    system? Which Ada compiler? How well/poorly is it working out?
    What sort of problems are you encountering?

    Since we are not at all committed to a processor at this point, we
    would like to hear about almost any recent 32 bit embedded system
    development using Ada95. (Note that we are not doing development
    using a SBC with some commercial RTOS - we build the processor
    board from the ground up and build all of the software that
    operates in it as well. So we are interested in experiences
    similar to the work we are doing and need to consider compilation
    systems aimed at this sort of bare machine.) If you have had some
    experience in selecting a processor/Ada compiler combination
    recently and wouldn't mind sharing the knowledge you have gained,
    please drop me a line.

    Thanks for any information you can send.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "Because that's where they keep the money."
        --  Willie Sutton when asked why he robbed banks.
=============================================================================

Re: Embedded Processor/Compiler Selection

[phil.brashear]

In article <98021913563192@psavax.pwfl.com>,
  "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM> wrote:
>
>     Embedded Processor/Compiler Selection
>
>     We are currently in the process of trying to select both a
>     processor and an Ada compiler for the next generation of engine
>     control.

My standard response to such postings is to remind people of the Ada Compiler
Evaluation System (ACES), a collection of performance and usability
assessment tools, including analysis tools for comparing results from
different configurations and for comparing results of related tests run on
the same configuration.  If (especially) performance is important to you, and
you have a pretty good idea of your requirements, then the ACES can be quite
useful.  It's not particularly easy to use, requiring some time investment,
but advice is available.  I'd start with the "Quick-Look" facility to cut the
number of candidates down, then use the full ACES to compare the final 2 or 3
candidates.

See "http://sw-eng.falls-church.va.us/adaic/compilers/aces" or use anonymous
FTP to sw-eng.falls-church.va.us and change directory to
"public/adaic/compiler/aces".

Good luck!

Phil Brashear
EDS Conformance Testing Center

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: Embedded Processor/Compiler Selection

[John E. Doss]

Marin David Condic, 561.796.8997, M/S 731-96 wrote:

>     We are trying to evaluate Ada compilers for the PowerPC, MIPS and
>     Pentium processor families. We would like to know of any
>     experiences with using these processors as embedded machines with
>     Ada as the embedded development language. What type of embedded
>     system? Which Ada compiler? How well/poorly is it working out?
>     What sort of problems are you encountering?
>

We have developed an embedded system using a Radstone PowerPC SBC runningvxWorks
using the Ada95 compiler from Green Hills hosted on a Sun.  Everything has
worked quite well.  The only real problem we had was getting familiar with
vxWorks
and the Green Hills compiler as this was the first time that we had used either
of
them.  Another small problem was getting help from our Green Hills rep.  We've
had
two, with the first one being very good and the second one not so good.

>     Since we are not at all committed to a processor at this point, we
>     would like to hear about almost any recent 32 bit embedded system
>     development using Ada95. (Note that we are not doing development
>     using a SBC with some commercial RTOS - we build the processor
>     board from the ground up and build all of the software that
>     operates in it as well. So we are interested in experiences
>     similar to the work we are doing and need to consider compilation
> systems aimed at this sort of bare machine.)

I've done this both ways.  The first time was with Ada 83 on a 16-bit processor
with no commercial RTOS.  The second, of course, was with the vxWorks/PowerPC
combination.  Unless I had some very tight memory constraints, I would never go
back to running without an RTOS such as vxWorks.  Development is much easier
with vxWorks.

John

--

John E. Doss                       Georgia Tech Research Institute
john.doss@gtri.gatech.edu   GTRI/ELSYS
(404) 894-7054                  Atlanta, Georgia 30332-0829

Re: Embedded Processor/Compiler Selection

[Marin David Condic, 561.796.8997, M/S 731-96]

    Embedded Processor/Compiler Selection

    Our compiler/processor search team is also looking at the
    following processors:

    Coldfire
    StrongARM
    Super H - Hitachi
    RH-32

    We are interested in hearing about any sort of embedded
    development with these processors that is similar to what we are
    constructing: An engine control with a highly specialized
    computer, having hard real time and reliability constraints.

    Naturally, we are interested in any experience (and sources for
    compilers) for programming these devices in Ada. (If this turns
    out to be the right answer, we might consider paying for a port.
    But we'd have to be convinced that this was the right long-term
    processor selection.) We would be interested in hearing about
    applications that are not programmed in Ada, provided they are
    reasonably similar to our own usage - high reliability, hard real
    time, bare silicon/ground up programming.

    If you can tell us about your usage of these processors, what you
    like/dislike about them, sources for tools, price/performance,
    whatever - we would find it a big help.

    Thanks for any information you can send.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "Because that's where they keep the money."
        --  Willie Sutton when asked why he robbed banks.
=============================================================================

Embedded Processor/Compiler Selection

[Robert C. Leif, Ph.D.]

To: Marin David Condic
Senior Computer Engineer
Pratt & Whitney

From: Bob Leif, Ph.D.
Vice President Ada_Med

My suggestion is to have one of the Ada vendors host their compiler on
Windows CE, which is hosted on multiple CPUs. CE must have a common
intermediate form. You do NOT have to use any part of the Microsoft GUI or
Windowing environment. CE was designed for embedded systems and is building
market share. This way, you will not be sponsoring a special but helping to
start a viable maintained, commercial product. Amusingly, Ada code which
uses Latin 1 will have a significant advantage in code size over the other
compilers, which use 2 byte Unicode.
----------------------------------
You wrote:
Embedded Processor/Compiler Selection

    Our compiler/processor search team is also looking at the
    following processors:

    Coldfire
    StrongARM
    Super H - Hitachi
    RH-32

    We are interested in hearing about any sort of embedded
    development with these processors that is similar to what we are
    constructing: An engine control with a highly specialized
    computer, having hard real time and reliability constraints.

    Naturally, we are interested in any experience (and sources for
    compilers) for programming these devices in Ada. (If this turns
    out to be the right answer, we might consider paying for a port.
    But we'd have to be convinced that this was the right long-term
    processor selection.) We would be interested in hearing about
    applications that are not programmed in Ada, provided they are
    reasonably similar to our own usage - high reliability, hard real
    time, bare silicon/ground up programming.

    If you can tell us about your usage of these processors, what you
    like/dislike about them, sources for tools, price/performance,
    whatever - we would find it a big help.

    Thanks for any information you can send.

    MDC

Marin David Condic.
--------------------------------------------------------------------------

Re: Embedded Processor/Compiler Selection

[Robert Dewar]

Bob Leif says

<<My suggestion is to have one of the Ada vendors host their compiler on
Windows CE, which is hosted on multiple CPUs. CE must have a common
intermediate form. You do NOT have to use any part of the Microsoft GUI or
>>


That's an odd claim, why do you think "CE *must* have a common intermediate
form"???

Re: Embedded Processor/Compiler Selection

[Marin David Condic, 561.796.8997, M/S 731-96]

>My suggestion is to have one of the Ada vendors host their compiler on
>Windows CE, which is hosted on multiple CPUs. CE must have a common
>intermediate form. You do NOT have to use any part of the Microsoft GUI or
>Windowing environment. CE was designed for embedded systems and is building
>market share. This way, you will not be sponsoring a special but helping to
>start a viable maintained, commercial product. Amusingly, Ada code which
>uses Latin 1 will have a significant advantage in code size over the other
>compilers, which use 2 byte Unicode.
>
    I'm afraid I don't know much about Windows CE except that its some
    kind of stripped down version of WindowsNT for things like PDAs
    and Gameboys. Correct?

    If this is the case, there's some credible reasons to believe that
    it is unsuitable for (at least hard) real time systems. (see:
    http://www.realtime-info.be/encyc/market/rtos/ntspecial.htm) Maybe
    Windows CE has corrected these problems?

    Even if its suitable, I'm not sure we could use it in our current
    application. Just briefly, here's a look at the system:

    The engine control is a dual-redundant computer with the two
    channels connected by a Manchester data link. Both channels have
    to synchronize their 1mSec cycles to within about 50uSec and have
    to stay in synch for data coherency and data latency reasons. (You
    like to be operating on loop closure data that isn't more than one
    cycle old, if possible.) Each channel consists of 3 general
    purpose processors and a digital signal processor, which also have
    to operate in synch with each other for the same data coherency
    and latency reasons. Each channel reads A/D converters, F/D
    converters, Discrete inputs, etc according to a schedule
    determined by which cycle number it is in. (Point the MUX, read
    the data, then execute the software that depends on that data to
    be as fresh as possible.) These deadlines are pretty serious
    deadlines because you're tracking the motion or state of physical
    hardware moving about rather rapidly. If you miss reading or
    processing the data in a timely manner, things can slam into stops
    & break, or a pressure can exceed some limit and start a stall or
    any other number of things generally considered by pilots &
    passengers to be "A Bad Thing".

    Historically, we have never encountered a commercial RTOS that
    would effectively do the job we needed done. Either it would have
    to have been heavily tailored or would run too slow or would suck
    up too much of the CPU time or all of the above. So we tend to do
    things with a relatively simple cyclic executive driven by
    interrupts. It may not be real exciting, but it works pretty well.

    Maybe Windows CE is different and I'm curious enough about it to
    do more research if you can point me at a resource. All other
    things being equal, there are obvious advantages to using a
    commercial RTOS where possible. If we can't use it to drive our
    engine control, we might very well be able to use it in other
    applications.

    Thanks for the info.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "Because that's where they keep the money."
        --  Willie Sutton when asked why he robbed banks.
=============================================================================

Re: Embedded Processor/Compiler Selection

[Marin David Condic, 561.796.8997, M/S 731-96]

phil.brashear@ACM.ORG writes:
>My standard response to such postings is to remind people of the Ada Compiler
>Evaluation System (ACES), a collection of performance and usability
>assessment tools, including analysis tools for comparing results from
>different configurations and for comparing results of related tests run on
>the same configuration.  If (especially) performance is important to you, and
>you have a pretty good idea of your requirements, then the ACES can be quite
>useful.  It's not particularly easy to use, requiring some time investment,
>but advice is available.  I'd start with the "Quick-Look" facility to cut the
>number of candidates down, then use the full ACES to compare the final 2 or 3
>candidates.
>
    We've used ACES before and the resources at the AdaIC have already
    been helpful in identifying validated compilers. However, I think
    we're more at the conceptual phase of the selection process where
    we are trying to figure out which processor is "right" because of
    market considerations, successful applications, infrastructure,
    etc. When we've more or less figured out where we'd like to head
    from that standpoint, we'll be much more interested in performance
    evaluations, etc.

    Thanks for the tip.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "Because that's where they keep the money."
        --  Willie Sutton when asked why he robbed banks.
=============================================================================

Re: Embedded Processor/Compiler Selection

[Robert Dewar]

Marin said

<<    If this is the case, there's some credible reasons to believe that
    it is unsuitable for (at least hard) real time systems. (see:
    http://www.realtime-info.be/encyc/market/rtos/ntspecial.htm) Maybe
    Windows CE has corrected these problems?
>>

No, that's a misunderstanding. Windows CE is indeed intended for hard
real time embedded applications. Look for example at the recent newsstory
on its adoption for a multi-million unit High-definition cable TV gizmo.

Actually the story is hot news, because MS is desperately trying to get
people NOT to adopt the new HDTV standard, and instead adopt the (inferior
from a TV point of view) PC standard, and these new cable boxes will not
properly accomodate HDTV, but that is not, I think beccause of any
*technical* limitation in Windows CE.

Whether CE is a reasonable Ada target from a business point of view is
quite another matter ...

Re: Embedded Processor/Compiler Selection

[Robert Dewar]

l.brashear@ACM.ORG writes:
>My standard response to such postings is to remind people of the Ada Compiler
>Evaluation System (ACES), a collection of performance and usability
>assessment tools, including analysis tools for comparing results from
>different configurations and for comparing results of related tests run on
>the same configuration.  If (especially) performance is important to you, and
>you have a pretty good idea of your requirements, then the ACES can be quite
>useful.  It's not particularly easy to use, requiring some time investment,
>but advice is available.  I'd start with the "Quick-Look" facility to cut the
>number of candidates down, then use the full ACES to compare the final 2 or 3
>candidates.


This advice from Phil, as one of the creators of ACES, is not a surprise :-)

But I have a question, has anyone successfully used the latest version of the
full ACES suite. We had a couple of customers look at using it and decide
it was far too much work. One customer used the Quick-Look facility, but
I would not base much on the results from this, since it is a rather
miscellaneous collection of tests.

Any set of canned benchmarks is always a bit dubious. I think you usually
do better to create some test cases of your own, trying to mirror your
intended application as closely as possible.

Re: Embedded Processor/Compiler Selection

[Marin David Condic, 561.796.8997, M/S 731-96]

Roger Racine[SMTP:rracine@draper.com] writes:
|One of Draper Laboratory's first Ada projects was an engine controller.
|That project used a bare Ada runtime system quite successfully.  The only
|problem with that approach is the slowness of loading programs (typically
|over an RS232 line).
|
    This sounds pretty typical of what we have around here. We get an
    embedded compiler where the RTK supplied with the compiler is the
    closest thing to an RTOS we've got. Usually, the RTK needs a
    little customization for peculiarities of the given system we are
    sticking it in. (Quite often, there's no clock, so we disable all
    the "delay" features, for example) We usually have either a UART
    or a Mil-Std-1553 bus for communication with the development
    equipment & program loading. Yes it can get slow, but usually,
    you're running tests on whatever you've put into EEPROM, and
    program loads are not too frequent.

|One does not even have to completely forego using all the Ada features.
|On the International Space Station program, they use the timer interrupt to
|get the executive task running, and after the high-priority, extremely
|time-critical processing is complete, the executive initiates the
|lower-priority tasks.  This might not be possible with your engine
|controller if you are using floating point registers in a slow processor.
|Some of the processors I have used took on the order of 100 microseconds to
|save the floating point registers during a context switch.  Your mileage
|may vary. :)  In that case you might want to continue your approach (cyclic
|executive).
|
    The YMMV part is really important. I had one system where we
    clocked the response from the instant our 1mSec interrupt went off
    to the instant we hit the first instruction of the interrupt
    procedure and found it to be on the order of 60 microseconds. Most
    of the rest of the world is thinking "big deal" but when you burn
    up this amount of time once every milisecond, that's 6% of your
    CPU time budget spent doing absolutely no useful work. And it only
    gets worse as the tasking environment comes into play.

    We can and do use the Ada tasking features in building executives.
    Its just that one has to be real careful about what you use when
    you are in the really high speed parts of the system. I know the
    compiler vendors work very hard at trying to make the tasking
    features as quick as possible. Ada95 tries to provide some help
    with protected types and all that. (I *really* want to conduct
    some experiments with this in our real time world to see how much
    better it is. But that means getting an Ada95 compiler for some
    sort of inexpensive SBC, and I despair of seeing this happen) But
    at really high cycle rates, you often can't afford to waste any
    time, so you go with the simplest possible implementation.
|
|I have used Rational, XD-Ada and Aonix personally, and Draper personnel
|have also used the TLD compiler, all using the bare runtime system (all
|Ada83).  We have had varying happiness with them, but we have had
|unqualified success with all of them.  Our unhappiness came from "ease of
|use" issues, and "cost of source to runtime system" issues.  I do not think
|we have had a project yet where we were able to avoid at least looking at
|the source to the runtime system.  We have done our share of modifying that
|source in some projects.
|
    We've had quite a bit of experience with XD-Ada and have been
    happy with the results. It's good to hear about the others, too.
    I'm curious about the target processors you were using these
    compilers with. (Our XD-Ada experience is primarily with
    Mil-Std-1750a and MC680x0 targets)

    I don't know how you get around the "cost of source to runtime
    system" issue when you build systems that are unconventional in
    nature. Usually, the embedded compiler is targeted to some
    "generic" kind of SBC that presumes you're going to plug a board
    into a VME bus or something similar and go off to the races from
    there. But when you're designing the computer from the ground up,
    the preconceived notions and unwarranted assumptions built into
    the RTK just don't hold and you've got to be able to change them.
    Usually, it isn't some sort of wholesale rewrite, but you do need
    to make adjustments.

    Thanks for the input.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "Because that's where they keep the money."
        --  Willie Sutton when asked why he robbed banks.
=============================================================================

Re: Embedded Processor/Compiler Selection

[Rakesh Malhotra]

Marin David Condic, 561.796.8997, M/S 731-96 wrote:
> 
> Roger Racine[SMTP:rracine@draper.com] writes:
> |One of Draper Laboratory's first Ada projects was an engine controller.
[delelted text]
>     some experiments with this in our real time world to see how much
>     better it is. But that means getting an Ada95 compiler for some
>     sort of inexpensive SBC, and I despair of seeing this happen) But
>     at really high cycle rates, you often can't afford to waste any
>     time, so you go with the simplest possible implementation.

We too develop custom hardware here (our market is embedded, real-time,
safety critical rail-road stuff)- in the past this has been boards based
on the Motorola 68302, 68332 and 68EC030.  All these were done in Ada83.

We are starting a new project, and for this I have been looking at using
the PowerPC EC603e, 166MHz/200MHz.   We have not actually started the
project and so I cannot provide you with much info other than just what
I have researched.  I did look into SBC's/ Ada compilers and there are a
few vendors out there selling SBCs (PowerPC) for $1500 to about $5000. 
Do not know if this expensive for you.   I guess the Ada95 compiler
environment would be expensive - though if you just wanted to do a bunch
of benchmarks you could probably convince a vendor to "loan" you a
license for a month.

The other thing I looked into was using Linux on PowerPC.  There is a
port of Linux/ PowerPC available and GNAT may run on it.  Have not
investigated this yet. I understand that Linux is far from real-time but
if you have an in-circuit emulator you may be able to do benchmarking by
setting up address ranges (though you would need an ICE for your
processor).

In the past I have used Alsys and Rational Ada83 compilers.  The Alsys
compiler comes with a run-time called SMART which is a cut down, bare
bones runtime - it does not support tasking/heap allocation etc. 
However since we use a tool called SPARK (for static analysis of our
software) and this tool does not allow the use of more esoteric Ada
features anyway, it does not really matter.   I have had very good
results with SMART.

More recently we used Rational (VADS) and this too has an optional
runtime that is fairly cut down -- have not had many problems.

Note: as an aside I was amazed to find that a PowerPC running at 133MHz,
giving well over 100MIPS costs just $25/- and dissipates of the order of
only 4W !!
--
Rakesh

Re: Embedded Processor/Compiler Selection

[phil.brashear]

In article <dewar.888332332@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>
> This advice from Phil, as one of the creators of ACES, is not a surprise :-)
>

Right!  As I said, this is my standard reply.

> But I have a question, has anyone successfully used the latest version of
the
> full ACES suite. We had a couple of customers look at using it and decide
> it was far too much work. One customer used the Quick-Look facility, but
> I would not base much on the results from this, since it is a rather
> miscellaneous collection of tests.

Yes, I have exchanged information with various people who appear to be using
ACES successfully.  (Sometimes I wish they were just a little bit less
successful, so they could pay me to help -- but that's rather mercenary of me,
isn't it!)  To cite one example of ACES use, the primary software developer on
an ongoing major weapon used ACES to do formal evaluations of several Ada
implementations as part of selecting an appropriate combination of platform
and compiler.

Yes, it's a lot of work, though less than previous versions, due to the much-
improved user interface.  The hardest part, of course, is deciding
what you're trying to accomplish, and selecting the appropriate tests and
analysis techniques.

>
> Any set of canned benchmarks is always a bit dubious. I think you usually
> do better to create some test cases of your own, trying to mirror your
> intended application as closely as possible.
>

One of the nice features of the ACES is that it provides a facility for
inserting your own benchmarks into the ACES testing and analysis processes.
It also provides a mechanism for selecting, processing, and analyzing subsets
tailored to your needs.

All this said, the fact remains that ACES is big, and the amount of
information produced can be overwhelming if you aren't selective.
Performance evaluation is a very tricky thing, not because ACES is hard to
use, but because the concept of measuring performance is loaded with
difficulties.

The worst thing is that after all the work of selection, processing,
analyzing, and understanding the results, you run into a manager who wants
you to give him a single number representing the performance of each
implementation.  One might as well give such a manager the Douglas Adams
answer: 42.

Phil

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: Embedded Processor/Compiler Selection

[Marin David Condic, 561.796.8997, M/S 731-96]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>
>No, that's a misunderstanding. Windows CE is indeed intended for hard
>real time embedded applications. Look for example at the recent newsstory
>on its adoption for a multi-million unit High-definition cable TV gizmo.
>
    Some folks have mentioned to me that Windows CE has been designed
    to work for real time systems (I'd still like to verify that it
    doesn't have the interrupt uncertainty problems of NT) but that
    there are other complaints. One complaint is that CE can currently
    only be used to work with Microsoft development tools due to
    proprietary load module formats. Another objection is that it is
    large (I can't believe the numbers that were given to me, so I
    won't quote them. I've got to chalk it up to a misunderstanding.
    But still the indication is that it is quite sizeable.)

    So it would seem that for the time being, it may be beyond
    consideration for my kind of app. But if it is being used in
    something like an HDTV gadget of some kind, maybe it has some
    potential. More research is clearly needed.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
     And who dares mock Spam?
     You? you? you are not worthy
     Of one rich pink fleck
        --  Spam Haiku
=============================================================================