A5 vendors

On 2/2/2015 6:36 AM, Simon Clubley 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.

Understandable.

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

I would gladly trade code samples (away) for complete and ACCURATE
documentation.  Too often, I've found bugs in published software/hardware
"samples"... i.e., good to convey a general *concept* but often not
addressing important details or -- *gasp* -- bugs in the silicon!

My design philosophy relies heavily on *specification*.  Tell me how the
devices (hardware/software/tools) that I am using will (!!!) behave and
I can design accordingly.  *I* can evaluate the cost of workarounds for
KNOWN bugs and see if it still makes sense to use a particular component.
Or not.

But, my process doesn't well tolerate "surprises".  Esp if those surprises
are in key areas of the design (like the VM system!).  E.g., I can tolerate
an I2C i/f only delivering 14b of data reliably to an audio D/AC.  But,
if it "randomly" decides WHICH 14b to deliver correctly, then that i/f
is effectively useless to me.

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

Colleagues have expressed "qualification" in their comments on TI devices
in the (recent) past.  I.e., bugs tend *not* to get fixed so pray
everything "broken" is documented as such.

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

I suspect a cultural issue.  I noticed when doing custom buys from Japanese
firms there was a different bias in how they approached the problem:
*We'd* want to know what they could *do* (affordably) while they wanted
to know what we *wanted*.  Left us wondering how we'd be able to decide if
we were getting good value as their capabilities would be masked by the
specifications we placed on the deliverables ("Yup!  Everything meets
the spec!  But, who knows how much select-at-test happened to cull these
from their production lot:  1%?  99%??")

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

Yes.  But, aside from the cost to download, I think you can rebuild the PDF's
and shrink them accordingly.  I've not looked at their internals to see
*why* they are so large (not an issue for me)

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

Fair 'nough.

On 2/2/2015 5:39 AM, Stephen Pelc wrote:
> 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.

Is this your *own* port?  Or, something from the Linux4SAM group?
(presumably, the latter would have a more conservative implementation
as they have to address *all* devices in the family)

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

<frown>  And Ulf seems to have gone missing...

Good luck with your effort!  I'd be interested in any "surprises"
you encounter -- hopefully none "spectacular"!

Hi Stephen,

On 2/2/2015 5:39 AM, Stephen Pelc wrote:
> 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.

Is this an *Atmel* sourced board (i.e., "Xplained")?  Or, third party?

Which D3 device is populated?  (e.g., the Xplained has a D36; I would
target the D31 and D35 -- unless the D36 cost premium was insignficant)

I may opt to port *just* my VM system and see what sorts of issues
arise -- and, how Atmel responds to those -- before taking the plunge
and formally embracing the device.

On 02/02/15 20:53, Don Y wrote:
> 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.

You know as well as I do that this is only the theory - so many things 
influence the cost of a SoC that the exact core type is a minor issue, 
and it will often be overwhelmed by other factors.  Statistically, there 
is probably a higher chance that the ideal chip for your use is an A5 - 
but only statistically.  Your original post made A5 seem the most 
important requirement, when that is clearly not the case - once that is 
dropped, all your other questions and concerns make sense.


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

What does your favourite distributor recommend?  If I were in your 
situation, that is the first person I would ask - they are the people 
who will be supplying you with the chips, the development boards, and 
the support.

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

Yes, but since the A5 is a relatively new core, your choices will be 
fewer and the competition is less - you might easily find a chip with an 
older core that costs less for more features.

>
> (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*!
>

I agree that it makes more sense to start with the A5 than the A57 - but 
I think it makes even more sense to ignore the exact core type at the 
start of your search.

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

If you need a second MAC, then my guess is that that requirement will 
push you out of the realm of the lowest price chips - and out of the 
realm of A5 devices.  First find the selection of chips that fit your 
peripheral needs - then consider other factors such as price, packaging, 
and long-term availability.

As an alternative idea here, you might consider using a chip with a 
single MAC along with a 3-way Ethernet switch - these are available with 
a MII (or RMII) interface and two PHY interfaces, along with Layer 2 
VLAN support and management.  Since you will need an external PHY 
anyway, this might be the cheapest way to get the two independent 
interfaces (though the documentation for how to set up port-based VLAN 
switching may not be very clear).

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

Indeed - but as these are the only ones I have personal experience with, 
they are the only ones I could mention here.

Hi David,

On 2/2/2015 3:06 PM, David Brown wrote:

>>>> 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.
>
> You know as well as I do that this is only the theory - so many things
> influence the cost of a SoC that the exact core type is a minor issue, and it
> will often be overwhelmed by other factors.

Of course!  And, the decision that makes sense today may not stand the test of
time as others adopt <whatever> fits *their* needs.

> Statistically, there is probably a
> higher chance that the ideal chip for your use is an A5 - but only
> statistically.  Your original post made A5 seem the most important requirement,
> when that is clearly not the case - once that is dropped, all your other
> questions and concerns make sense.

My initial post asked for information on A5 vendors.  I would assume readers
would show me the respect of assuming that I had "done my homework" and wasn't
looking for <laundry list of features> -- each of which they would then want
to see *justified* and offer alternative suggestions.

>> 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.)
>
> What does your favourite distributor recommend?  If I were in your situation,
> that is the first person I would ask - they are the people who will be
> supplying you with the chips, the development boards, and the support.

They'll gladly sell me whatever I am willing to buy.  "Local" usage
(or lack thereof) can bias their "advice":  if you work in a cluster
of telecom companies but *aren't* doing telecom work, chances are the
"local stock" (and sales experiences) will match your needs poorly.

>> 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.
>
> Yes, but since the A5 is a relatively new core, your choices will be fewer and
> the competition is less - you might easily find a chip with an older core that
> costs less for more features.

And the older core might go away sooner.  :>  It's always a crap shoot.
I'm banking on ARM Ltd. having a much better/broader understanding of The
Market than I do -- or any disti's, etc.  I.e., they've chosen to invest
*their* effort/dollars in this product offering.  Presumably because they
see a need for it.  I (and I suspect almost *all* OEMs) don't have the
resources to investigate all sectors of a particular market before making a
choice as to which components to use/avoid.  So, leverage the efforts of
someone (e.g., ARM) who has a more highly vested interest in that knowledge.

>> (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*!
>
> I agree that it makes more sense to start with the A5 than the A57 - but I
> think it makes even more sense to ignore the exact core type at the start of
> your search.

I *did* "ignore the exact core type at the start of my search".  (Again,
assume I have *done* my homework by the nature of the question posed).
I ruled out the M-series and R-series devices based on the lack of MMU
support.  That left the A-series devices (in ARM's portfolio).  Of these,
the A5 gave me what I needed in terms of available features -- it didn't
force me to accept The Kitchen Sink but let me pick a couple of different
(related) devices to bias my price point without having to reinvest in
all new tools, codebase, etc.

That left *one* issue:  who to buy the ARM IP from -- hence the subject
line of my post!  That decision involves specifics of the individual
product offerings from each vendor *around* that A5 technology.  And
price.  And, support.

I can freely explore the details of the various parts offered/announced.
I can also get pricing information (at least in 1K qty's... I'm not going
to get involved in bigger qty pricing at this stage of the selection
process).

What I can't "lookup" is support experiences (beyond app notes which are
often of dubious quality and/or recycled from ARM directly).  In particular,
how glitches/bugs in the designs are handled by the manufacturers.  A bug
that has significant impact TO ME (but perhaps not to someone else) that
isn't addressed can be the kiss of death for a design.  OTOH, if the vendor
is responsive and folds those fixes into *continuing* updates to the
technology, then it's just a momentary inconvenience (I've had to place
orders where specific masks were required to meet our needs; not fun but
at least it keeps product moving).

>>> 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.
>
> If you need a second MAC, then my guess is that that requirement will push you
> out of the realm of the lowest price chips - and out of the realm of A5
> devices.  First find the selection of chips that fit your peripheral needs -
> then consider other factors such as price, packaging, and long-term availability.

The A5's come with 1 Gb, 1 100Mb or both MACs.  There are M3's with similar
hardware complements -- but no MMU.  (I did some prototyping work on some
of the designs with M3's -- but without adding the VM functionality, obviously)

So, my A5 selection reflects all of this "homework".

> As an alternative idea here, you might consider using a chip with a single MAC
> along with a 3-way Ethernet switch - these are available with a MII (or RMII)
> interface and two PHY interfaces, along with Layer 2 VLAN support and
> management.  Since you will need an external PHY anyway, this might be the
> cheapest way to get the two independent interfaces (though the documentation
> for how to set up port-based VLAN switching may not be very clear).

I considered that.  But, the two independent interfaces is a better fit.
Especially for 1588-ish work (the A5's support 1588 on the Gb i/f -- but
not on the 100Mb).

>>>  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.
>
> Indeed - but as these are the only ones I have personal experience with, they
> are the only ones I could mention here.

My point was that I had already been through this exercise to "settle"
on the A5's.  Had the A5 *not* had some of the I/O's I need, I would
have considered stepping *up* to a different core (assuming the I/O's
were available on *that* core).

[There's a *long* list of "required" capabilities, I/O's, etc.  As I didn't
need c.a.e denizens make my *device* selection for me, I didn't bother
mentioning any of them.]

I'd also looked at different classes of devices for different functionality
(e.g., motes and servers).  And, even big.LITTLE to dedicate a processor to
handling the network.  Bottom line, the A5 seems to have "enough" capability to
address my needs without going into more exotic/heterogeneous implementations.

I'm going to follow Stephen's (and Simon's) lead and buy 4 or 5 (identical)
EVB's so I can implement my VM system and see what sorts of problems I stumble
upon.  And, how the vendor responds to any problems that I report.  This
will allow me to get a feel for what the device *might* be like in production
(i.e., no guarantee that it isn't "re-bugged" at a later date!)

I'll have to see how little I can implement to exercise what needs to be
"proven".  If all goes well, I can start designing boards based on those
results.

Hi Don,

On 02/02/15 23:54, Don Y wrote:
> Hi David,
> 
> On 2/2/2015 3:06 PM, David Brown wrote:
> 
>>>>> 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.
>> 
>> You know as well as I do that this is only the theory - so many
>> things influence the cost of a SoC that the exact core type is a
>> minor issue, and it will often be overwhelmed by other factors.
> 
> Of course!  And, the decision that makes sense today may not stand
> the test of time as others adopt <whatever> fits *their* needs.

There is quite a bit of luck involved in predicting the future of
components!

> 
>> Statistically, there is probably a higher chance that the ideal
>> chip for your use is an A5 - but only statistically.  Your original
>> post made A5 seem the most important requirement, when that is
>> clearly not the case - once that is dropped, all your other 
>> questions and concerns make sense.
> 
> My initial post asked for information on A5 vendors.  I would assume 
> readers would show me the respect of assuming that I had "done my
> homework" and wasn't looking for <laundry list of features> -- each
> of which they would then want to see *justified* and offer
> alternative suggestions.

I would have preferred that you showed the group the respect of giving
your /real/ requirements, rather than just stating an artificial one and
then making us guess or ask for more information.  And you could have
shown that you'd done your homework by giving examples of some chips or
vendors that you are considering, but asking for opinions on.

I managed to summarise your "laundry list" in a single short paragraph -
it doesn't need to take more than that, unless people want more detail.

> 
>>> 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.)
>> 
>> What does your favourite distributor recommend?  If I were in your 
>> situation, that is the first person I would ask - they are the
>> people who will be supplying you with the chips, the development
>> boards, and the support.
> 
> They'll gladly sell me whatever I am willing to buy.  "Local" usage 
> (or lack thereof) can bias their "advice":  if you work in a cluster 
> of telecom companies but *aren't* doing telecom work, chances are
> the "local stock" (and sales experiences) will match your needs
> poorly.
> 

Maybe I'm lucky, but any of our four biggest distributors are happy to
give solid technical recommendations for components, including the
possibility of training or expert help, and information about stock,
availability, and sometimes inside information about vendor's future plans.

>>> 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.
>> 
>> Yes, but since the A5 is a relatively new core, your choices will
>> be fewer and the competition is less - you might easily find a chip
>> with an older core that costs less for more features.
> 
> And the older core might go away sooner.  :>  It's always a crap
> shoot. I'm banking on ARM Ltd. having a much better/broader
> understanding of The Market than I do -- or any disti's, etc.  I.e.,
> they've chosen to invest *their* effort/dollars in this product
> offering.  Presumably because they see a need for it.  I (and I
> suspect almost *all* OEMs) don't have the resources to investigate
> all sectors of a particular market before making a choice as to which
> components to use/avoid.  So, leverage the efforts of someone (e.g.,
> ARM) who has a more highly vested interest in that knowledge.
> 
>>> (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*!
>> 
>> I agree that it makes more sense to start with the A5 than the A57
>> - but I think it makes even more sense to ignore the exact core
>> type at the start of your search.
> 
> I *did* "ignore the exact core type at the start of my search".
> (Again, assume I have *done* my homework by the nature of the
> question posed). I ruled out the M-series and R-series devices based
> on the lack of MMU support.  That left the A-series devices (in ARM's
> portfolio).  Of these, the A5 gave me what I needed in terms of
> available features -- it didn't force me to accept The Kitchen Sink
> but let me pick a couple of different (related) devices to bias my
> price point without having to reinvest in all new tools, codebase,
> etc.

I will certainly assume that you did your homework - you never ask for
advice in this group without having done solid research in advance.  But
while I knew from your first post that you had thought about this, I had
no way of knowing /what/ research you had done, or why you thought the
A5 was the single possible choice of core.

I am not trying to say that you are wrong about the A5 - if vendors are
making the right SoC's for your use around an A5 core, and view them as
a long-term chips and not just cheap short-term ones, then it is
probably a good fit.

But your first post screams out for the question "why an A5" ?

You came to us with half an answer - we need to know the question before
we can find the other half of the answer, and we must challenge the
accuracy of the half-answer you have given.

And what is the risk here?  You are worried that if you say you need an
MMU, people will ask why?  Either you know the answer and have a good
reason for using it (and being the helpful person you are, you would
probably enjoy teaching others here about it), or the ensuing discussion
would also be helpful for you to clarify your own understanding of the
problem.

> 
> That left *one* issue:  who to buy the ARM IP from -- hence the
> subject line of my post!  That decision involves specifics of the
> individual product offerings from each vendor *around* that A5
> technology.  And price.  And, support.
> 
> I can freely explore the details of the various parts
> offered/announced. I can also get pricing information (at least in 1K
> qty's... I'm not going to get involved in bigger qty pricing at this
> stage of the selection process).
> 
> What I can't "lookup" is support experiences (beyond app notes which
> are often of dubious quality and/or recycled from ARM directly).  In 
> particular, how glitches/bugs in the designs are handled by the
> manufacturers.  A bug that has significant impact TO ME (but perhaps
> not to someone else) that isn't addressed can be the kiss of death
> for a design.  OTOH, if the vendor is responsive and folds those
> fixes into *continuing* updates to the technology, then it's just a
> momentary inconvenience (I've had to place orders where specific
> masks were required to meet our needs; not fun but at least it keeps
> product moving).
> 

These are all important aspects.  They are very difficult to answer, and
there is no good way to extrapolate other people's past experiences to
your own future ones, but maybe you'll get some general idea.

>>>> 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.
>> 
>> If you need a second MAC, then my guess is that that requirement
>> will push you out of the realm of the lowest price chips - and out
>> of the realm of A5 devices.  First find the selection of chips that
>> fit your peripheral needs - then consider other factors such as
>> price, packaging, and long-term availability.
> 
> The A5's come with 1 Gb, 1 100Mb or both MACs.  There are M3's with
> similar hardware complements -- but no MMU.  (I did some prototyping
> work on some of the designs with M3's -- but without adding the VM
> functionality, obviously)

No, the A5's do /not/ come with any sort of Ethernet.

There are some SoC's with A5 cores and MACs in those combinations - but
that is /nothing/ to do with the core.  There are other SoC's with
different cores with two MACs, and no doubt SoC's with A5 cores and more
or fewer MACs.

My guess (that SoC's with A5 cores and dual MACs would be hard to find)
turned out to be wrong, but the point is still that it is not the /core/
that is the deciding factor.

> 
> So, my A5 selection reflects all of this "homework".
> 
>> As an alternative idea here, you might consider using a chip with
>> a single MAC along with a 3-way Ethernet switch - these are
>> available with a MII (or RMII) interface and two PHY interfaces,
>> along with Layer 2 VLAN support and management.  Since you will
>> need an external PHY anyway, this might be the cheapest way to get
>> the two independent interfaces (though the documentation for how to
>> set up port-based VLAN switching may not be very clear).
> 
> I considered that.  But, the two independent interfaces is a better
> fit. Especially for 1588-ish work (the A5's support 1588 on the Gb
> i/f -- but not on the 100Mb).

Again, you are mixing apples and bananas.  A5 is the cpu core - it does
not support 1588 or anything else related to Ethernet.  If you want to
discuss a particular SoC, that's fine - but it is not an A5.

I agree that two independent MACs is often a better fit, unless hardware
layout issues make the switch more suitable.  And it will make accurate
timing with 1588 easier.

> 
>>>> 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.
>> 
>> Indeed - but as these are the only ones I have personal experience 
>> with, they are the only ones I could mention here.
> 
> My point was that I had already been through this exercise to
> "settle" on the A5's.  Had the A5 *not* had some of the I/O's I need,
> I would have considered stepping *up* to a different core (assuming
> the I/O's were available on *that* core).
> 
> [There's a *long* list of "required" capabilities, I/O's, etc.  As I
> didn't need c.a.e denizens make my *device* selection for me, I
> didn't bother mentioning any of them.]

Pick the important ones.  There is no need to mention UARTs, SPI, etc.,
unless you have very unusual requirements.

> 
> I'd also looked at different classes of devices for different
> functionality (e.g., motes and servers).  And, even big.LITTLE to
> dedicate a processor to handling the network.  Bottom line, the A5
> seems to have "enough" capability to address my needs without going
> into more exotic/heterogeneous implementations.
> 
> I'm going to follow Stephen's (and Simon's) lead and buy 4 or 5
> (identical) EVB's so I can implement my VM system and see what sorts
> of problems I stumble upon.  And, how the vendor responds to any
> problems that I report.  This will allow me to get a feel for what
> the device *might* be like in production (i.e., no guarantee that it
> isn't "re-bugged" at a later date!)
> 
> I'll have to see how little I can implement to exercise what needs to
> be "proven".  If all goes well, I can start designing boards based on
> those results.


A key point that you missed in your first posts was what you want to do
with the device - the automatic assumption when someone mentions a
Cortex A device is that they will be running Linux on it.  Anything is
is unusual, and is worth mentioning early on.  In particular, since you
are running your own OS, it is likely that you will have very different
memory requirements from a "typical" embedded Linux system.  So maybe
this would be a good choice:

<http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF3xx#>

These are mainly for industrial and automotive applications, so they
will be long-term devices (unlike devices targeted at consumer systems).
 I haven't used the Vybrid chips, but my experience with Freescale as a
vendor has been good.

On Mon, 02 Feb 2015 13:16:09 -0700, Don Y <this@is.not.me.com> wrote:

>> We haven't started the bare-metal stuff yet, just installed
>> our Linux software.
>
>Is this your *own* port?  Or, something from the Linux4SAM group?
>(presumably, the latter would have a more conservative implementation
>as they have to address *all* devices in the family)

One of the things we have learned over the last 15 years or so
is not to write O/S software for these devices - there's still
a NetWinder in the building. Let the Linux weenies do it for you.
Then find someone who *knows* what hard real time means and *pay*
them to install the patches.

The major decision for us all is whther to build or buy the
compute section of the hardware. With a quad-core ARM-7 
board (RPi B2) at GBP 27, approx USD 41, the balance is
tipping rapidly in favour of buy. There are many other
suppliers of quad-core boards in this price bracket, e.g.
Olimex.

>> It's too early to tell how responsive Atmel will be.
>
><frown>  And Ulf seems to have gone missing...

Even you will go missing one day ...

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 Mon, 02 Feb 2015 13:59:22 -0700, Don Y <this@is.not.me.com> wrote:

>>>> I have an Atmel SAMA5D3 board on my desk.
>
>Is this an *Atmel* sourced board (i.e., "Xplained")?  Or, third party?

Yes, the Xplained board with a D36.

>I may opt to port *just* my VM system and see what sorts of issues
>arise -- and, how Atmel responds to those -- before taking the plunge
>and formally embracing the device.

Depending on the CPU, you just need to be careful with instruction set
selection switches. For example, ARM32 code for Cortex-A has more
restrictions than (say) for an ARM11.

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 Stephen,

On 2/3/2015 6:01 AM, Stephen Pelc wrote:
> On Mon, 02 Feb 2015 13:59:22 -0700, Don Y <this@is.not.me.com> wrote:
>
>>>>> I have an Atmel SAMA5D3 board on my desk.
>>
>> Is this an *Atmel* sourced board (i.e., "Xplained")?  Or, third party?
>
> Yes, the Xplained board with a D36.

OK.  The D35 (or 36) and D31 were two of the candidates I was investigating.
I'll put one on order.  Not sure when I'll have time -- colleagues in town for
a status meeting.  Advantage of living somewhere *warm* at this time of year
is *you* don't have to travel (they are more than eager to come *to* you! :> ).
DISadvantage is you end up having to do a fair bit of "hosting".

[But, at least I get to set the schedule -- no early morning meetings!!  :> ]

>> I may opt to port *just* my VM system and see what sorts of issues
>> arise -- and, how Atmel responds to those -- before taking the plunge
>> and formally embracing the device.
>
> Depending on the CPU, you just need to be careful with instruction set
> selection switches. For example, ARM32 code for Cortex-A has more
> restrictions than (say) for an ARM11.

If they're documented, I'll have no problem.  I'm mainly concerned about
the "OhShits" -- stuff that *isn't* documented (or, documented incorrectly)
that you have to discover for yourself... "the hard way".

I figure if I purchase a few of these I can deploy some test code (running
just on the VM and a trimmed down network stack) to exercise the features
about which I'm most concerned...   Couple of hundred dollars for disposable
boards easily outweighs the cost of having to put something together
(just for test purposes).

Thx!

Hi Stephen,

On 2/3/2015 5:58 AM, Stephen Pelc wrote:
> On Mon, 02 Feb 2015 13:16:09 -0700, Don Y <this@is.not.me.com> wrote:
>
>>> We haven't started the bare-metal stuff yet, just installed
>>> our Linux software.
>>
>> Is this your *own* port?  Or, something from the Linux4SAM group?
>> (presumably, the latter would have a more conservative implementation
>> as they have to address *all* devices in the family)
>
> One of the things we have learned over the last 15 years or so
> is not to write O/S software for these devices - there's still
> a NetWinder in the building. Let the Linux weenies do it for you.
> Then find someone who *knows* what hard real time means and *pay*
> them to install the patches.

There's a difference between trying to backfill HRT solutions to
an OTS OS vs. designing a system with the features you need "up
front".  HRT is simple:  overprovision your design so you hit
every deadline.  Verify this on paper, then in testing.  Done.

I try to move "most" problems to SRT solutions (as most problems
really *are* SRT -- but just a lot easier to deal with if you
make the deadlines *hard*!  No need to resolve the pesky issues
of "well, what do I do *if* I miss a deadline?").  So, instead of
NO deadline handler (in a system that is completely HRT, you've
decided that deadlines MUST be met so the only thing you have to
deal with for a missed deadline is KILL THE JOB), I need hooks for
one and mechanisms that let the code "adapt" to the new set of
deadlines/values.

SRT means you have to come up with a (often variable) response to the
"deadline missed" scenario.  Reevaluate your relative priorities in
light of this (should I keep working on this task?  At the risk of
making some other task miss its deadline?  Or, should I just dump
the task and move on??).  Solutions tend to get more complicated
(and, thus, the mechanisms on which they rely tend to be more complex).

E.g., HRT with Linux can be accomplished by running Linux on a HRT
understructure that caters to your HRT needs and let Linux itself be
on a *par* with those needs (instead of forcing it to provide the
HRT guarantees itself).  This lets you sidestep things like designing
a RT network stack, VM/MM system, etc.

I take a similar approach (though w/o Linux) putting all the RT stuff
on my RTOS and hosting "userland" tasks in a scripting language
(Inferno/Limbo derived) that runs atop all that.  So, *what* the
system does can be easily scripted while the details of *how* it
manages to "get it done" can be hidden in RT services "beneath" it all.

> The major decision for us all is whther to build or buy the
> compute section of the hardware. With a quad-core ARM-7
> board (RPi B2) at GBP 27, approx USD 41, the balance is
> tipping rapidly in favour of buy. There are many other
> suppliers of quad-core boards in this price bracket, e.g.
> Olimex.

If I didn't have particular physical constraints on my final
deployment, hands down, I wouldn't bother with (core) hardware,
nowadays (e.g., the network speakers have to fit in a 1G Jbox;
about 1x2x1").  Granted, you still have to design/fab something that
*interfaces* that OTS solution to your particular needs.  But,
unless you're really pinching pennies, you're probably better served
letting someone else deal with the "more demanding" parts of the
layout.

E.g., I have rearranged my system's design so it relies on a SINGLE
*truly* high performance node (database server).  It's simply not
economical for me to try to design a piece of hardware that can
run at that sort of performance level, disk support, etc.  Even
a low end "PC" will typically outperform what I can build and at
a fraction of the cost.

>>> It's too early to tell how responsive Atmel will be.
>>
>> <frown>  And Ulf seems to have gone missing...
>
> Even you will go missing one day ...

Yup.  My NNTP proxy keeps clamping down on the number of posts that
it "exposes" to me (one of my goals in designing it; also a chance to
explore algorithms for filtering out unwanted mail, phone contacts!
Some of the results have been unexpected -- yet in a pleasant way!).
As a result, I spend far less time with News than I did even 6 mos
ago!  Get older and you have less time to spend on activities that
aren't directly contributing to your own productivity ("Youth wasted
on The Young, etc."  :> )

Hopefully, Ulf's absence is by his *choice* and nothing else...

(sigh)  I'd best get to my first meeting lest I catch an (friendly)
earful about "oversleeping" or somesuch...