A5 vendors

On 2015-02-01, Don Y <this@is.not.me.com> wrote:
> Hi Stephen,
>
> On 2/1/2015 10:36 AM, Stephen Pelc wrote:
>> On Sat, 31 Jan 2015 11:12:24 -0700, Don Y <this@is.not.me.com> wrote:
>>
>>> Any comments regarding A5 offerings?  Vendors to favor?  Avoid?
>>> Mainly interested in the number of bugs I'll have to address
>>> (and if any are fatal/no workaround).
>>
>> Will your application be
>>    bare metal
>
> "bare metal" in the sense that there is no (C)OTS OS running on it.
>

[snip]

>
>>    requirements?
>
> See my reply to David's post for more specifics.  The MMU requirement
> seems to limit the ARM products to the A-series devices.  Though, as
> I said, there, I'd be willing to look at other (non-ARM) families.
>

Hmmm. Bare metal MMU on a Cortex-A series MCU.

Been there, done that (in this case multiple A8 series MCUs). :-)

If the A5 is anything like the A8 then don't assume that MMU settings
which work on one A5 MCU will work on another A5 MCU.

I wrote up some of my experiences last year when (as I've just discovered)
you were asking about the ARM v7 MMU. Here's a pointer to a website which
archives comp.arch.embedded and has the discussion in question:

http://www.embeddedrelated.com/usenet/embedded/show/187707-1.php

It might be worthwhile for you to keep my discoveries in mind in case
you hit the same issues with the A5 MCUs.

It may also be worthwhile for you to see where you stand with things like
cache invalidation on the A5; I was surprised to see options available on
traditional MMU capable ARM MCUs retired on the A8.

Warning: I browse with Javascript disabled by default, so I don't know
if you are going to get hit by multiple adverts and popups when visiting
that URL.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Hi Simon,

On 2/1/2015 5:29 PM, Simon Clubley wrote:
> On 2015-02-01, Don Y <this@is.not.me.com> wrote:

>> "bare metal" in the sense that there is no (C)OTS OS running on it.

> Hmmm. Bare metal MMU on a Cortex-A series MCU.
>
> Been there, done that (in this case multiple A8 series MCUs). :-)

Yes, I recall discussing bits of this with you in a previous life.
I was wondering if you'd chime in with any "updates"...

Aside from your gripes about TI's policies, would you opine as to
which vendors (fabs) to prefer/avoid?  I.e., they're all largely making
the same *kit*...

> If the A5 is anything like the A8 then don't assume that MMU settings
> which work on one A5 MCU will work on another A5 MCU.

Yes, you'd said that in your past experience.  Any update as to possible
cause?

