tns1 wrote:
> Jim Granville wrote:
> 
>> tns1 wrote:
>>
>>> I am faced with selecting a replacement processor/uC for a re-design 
>>> of some industrial controller/safety equipment. The technical 
>>> requirements can be satisfied by just about any 32bit risc style 
>>> uP/uC, but one key requirement is that since the product life is 
>>> decades long, the particular part or at least the architecture should 
>>> continue to be supported by the vendor for as long as possible.
>>>
>>> This seems a pretty tough requirement. Years ago, the x86 would have 
>>> been a good choice, but probably not today.
>>
>>
>> Why not ?  PC104 and variants are long life, and the new Intel Atom
>> runs x86 code fine.
> 
> Board level standards for longevity may be the right way to go.
> 
> I think the Atom is too new, too complex, way overkill. I need maybe 
> 20-30mips max. Packaging reqs may be restricted to leaded parts due to 
> in-house assy req. Small process geometry may actually be a negative due 
> to lower radiation/cosmic ray tolerance. Think avionics & safety - what 
> would you use?

That's impoerant new information.
Just how 'mission critical' is this ?

Unless you can find a specific avionics qualified part, the next-best 
would be Automotive flow devices. Longer supply lifetimes, and generally
higher quality standards.
eg Infineon have ECC in their Automotive flash devices.

<snip>

> Maybe this means picking a vanilla part with fewer custom
> features instead of the 'one chip does as much as possible' approach I 
> would normally use.
> 
> A secondary goal might be to pick a popular architecture in the hopes 
> that there will at least be an easier upgrade path down the road.
> 
> As much as I dislike x86 for embedded, I have to consider using 
> PC104/x86 or another board standard.

You have not mentioned codesize yet. If you can fit this into an
Automotive 32 bit (Infineon, Freescale, TI... ) single chip, that
is likely to be the most reliable solution.

-jg

More info, OS and toolchain discussion...

This is industrial safety monitoring equipment that also has to meet 
some minimal radiation rating. Trailing edge technologies with larger 
process geometries may actually fare better. Compatibility with in-house 
assembly equipment may eliminate using BGA components.

The overall HW design will include RS232,RS485, current loop, A/D, D/A, 
a key panel with display, and some GPIO. The biggest change is to add an 
ethernet port which could be satisfied by some kind of separate serial 
to ethernet adaptor design as long as all the IP were available.

I am still getting an idea of what my requirements really are and what 
that means in terms of component selection. My interpretation so far is 
to stay away from proprietary architectures and tools which may go away. 
I think I will want the source for every piece, so open source or 
commercialized open source.

The original system design used the Intel i960 running the Intel iRMK 
kernel. You are lucky if you can even find any mention of this 
processor/scheduler combo today (tell me if you find anything), let 
alone any reference manuals. Intel is still going strong but these 
particular products have long been abandoned. The old command line 
cross-tools are still workable under XP, but obviously won't be of use 
on the re-design.

The iRMK/iRMX product was sold and the new company has continued with 
the x86 port. I'd consider it if I still wanted to use x86.

The existing kernel is just a scheduler without a filesystem. It only 
uses the most basic kernel services (tasks, semaphores, mailboxes). The 
only new complication is ethernet, which may not need to be handled 
directly by the main processor if it complicates the whole safety 
verification part too much. There is a big advantage in preserving 
existing code and task partitioning - something simple and very similar 
to the existing kernel.

Possible candidates so far are Ecos, QNX, FreeRTOS/SafeRTOS, L4. If it 
isn't already ported to many devices or the complete source is not 
available, then it isn't a candidate. On the other hand, my app code is 
commercial and probably can't be made public.

tns1 wrote:
> 
> The overall HW design will include RS232,RS485, current loop, A/D, D/A, 
> a key panel with display, and some GPIO. The biggest change is to add an 
> ethernet port which could be satisfied by some kind of separate serial 
> to ethernet adaptor design as long as all the IP were available.
> ...
> The existing kernel is just a scheduler without a filesystem. It only 
> uses the most basic kernel services (tasks, semaphores, mailboxes). The 
> only new complication is ethernet, which may not need to be handled 
> directly by the main processor if it complicates the whole safety 
> verification part too much. There is a big advantage in preserving 
> existing code and task partitioning - something simple and very similar 
> to the existing kernel.
> 
> Possible candidates so far are Ecos, QNX, FreeRTOS/SafeRTOS, L4. If it 
> isn't already ported to many devices or the complete source is not 
> available, then it isn't a candidate. On the other hand, my app code is 
> commercial and probably can't be made public.

I'm thinking Freescale Coldfire or some of the automotive or industrial 
PowerPC controllers might be a good choice.  They both have been around 
a while and should continue to be available.  Try www.netburner.com for 
some Coldfire info on real world HW and SW.

Also, you might want to add RTEMS (www.rtems.com) to your OS list.


     -Dave-

