A5 vendors

Hi,

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

Thx,
--don

On 1/31/2015 1:12 PM, Don Y wrote:
> Hi,
>
> 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).
>
> Thx,
> --don

Is that a paper size?  There is a lot more to paper than just its size.

-- 

Rick

On 2015-02-01, rickman <gnuarm@gmail.com> wrote:
> On 1/31/2015 1:12 PM, Don Y wrote:
>> Hi,
>>
>> 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).
>>
>
> Is that a paper size?  There is a lot more to paper than just its size.
>

I think Don's talking about the ARM Cortex A5.

I've no experience with them myself however.

Simon.

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

On Sun, 01 Feb 2015 14:21:28 +0000, Simon Clubley wrote:

> On 2015-02-01, rickman <gnuarm@gmail.com> wrote:
>> On 1/31/2015 1:12 PM, Don Y wrote:
>>> Hi,
>>>
>>> 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).
>>>
>>>
>> Is that a paper size?  There is a lot more to paper than just its size.
>>
>>
> I think Don's talking about the ARM Cortex A5.
> 
> I've no experience with them myself however.

Me neither.  Don, you may be a c.a.e pioneer.

Personally, I may have a use for the M7, if it can do double-precision 
floating point way fast.

-- 
www.wescottdesign.com

On 31/01/15 19:12, Don Y wrote:
> Hi,
>
> 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.

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
  Linux
  hard/soft real time
  requirements?

I have an Atmel SAMA5D3 board on my desk.

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 09:59:24 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

>Personally, I may have a use for the M7, if it can do double-precision 
>floating point way fast.

That's what we wanted, too. However, double-precision floats are an
option in the M7 profile, and all the M7 devices I have read about
are single-precision only.

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

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?

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.

I have proof-of-concept implementations running on x86 SBC's (easiest
"development boards" with MMU support to get a hold of "in quantity").
I had originally planned to move many nodes onto dumber "motes" and
was targeting the M3 devices for that.  But, am now shifting the
implementation to push more of the server functionality into the
"remotes" -- which means they start to look more like the server
than the original (dumb) "motes".  Entirely different coding style...

> 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)?

On Sun, 01 Feb 2015 17:38:55 +0000, Stephen Pelc wrote:

> On Sun, 01 Feb 2015 09:59:24 -0600, Tim Wescott <tim@seemywebsite.com>
> wrote:
> 
>>Personally, I may have a use for the M7, if it can do double-precision
>>floating point way fast.
> 
> That's what we wanted, too. However, double-precision floats are an
> option in the M7 profile, and all the M7 devices I have read about are
> single-precision only.

Crudbuckets.  Fortunately I need it for a back-burner personal project, 
so I can wait.

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.

-- 
www.wescottdesign.com