> I wrote up some of my experiences last year when (as I've just discovered)
> you were asking about the ARM v7 MMU. Here's a pointer to a website which
> archives comp.arch.embedded and has the discussion in question:
>
> http://www.embeddedrelated.com/usenet/embedded/show/187707-1.php
>
> It might be worthwhile for you to keep my discoveries in mind in case
> you hit the same issues with the A5 MCUs.

Yes, I have that discussion saved in my NNTP client.

> It may also be worthwhile for you to see where you stand with things like
> cache invalidation on the A5; I was surprised to see options available on
> traditional MMU capable ARM MCUs retired on the A8.

There are advantages to SMALLER caches!  :>

> Warning: I browse with Javascript disabled by default, so I don't know
> if you are going to get hit by multiple adverts and popups when visiting
> that URL.

I've got the browser here so tightly clamped that I usually have the
opposite problem:  sites that "don't work" because I've got <something>
turned off, crippled, etc.  [SWMBO grumbles about it, from time to time;
though nary a week or two goes by without her hearing of one of her
friends having a "broken" computer (malware)]

On Sun, 01 Feb 2015 14:20:00 -0700, Don Y <this@is.not.me.com> wrote:

>Hi Stephen,
>
>On 2/1/2015 10:36 AM, Stephen Pelc wrote:
>> On Sat, 31 Jan 2015 11:12:24 -0700, Don Y <this@is.not.me.com> wrote:
>>
>>> Any comments regarding A5 offerings?  Vendors to favor?  Avoid?
>>> Mainly interested in the number of bugs I'll have to address
>>> (and if any are fatal/no workaround).
>>
>> Will your application be
>>    bare metal
>
>"bare metal" in the sense that there is no (C)OTS OS running on it.
>
>>    Linux
>
>No.  See above.
>
>>    hard/soft real time
>
>Yes.
>
>>    requirements?
>
>See my reply to David's post for more specifics.  The MMU requirement
>seems to limit the ARM products to the A-series devices.  Though, as
>I said, there, I'd be willing to look at other (non-ARM) families.

Bare metal and (demand paging) MMU requirements do not make much
sense. Are you trying to develop your own RTOS ?

What for do you need that MMU, why not link everything, including
processor startup, device drivers and your application into a single
big executable file and transfer it somehow to the target processor by
inserting SD card or loading electrically (needs permanent boot) code?

Setting up the MMU is often a pain, not to mention any demand paging
system. Just run everything in a single linear address space.
 

On 2/1/2015 10:22 PM, upsidedown@downunder.com wrote:

>> See my reply to David's post for more specifics.  The MMU requirement
>> seems to limit the ARM products to the A-series devices.  Though, as
>> I said, there, I'd be willing to look at other (non-ARM) families.
>
> Bare metal and (demand paging) MMU requirements do not make much
> sense. Are you trying to develop your own RTOS ?

RTOS is already written.  But, on x86 hardware.  AFAICT, there's not
a low power, low cost, highly integrated version available.

> What for do you need that MMU, why not link everything, including
> processor startup, device drivers and your application into a single
> big executable file and transfer it somehow to the target processor by
> inserting SD card or loading electrically (needs permanent boot) code?

Single flat address space (no protection domains) leads to less reliable
code.  It also makes it harder to identify and locate problems (at debug
*and* run-time)  E.g., why is the kernel (Linux, BSD, Windows, etc.) given
special treatment?  Why not link everything in a single address space?
Think of how much *simpler* the entire system MIGHT be!

> Setting up the MMU is often a pain, not to mention any demand paging
> system. Just run everything in a single linear address space.

With a paged MMU, the OS has information that isn't available to any
other sort of implementation.  E.g., who referenced what and when; faster
out-of-band comms; information hiding; zero-copy sematics; etc.  Exploiting
this leads to a different coding style -- one where you concentrate on what
you want to *do* instead of the mechanisms by which you do it.

On Sun, 01 Feb 2015 17:09:32 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

>If I ever get desperate and want to throw a bunch of man-hours at it, I 
>can do the job using fixed-point 64-bit math and a whole bunch of careful 
>scaling -- but it would take rewriting some fairly heavy duty algorithms, 
>and I'd really rather wait.

The SAMA5D3x is a Cortex A5, and Atmael say they have bare-metal
code for it. This should have double-precision hardware. The EVBs
are not expensive.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On Sun, 01 Feb 2015 14:20:00 -0700, Don Y <this@is.not.me.com> wrote:

>> I have an Atmel SAMA5D3 board on my desk.
>
>Have you done any (bare-metal) work with it to be able to comment as
>to how "robust" (reliable? predictable?) the processor's design?
>And, how "responsive"/cooperative the vendor (Atmel) is to any
>problems you've encountered?  I.e., are they "on your side" or
>just trying to keep every "sold" product as "SOLD" (at YOUR
>expense/hassle/grief)?

We haven't started the bare-metal stuff yet, just installed
our Linux software.

It's too early to tell how responsive Atmel will be.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On 01/02/15 21:40, Don Y wrote:
> Hi David,
> 
> On 2/1/2015 9:41 AM, David Brown wrote:
>> On 31/01/15 19:12, Don Y wrote:
> 
>>> Any comments regarding A5 offerings?  Vendors to favor?  Avoid? 
>>> Mainly interested in the number of bugs I'll have to address
>>> (and if any are fatal/no workaround).
>>> 
>>> I can live with a single core (e.g., big.LITTLE isn't worth any 
>>> real dollars).
>> 
>> Why specifically A5?  Normally you don't want to specify the exact
>>  core, but rather the features you need (speed, SIMD, etc.) in the 
>> core, and the features you need in the chip itself (size, power, 
>> cost, availability, features, packaging, supplier, error rate, 
>> etc.).  There are lots of criteria in choosing a Cortex-A chip - 
>> the exact core is seldom relevant.
> 
> Assume (roughly) functionality has costs.  I.e., pay for *only* what 
> you *need*.
> 
> The above suggests finding the smallest/cheapest/least-performant 
> device that fits other goals.
> 
> ["Applications" in the following refers to actual uses I have on the 
> bench; not "pie-in-the-sky wish-lists"]
> 
> Low power, high level of integration, etc. all stand without 
> saying...
> 
> I can live with a 32b machine (but not 16 -- and unwilling to pay
> for 64)
> 
> I can live with a single core -- thus, not willing to pay for 
> big.LITTLE, either.
> 
> FPU isn't necessary -- though I can *exploit* (i.e., probably not 
> worth paying for them as I can emulate the required operations in 
> software in the resources available) even single precision in some 
> cases.
> 
> DSP/SIMD not necessary -- though I can *exploit* (see above) them in 
> *some* applications.
> 
> Support for demand paged MMU (with hardware protection).
> 
> Particular I/O's that can be exploited include LCD and camera 
> interfaces (GPIO's, etc. tend to fall out of the equation for most 
> devices -- though extra counter/timers can always find use!  At 
> *some* cost)
> 
> At least one 100Mb MAC/PHY -- preferably 1588 capable (though I can 
> work around that).  A *second* MAC is handy in some applications 
> (ideally also 1588).
> 
> Tools can always be acquired to fit *a* need.  But, I'm not keen on 
> having to buy/learn N sets of tools for N different solutions (to N 
> different applications).
> 
> The MMU requirement rules out all but the A-series, AFAICT (in ARM 
> product offerings -- I'd be willing to look at other 
> vendors/families). The I/O's can be addressed by products in other 
> series, but the MMU is too hard to live without.  A5 *seems* to be 
> the low point on the (current) performance/feature curve given the 
> above constraints. (Have I missed something?)
> 
> And, hopefully will be around a bit longer than some of the earlier 
> v7 devices. It also seems to have hooks to let me add some of those 
> features as apps are willing to pay for them (e.g., "IP camera" is 
> far more willing to pay for DSP functions than a "weather station")
> 
> I don't want to, for example, have to write another version of the 
> RTOS to deal with some other vendor's MMU, a different set of
> drivers for some other NIC, timers, etc.  And, a homogeneous system
> solution lets me optimize at even lower levels in the design (e.g.,
> data can be implicitly typed as I know the characteristics of the
> recipient device -- no endian conversions, floating point format
> conversions, struct packing changes, etc.)
> 
> But, with different fabs offering the same, "conceptually", IP, it 
> boils down to which are most "on top of" the designs.  I.e., 
> fix/acknowledge problems in the silicon *earliest*, etc.
> 
> [No idea what their licensing arrangements with ARM are -- does 
> buying a license to some IP entitle them to all *updates* to that
> IP? In which case, it's "just" a matter of when they choose to
> update their fab? OTOH, if IP updates *add* to the costs of fab
> update, then I suspect they are a lot less anxious to push fixes into
> production as they might otherwise be!]
> 
> Would you have chosen a different point in the A-series family?