tns1 wrote:
> More info, OS and toolchain discussion...
> 
> This is industrial safety monitoring equipment that also has to meet 
> some minimal radiation rating. Trailing edge technologies with larger 
> process geometries may actually fare better. Compatibility with in-house 
> assembly equipment may eliminate using BGA components.

If you have such sign-offs, then you might need some Eval-boards, to
reality-check before going too far down one pathway.

This could also favour Error Correcting Flash devices, and that
will narrow your field a lot.
Or a device with Stack Error trapping.
Infineon XC2000 family offers those features. (as does XE16x)
(and allows 5V ADC operation)

> 
> The overall HW design will include RS232,RS485, current loop, A/D, D/A, 
> a key panel with display, and some GPIO. The biggest change is to add an 
> ethernet port which could be satisfied by some kind of separate serial 
> to ethernet adaptor design as long as all the IP were available.
> 
> I am still getting an idea of what my requirements really are and what 
> that means in terms of component selection. My interpretation so far is 
> to stay away from proprietary architectures and tools which may go away. 
> I think I will want the source for every piece, so open source or 
> commercialized open source.

I'm not sure having 100% source code coverage is that important - after 
all, you got this far without it!

Better is to avoid any sort of security keying on the tools, as that CAN 
be a long-term killer.

As you say
> The old command line cross-tools are still workable under XP

-jg

On Mon, 07 Jul 2008 13:32:18 +1200, Jim Granville
<n...@designtools.maps.co.nz> wrote:

><snip>
>Better is to avoid any sort of security keying on the tools, as that CAN 
>be a long-term killer.

Bingo.  That can be _very_ problematic.

Jon

On Sun, 06 Jul 2008 12:53:47 -0700, tns1 <t...@cox.net> wrote:

>Jim Granville wrote:

>> How many Decades, exactly ?

>20-40yrs

With that kind of period, I would suggest standardizing a board level
mechanical and electrical interfaces specification and be prepared to
redesign the board 2-3 times during that period, so that any boards
from any generation can be freely mixed. 

While some designs have been in production for more than two decades
with little changes, for instance the RoHS directive may cause
problems if semiconductor manufacturers are not willing to create
lead-free versions of some very old design. Although the RoHS
directive has some allowance for leaded replacement part, the demand
may drop quite fast, causing the end of life for a specific product.

Also the availability of lead-through components may drop, since most
use surface mount components these days.

This development would have been hard to predict 20 years ago, so do
we expect to be able to give better prediction now about what will
happen during the next 20 years ?

Making a board level mechanical/electrical design allows much more
flexibility in implementing what is on the board at a specific decade.


Paul

"Jack Klein" <j...@spamcop.net> wrote in message 
news:5...@4ax.com...
> You might want to snare the 2007 version as well, under the assumption
> that you might be forced to move Windows Vista someday.

Dude! The OP said "decades". I'm thinking 1982 compared to today; today 
compared to 2035. Ciarcia was still writing for Byte magazine back then. 
Around that time, he was espousing programmable logic for hobbyists; I wrote 
him off for many years, stopped reading his columns, as being a little too 
radical. :)

(Thanks for the links.)

Mike.

On Jul 6, 4:02 pm, tns1 <t...@cox.net> wrote:
> Frank-Christian Kruegel wrote:
> > On Sat, 05 Jul 2008 23:15:21 -0700, tns1 <t...@cox.net> wrote:
>
> >> I am faced with selecting a replacement processor/uC for a re-design o=
f
> >> some industrial controller/safety equipment. The technical requirement=
s
> >> can be satisfied by just about any 32bit risc style uP/uC, but one key
> >> requirement is that since the product life is decades long, the
> >> particular part or at least the architecture should continue to be
> >> supported by the vendor for as long as possible.
>
> > You might consider using softcores in FPGAs. That means that the cpu an=
d all
> > peripherials are coded in VHDL or Verilog and compiled into logic that =
can
> > be loaded into an FPGA. If a silicon gets unavailable, you just recompi=
le
> > your source for another one. Ok, it'll be a bit more work than just
> > recompiling, but much less then changing the system architecture.
>
> > Mit freundlichen Gr=FC=DFen
>
> > Frank-Christian Kr=FCgel
>
> Softcore/FPGA solutions do seem attractive from the view of being able
> to exactly duplicate the design far down the road using very different
> programmable logic devices. The extra design effort and the
> validation/qualification to meet the safety requirements will probably
> nix this idea. At least with a hard core, the manuf. has done a lot of
> this for you. Besides, point me to a 32bit risk soft-core that is
> open-source (not vendor specific), and has reached mainstream.

How about the 32 bit soft core from Lattice?  They claim it is open
source and not locked to their parts.  I have not looked at it hard
enough to verify this.

Rick