In other words, no, you do /not/ specifically need a Cortex A5.

You need a chip with an MMU, reasonable processing power (multiple 100
MHz, but not multi-core, with FPU/SIMD as nice to have), and with at
least a 100 Mb MAC.  (Requiring an Ethernet PHY will reduce the choice
of devices to close to zero.)  You don't even require the chip to be an
ARM device - it could be PPC or MIPS as alternatives.

Apart from that, you want long-term availability and low cost.

None of that suggests a requirement for a Cortex A5 core.

From my own experience, the only chip of this sort that I have used is a
Freescale i.mx6 device, and we've been happy with the devices.  These
are a very popular range, and at least some of the i.mx6 devices are
part of Freescale's long-term availability program.  They happen to be
Cortex-A9 cores - but that should not matter to you.

On 2015-02-01, Don Y <this@is.not.me.com> wrote:
> Hi Simon,
>
> On 2/1/2015 5:29 PM, Simon Clubley wrote:
>> On 2015-02-01, Don Y <this@is.not.me.com> wrote:
>
>>> "bare metal" in the sense that there is no (C)OTS OS running on it.
>
>> Hmmm. Bare metal MMU on a Cortex-A series MCU.
>>
>> Been there, done that (in this case multiple A8 series MCUs). :-)
>
> Yes, I recall discussing bits of this with you in a previous life.
> I was wondering if you'd chime in with any "updates"...
>
> Aside from your gripes about TI's policies, would you opine as to
> which vendors (fabs) to prefer/avoid?  I.e., they're all largely making
> the same *kit*...
>

The problem with that is as a hobbyist, _my_ priorities are completely
different from yours. :-)

For example, while I have absolutely no problem with building my own
circuits around smaller PDIP based MCUs, my hardware skills don't extend
to building my own boards around the bigger stuff such as the Cortex-A8
range.

As a result, I am only exposed to larger MCUs which are available on
hobbyist priced boards, which will be a subset of the options available
to you.

Now, having said that, I do like the TI documentation on it's MCUs.
Yes, I know the access to sample code sucks, and yes, I got caught with
the MMU problem, but the documentation _overall_ is rather good (IMHO).

It's not just the Cortex-A material as well. I've also been looking at
the MSP430 documentation (because I'm interested in a closer look in the
future) and that documentation "appears" to also be rather good.

For a couple of other examples, the Freescale documentation wasn't as
good on the board I looked at (iMX233, which is traditional ARM not
Cortex-A) but was generally workable IIRC and the documentation on the
Chinese Allwinner Cortex-A jobs was absolutely appalling (when it existed
at all :-( ).

On the old SAM7S range, I thought the Atmel documentation was rather good
but I've no knowledge of recent Atmel ARM MCUs. Be aware however that
Atmel PDFs are now rather stupid sizes (at least for the AVRs) because
someone doesn't know how to properly create PDFs.

>> If the A5 is anything like the A8 then don't assume that MMU settings
>> which work on one A5 MCU will work on another A5 MCU.
>
> Yes, you'd said that in your past experience.  Any update as to possible
> cause?
>

No. In the end, I just accepted that was the case and moved on.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2/2/2015 6:08 AM, David Brown wrote:
> On 01/02/15 21:40, Don Y wrote:
>> Hi David,
>>
>> On 2/1/2015 9:41 AM, David Brown wrote:
>>> On 31/01/15 19:12, Don Y wrote:
>>
>>>> Any comments regarding A5 offerings?  Vendors to favor?  Avoid?
>>>> Mainly interested in the number of bugs I'll have to address
>>>> (and if any are fatal/no workaround).
>>>>
>>>> I can live with a single core (e.g., big.LITTLE isn't worth any
>>>> real dollars).
>>>
>>> Why specifically A5?  Normally you don't want to specify the exact
>>>   core, but rather the features you need (speed, SIMD, etc.) in the
>>> core, and the features you need in the chip itself (size, power,
>>> cost, availability, features, packaging, supplier, error rate,
>>> etc.).  There are lots of criteria in choosing a Cortex-A chip -
>>> the exact core is seldom relevant.
>>
>> Assume (roughly) functionality has costs.  I.e., pay for *only* what
>> you *need*.
>>
>> The above suggests finding the smallest/cheapest/least-performant
>> device that fits other goals.
>>
>> ["Applications" in the following refers to actual uses I have on the
>> bench; not "pie-in-the-sky wish-lists"]
>>
>> Low power, high level of integration, etc. all stand without
>> saying...
>>
>> I can live with a 32b machine (but not 16 -- and unwilling to pay
>> for 64)
>>
>> I can live with a single core -- thus, not willing to pay for
>> big.LITTLE, either.
>>
>> FPU isn't necessary -- though I can *exploit* (i.e., probably not
>> worth paying for them as I can emulate the required operations in
>> software in the resources available) even single precision in some
>> cases.
>>
>> DSP/SIMD not necessary -- though I can *exploit* (see above) them in
>> *some* applications.
>>
>> Support for demand paged MMU (with hardware protection).
>>
>> Particular I/O's that can be exploited include LCD and camera
>> interfaces (GPIO's, etc. tend to fall out of the equation for most
>> devices -- though extra counter/timers can always find use!  At
>> *some* cost)
>>
>> At least one 100Mb MAC/PHY -- preferably 1588 capable (though I can
>> work around that).  A *second* MAC is handy in some applications
>> (ideally also 1588).
>>
>> Tools can always be acquired to fit *a* need.  But, I'm not keen on
>> having to buy/learn N sets of tools for N different solutions (to N
>> different applications).
>>
>> The MMU requirement rules out all but the A-series, AFAICT (in ARM
>> product offerings -- I'd be willing to look at other
>> vendors/families). The I/O's can be addressed by products in other
>> series, but the MMU is too hard to live without.  A5 *seems* to be
>> the low point on the (current) performance/feature curve given the
>> above constraints. (Have I missed something?)
>>
>> And, hopefully will be around a bit longer than some of the earlier
>> v7 devices. It also seems to have hooks to let me add some of those
>> features as apps are willing to pay for them (e.g., "IP camera" is
>> far more willing to pay for DSP functions than a "weather station")
>>
>> I don't want to, for example, have to write another version of the
>> RTOS to deal with some other vendor's MMU, a different set of
>> drivers for some other NIC, timers, etc.  And, a homogeneous system
>> solution lets me optimize at even lower levels in the design (e.g.,
>> data can be implicitly typed as I know the characteristics of the
>> recipient device -- no endian conversions, floating point format
>> conversions, struct packing changes, etc.)
>>
>> But, with different fabs offering the same, "conceptually", IP, it
>> boils down to which are most "on top of" the designs.  I.e.,
>> fix/acknowledge problems in the silicon *earliest*, etc.
>>
>> [No idea what their licensing arrangements with ARM are -- does
>> buying a license to some IP entitle them to all *updates* to that
>> IP? In which case, it's "just" a matter of when they choose to
>> update their fab? OTOH, if IP updates *add* to the costs of fab
>> update, then I suspect they are a lot less anxious to push fixes into
>> production as they might otherwise be!]
>>
>> Would you have chosen a different point in the A-series family?
>
> In other words, no, you do /not/ specifically need a Cortex A5.