On Jul 6, 5:05 pm, tns1 <t...@cox.net> wrote:
> More info, OS and toolchain discussion...
>
> This is industrial safety monitoring equipment that also has to meet
> some minimal radiation rating. Trailing edge technologies with larger
> process geometries may actually fare better. Compatibility with in-house
> assembly equipment may eliminate using BGA components.
>
> The overall HW design will include RS232,RS485, current loop, A/D, D/A,
> a key panel with display, and some GPIO. The biggest change is to add an
> ethernet port which could be satisfied by some kind of separate serial
> to ethernet adaptor design as long as all the IP were available.
>
> I am still getting an idea of what my requirements really are and what
> that means in terms of component selection. My interpretation so far is
> to stay away from proprietary architectures and tools which may go away.
> I think I will want the source for every piece, so open source or
> commercialized open source.
>
> The original system design used the Intel i960 running the Intel iRMK
> kernel. You are lucky if you can even find any mention of this
> processor/scheduler combo today (tell me if you find anything), let
> alone any reference manuals. Intel is still going strong but these
> particular products have long been abandoned. The old command line
> cross-tools are still workable under XP, but obviously won't be of use
> on the re-design.
>
> The iRMK/iRMX product was sold and the new company has continued with
> the x86 port. I'd consider it if I still wanted to use x86.
>
> The existing kernel is just a scheduler without a filesystem. It only
> uses the most basic kernel services (tasks, semaphores, mailboxes). The
> only new complication is ethernet, which may not need to be handled
> directly by the main processor if it complicates the whole safety
> verification part too much. There is a big advantage in preserving
> existing code and task partitioning - something simple and very similar
> to the existing kernel.
>
> Possible candidates so far are Ecos, QNX, FreeRTOS/SafeRTOS, L4. If it
> isn't already ported to many devices or the complete source is not
> available, then it isn't a candidate. On the other hand, my app code is
> commercial and probably can't be made public.

This is just my opinion of course, but have you considered that
although someone is asking for 20 to 40 year product life (btw 20 to
40 years is not spec, they need to decide if 20 is good enough or if
they really need 40) is that really a useful target.  Usually a long
life time for a product is desired when the development requires a lot
of testing or there is some other high expense associated with
changing the product.

I don't think there are many apps that have a higher development
expense than space equipment.  The shuttle has been around for about
25 years.  The computers have been replaced and I expect there is
virtually no digital electronics that hasn't been redesigned other
than possibly SSI/MSI type stuff which will virtually never go away.

So does your application *really* warrant a 40 year product lifetime?
Even if you go with PC/104 boards, do you really think this bus will
still be around in even just 20 years?  I don't.

Looking at your stated requirements realistically, I think that 20
years is a very outside possibility for a product lifetime.  Of the
solutions offered so far, I don't see any that can make it likely that
the entire unit won't have to be redesigned and recoded at least once
in 20 years.  Try to get any manufacturer to state they will make a
part for even 5 years... I have asked and they won't do it.  So what
do you think the chances are that they will make it for more than 10
years much less 20?  If you count on there being PC/104 boards COTS in
10 more years, I think you may get a surprise.  Again, I just can't
see PC/104 being around in 20 years.  Heck, I'm not even sure the PC
will be around in 20 years.  Computing is just changing too fast.  I
expect that in 10 years the desktop PC will be an antique and they
will all be about the size of today's routers, most likely built into
the monitor.  Items like PC/104 boards will have changed to either a
much smaller form factor for lower end devices or will have much
faster interfaces for higher end embedded, much like the PC/104+ uses
PCI.

I guess it is a lot more fun to work the problem and try to come up
with something that has a chance of making the 20 year mark.  But I
think realistically your company (or the end user) would be better
served by acknowledging that it will be hard to make 10 years and 20
is very unlikely and planning accordingly.

Am I being overly pessimistic?

Rick

tns1 wrote:
> More info, OS and toolchain discussion...
> 
> This is industrial safety monitoring equipment that also has to meet 
> some minimal radiation rating. Trailing edge technologies with larger 
> process geometries may actually fare better. Compatibility with in-house 
> assembly equipment may eliminate using BGA components.
> 
> The overall HW design will include RS232,RS485, current loop, A/D, D/A, 
> a key panel with display, and some GPIO. The biggest change is to add an 
> ethernet port which could be satisfied by some kind of separate serial 
> to ethernet adaptor design as long as all the IP were available.

  Looking at ST's website, under "Automotive 32 Bit Controllers"
interesting to note they do NOT list their Cortex M3, but they DO list 
the PowerPC offerings, a joint sourcing venture with Freescale.
  These have ECC in Flash and RAM, and protected memory - and 5V operation.

  5V operation is one standardisation that is coming back :)

  After a few years when the IC vendors tried telling their customers
to keep finding new and many ever-lower voltages, they finally got 
enough skills in the fab, to give customers what they always wanted : 
ONE supply rail, with good noise immunity, and analog dynamic range.

  Seems second sourcing is coming back too... :)

-jg