No -- I could *also* use an A15, etc.  :>  But, if you:

      Assume (roughly) functionality has costs.  I.e., pay for *only* what
      you *need*.

Then, buying a device with capabilities beyond your needs increases cost.
(Yes, I know the price:performance ratio can be upset by all sorts of factors.
But, with *hundreds* of ARM offerings from dozens of fabs, trying to build a
comparison matrix of ALL possible choices is a silly effort.  And, the
resulting decision can be invalidated by the chosen vendor dropping support,
altering its pricing strategy, etc.)

Given that ARM claims:

      "The ARM Cortex-A5 processor is the smallest, lowest cost and
      lowest power ARMv7 application processor"

I.e., ARM's positioning for the A5 seems to be *at* the low end of
the performance spectrum suggesting they haven't loaded it up with
"extra" features that would bias its cost upwards.  Assuming it is
well received by the market (in the long run), then it seems this
positioning would tend to hold and drive price accordingly.

(Of course, if all the volume moves to the high end of the spectrum,
then all bets are off.  But, such a change could also be a problem
for folks trying to acquire inventory and competing with others
buying in *huge* lots -- everything "on allocation")

It makes sense (to me) to start *there* -- and not at the opposite end
of the spectrum (e.g., A57) and work your way *down*!

> You need a chip with an MMU, reasonable processing power (multiple 100
> MHz, but not multi-core, with FPU/SIMD as nice to have), and with at
> least a 100 Mb MAC.  (Requiring an Ethernet PHY will reduce the choice
> of devices to close to zero.)  You don't even require the chip to be an
> ARM device - it could be PPC or MIPS as alternatives.

Correct.  Though note the other I/O's that I *will* require!  E.g., if
they aren't available from *some* vendor in a particular device family,
it means adding external components to provide that functionality (a
second MAC).  And, adding anything external typically costs you "something"
as pins (that would otherwise be used to make certain integrated I/Os
available) are freed up to interface with that device.

> Apart from that, you want long-term availability and low cost.
>
> None of that suggests a requirement for a Cortex A5 core.

Didn't say it *had* to be an A5.  Rather, from my survey of Cortex A series
parts (MMU requirement), the A5 offered enough performance and the right set
of possible I/O's (depends on the actual fab to see what they pin out) to
address my needs without leaving me paying for unused/unneeded features
or capabilities.

>  From my own experience, the only chip of this sort that I have used is a
> Freescale i.mx6 device, and we've been happy with the devices.  These
> are a very popular range, and at least some of the i.mx6 devices are
> part of Freescale's long-term availability program.  They happen to be
> Cortex-A9 cores - but that should not matter to you.

They don't have a second MAC available.  And, they seem geared towards
"display devices" -- tablets, phones, etc. -- with a heavy resource investment
(silicon) in providing that support.

On 2/2/2015 8:08 AM, David Brown wrote:
> On 01/02/15 21:40, Don Y wrote:
>> Hi David,
>>
>> On 2/1/2015 9:41 AM, David Brown wrote:
>>> On 31/01/15 19:12, Don Y wrote:
>>
>>>> Any comments regarding A5 offerings?  Vendors to favor?  Avoid?
>>>> Mainly interested in the number of bugs I'll have to address
>>>> (and if any are fatal/no workaround).
>>>>
>>>> I can live with a single core (e.g., big.LITTLE isn't worth any
>>>> real dollars).
>>>
>>> Why specifically A5?  Normally you don't want to specify the exact
>>>   core, but rather the features you need (speed, SIMD, etc.) in the
>>> core, and the features you need in the chip itself (size, power,
>>> cost, availability, features, packaging, supplier, error rate,
>>> etc.).  There are lots of criteria in choosing a Cortex-A chip -
>>> the exact core is seldom relevant.
>>
>> Assume (roughly) functionality has costs.  I.e., pay for *only* what
>> you *need*.
>>
>> The above suggests finding the smallest/cheapest/least-performant
>> device that fits other goals.
>>
>> ["Applications" in the following refers to actual uses I have on the
>> bench; not "pie-in-the-sky wish-lists"]
>>
>> Low power, high level of integration, etc. all stand without
>> saying...
>>
>> I can live with a 32b machine (but not 16 -- and unwilling to pay
>> for 64)
>>
>> I can live with a single core -- thus, not willing to pay for
>> big.LITTLE, either.
>>
>> FPU isn't necessary -- though I can *exploit* (i.e., probably not
>> worth paying for them as I can emulate the required operations in
>> software in the resources available) even single precision in some
>> cases.
>>
>> DSP/SIMD not necessary -- though I can *exploit* (see above) them in
>> *some* applications.
>>
>> Support for demand paged MMU (with hardware protection).
>>
>> Particular I/O's that can be exploited include LCD and camera
>> interfaces (GPIO's, etc. tend to fall out of the equation for most
>> devices -- though extra counter/timers can always find use!  At
>> *some* cost)
>>
>> At least one 100Mb MAC/PHY -- preferably 1588 capable (though I can
>> work around that).  A *second* MAC is handy in some applications
>> (ideally also 1588).
>>
>> Tools can always be acquired to fit *a* need.  But, I'm not keen on
>> having to buy/learn N sets of tools for N different solutions (to N
>> different applications).
>>
>> The MMU requirement rules out all but the A-series, AFAICT (in ARM
>> product offerings -- I'd be willing to look at other
>> vendors/families). The I/O's can be addressed by products in other
>> series, but the MMU is too hard to live without.  A5 *seems* to be
>> the low point on the (current) performance/feature curve given the
>> above constraints. (Have I missed something?)
>>
>> And, hopefully will be around a bit longer than some of the earlier
>> v7 devices. It also seems to have hooks to let me add some of those
>> features as apps are willing to pay for them (e.g., "IP camera" is
>> far more willing to pay for DSP functions than a "weather station")
>>
>> I don't want to, for example, have to write another version of the
>> RTOS to deal with some other vendor's MMU, a different set of
>> drivers for some other NIC, timers, etc.  And, a homogeneous system
>> solution lets me optimize at even lower levels in the design (e.g.,
>> data can be implicitly typed as I know the characteristics of the
>> recipient device -- no endian conversions, floating point format
>> conversions, struct packing changes, etc.)
>>
>> But, with different fabs offering the same, "conceptually", IP, it
>> boils down to which are most "on top of" the designs.  I.e.,
>> fix/acknowledge problems in the silicon *earliest*, etc.
>>
>> [No idea what their licensing arrangements with ARM are -- does
>> buying a license to some IP entitle them to all *updates* to that
>> IP? In which case, it's "just" a matter of when they choose to
>> update their fab? OTOH, if IP updates *add* to the costs of fab
>> update, then I suspect they are a lot less anxious to push fixes into
>> production as they might otherwise be!]
>>
>> Would you have chosen a different point in the A-series family?
>
> In other words, no, you do /not/ specifically need a Cortex A5.
>
> You need a chip with an MMU, reasonable processing power (multiple 100
> MHz, but not multi-core, with FPU/SIMD as nice to have), and with at
> least a 100 Mb MAC.  (Requiring an Ethernet PHY will reduce the choice
> of devices to close to zero.)  You don't even require the chip to be an
> ARM device - it could be PPC or MIPS as alternatives.
>
> Apart from that, you want long-term availability and low cost.
>
> None of that suggests a requirement for a Cortex A5 core.
>
>  From my own experience, the only chip of this sort that I have used is a
> Freescale i.mx6 device, and we've been happy with the devices.  These
> are a very popular range, and at least some of the i.mx6 devices are
> part of Freescale's long-term availability program.  They happen to be
> Cortex-A9 cores - but that should not matter to you.

The OP wrote 18 paragraphs which you summarized and gave an answer to in 
just 5 paragraphs.  I think you must have compressed out most of his 
content... or was it really that magniloquent?

-- 

Rick