On Jul 24, 7:04 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:
> "rickman" <gnu...@gmail.com> skrev i meddelandetnews:1185283098.545264.259220@k79g2000hse.googlegroups.com...
> > Sure, but that does not require a FIFO.  Any processor that fetches 32
> > bits from memory and executes 16 bit instructions will automatically
> > have a 2 instruction queue.  There is not much point extending the
> > FIFO beyond that really.  It is only a small fraction of the time that
> > you will make use of the additional stages.
> > Ulf seems to be mixing the idea of a prefetch FIFO and a pipelined
> > processor.  If the processor is pipelined, you need to have data in
> > each stage or there is a stall.
> > The point of a FIFO is that it can
> > hold a *variable* number of data elements.  Combining them means you
> > either have stalls anytime the FIFO does not have enough data or that
> > the FIFO has to stay full.
>
> The parts I have been looking at,  have a FIFO in stage 1,
> and fixed pipeline registers in stage 2 and 3.
> The top level of the FIFO is the pipeline register for stage 1.
> This  is more efficient than not having a FIFO in stage 1 (like the ARM7)

I have trouble telling just what you are talking about sometimes as
you seem to wander off to discuss other things.  I know that at one
point you said the FIFO was involved in multiple stages of the
pipeline.

> The prefetch FIFO in the CPU cores I have looked at are typically 8-16
> bytes.
> The ideal length of the FIFO is application dependent.
> If you for some reason have few jumps (maybe due to inlining) and lots
> of data, then a long prefetch FIFO is beneficial.

But that was not the original topic.  The original topic was the
relative merits of having single cycle access to Flash (program)
memory.  You had said that it was not as fast as using a FIFO and I
have been trying to dispute that since.  You have been talking about a
lot of irrelevant topics since.


> >  Either way you gained nothing from the
> > combination of the two.  You really need to keep them separate and
> > have pipeline registers which are kept full as much as possible
>
> The top level of the FIFO is a pipeline register.
>
> > (else you get a stall) and a small FIFO (one or two memory words) for the
> > prefetch.  Regardless, every time you hit a branch both the FIFO and
> > the pipeline must be emptied, so the FIFO should have the lowest
> > priority (relative to data fetches) to avoid wasted memory bandwidth.
> > Increasing the size of the FIFO just wastes memory bandwidth without
> > reducing the likelihood of a pipeline stall.
>
> Unless you support delayed loading.
> A CPU with this feature can reorder the execution of the load
> and it is enforced only when the register to be loaded is actually used.
> If you are far away from its actual use, then it may makes more sense
> to do the load later.
> A write FIFO also lets you increase the priority of the prefetch FIFO.

So do *any* of the processors we are talking about have "delayed
loading" or are you just showing off?

"rickman" <gnuarm@gmail.com> skrev i meddelandet 
news:1185283098.545264.259220@k79g2000hse.googlegroups.com...
> On Jul 24, 4:43 am, Joseph <joseph....@somewhere-in-arm.com> wrote:
>> rickman wrote:
>> >>Nope it isn't, the AVR32 running at 66 MHz will run mostly
>> >>at zero waitstates due to its interleaved flash controller design.
>> >>Each flash access done by the memory controller
>> >>will have 1 waitstate, but since the memory controller can do
>> >>two accesses in parallel, the CPU will only see waitstates
>> >>during jumps, and no waitstates during non jump instructions.
>> >>If you do jumps 20% of the time, then the average number of waitstates 
>> >>is
>> >>0,2.
>> >>On top of that you will be able to perform dataaccesses to the flash
>> >>while eating from the instruction queue wihout any performance penalty.
>>
>> > That is pointless.  It does not matter how large the FIFO is, if you
>> > are pulling data out at a given rate and you can only put data in at
>> > that same rate, as soon as you have to stop instruction reads to do a
>> > data read, you will not be filling the FIFO as fast as it is being
>> > emptied and performance will suffer.  Run through a simulation and see
>> > if that is not true.  Based on the info you provided, this is the
>> > result.
>>
>> On Cortex-M3 (and possibly AVR32 ? ), many instructions are 16-bit.
>> As a result, the instruction bus (32-bit) fetch upto two instructions
>> each cycle, while most of the time only one instructions is executed per
>> cycle. So it is possible to stall the instruction fetch for a cycle to
>> to fetch data from flash, without seeing any stall at the execution 
>> stage.
>>
>> Joseph
>
> Sure, but that does not require a FIFO.  Any processor that fetches 32
> bits from memory and executes 16 bit instructions will automatically
> have a 2 instruction queue.  There is not much point extending the
> FIFO beyond that really.  It is only a small fraction of the time that
> you will make use of the additional stages.


> Ulf seems to be mixing the idea of a prefetch FIFO and a pipelined
> processor.  If the processor is pipelined, you need to have data in
> each stage or there is a stall.
> The point of a FIFO is that it can
> hold a *variable* number of data elements.  Combining them means you
> either have stalls anytime the FIFO does not have enough data or that
> the FIFO has to stay full.

The parts I have been looking at,  have a FIFO in stage 1,
and fixed pipeline registers in stage 2 and 3.
The top level of the FIFO is the pipeline register for stage 1.
This  is more efficient than not having a FIFO in stage 1 (like the ARM7)

The prefetch FIFO in the CPU cores I have looked at are typically 8-16 
bytes.
The ideal length of the FIFO is application dependent.
If you for some reason have few jumps (maybe due to inlining) and lots
of data, then a long prefetch FIFO is beneficial.

>  Either way you gained nothing from the
> combination of the two.  You really need to keep them separate and
> have pipeline registers which are kept full as much as possible

The top level of the FIFO is a pipeline register.

> (else you get a stall) and a small FIFO (one or two memory words) for the
> prefetch.  Regardless, every time you hit a branch both the FIFO and
> the pipeline must be emptied, so the FIFO should have the lowest
> priority (relative to data fetches) to avoid wasted memory bandwidth.
> Increasing the size of the FIFO just wastes memory bandwidth without
> reducing the likelihood of a pipeline stall.
>
Unless you support delayed loading.
A CPU with this feature can reorder the execution of the load
and it is enforced only when the register to be loaded is actually used.
If you are far away from its actual use, then it may makes more sense
to do the load later.
A write FIFO also lets you increase the priority of the prefetch FIFO.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

On Jul 24, 4:43 am, Joseph <joseph....@somewhere-in-arm.com> wrote:
> rickman wrote:
> >>Nope it isn't, the AVR32 running at 66 MHz will run mostly
> >>at zero waitstates due to its interleaved flash controller design.
> >>Each flash access done by the memory controller
> >>will have 1 waitstate, but since the memory controller can do
> >>two accesses in parallel, the CPU will only see waitstates
> >>during jumps, and no waitstates during non jump instructions.
> >>If you do jumps 20% of the time, then the average number of waitstates is
> >>0,2.
> >>On top of that you will be able to perform dataaccesses to the flash
> >>while eating from the instruction queue wihout any performance penalty.
>
> > That is pointless.  It does not matter how large the FIFO is, if you
> > are pulling data out at a given rate and you can only put data in at
> > that same rate, as soon as you have to stop instruction reads to do a
> > data read, you will not be filling the FIFO as fast as it is being
> > emptied and performance will suffer.  Run through a simulation and see
> > if that is not true.  Based on the info you provided, this is the
> > result.
>
> On Cortex-M3 (and possibly AVR32 ? ), many instructions are 16-bit.
> As a result, the instruction bus (32-bit) fetch upto two instructions
> each cycle, while most of the time only one instructions is executed per
> cycle. So it is possible to stall the instruction fetch for a cycle to
> to fetch data from flash, without seeing any stall at the execution stage.
>
> Joseph

Sure, but that does not require a FIFO.  Any processor that fetches 32
bits from memory and executes 16 bit instructions will automatically
have a 2 instruction queue.  There is not much point extending the
FIFO beyond that really.  It is only a small fraction of the time that
you will make use of the additional stages.

Ulf seems to be mixing the idea of a prefetch FIFO and a pipelined
processor.  If the processor is pipelined, you need to have data in
each stage or there is a stall.  The point of a FIFO is that it can
hold a *variable* number of data elements.  Combining them means you
either have stalls anytime the FIFO does not have enough data or that
the FIFO has to stay full.  Either way you gained nothing from the
combination of the two.  You really need to keep them separate and
have pipeline registers which are kept full as much as possible (else
you get a stall) and a small FIFO (one or two memory words) for the
prefetch.  Regardless, every time you hit a branch both the FIFO and
the pipeline must be emptied, so the FIFO should have the lowest
priority (relative to data fetches) to avoid wasted memory bandwidth.
Increasing the size of the FIFO just wastes memory bandwidth without
reducing the likelihood of a pipeline stall.

> As to the four Ps, price includes the development cost for most
> designs, also including time to market.  If you are accustomed to
> using ARM MCUs (which many, many people are) then using a CM3 is a lot
> less of a ramp than switching to an AVR32.  That is a cold, hard
> fact.  It will affect some of the most important aspects of any
> project, risk and time to market (far above simple technical issues
> such as which one of the bazillion MCUs do I choose)!!!
>

If you are using an AT91, then moving to an AVR32 is easy because
you use the same peripherals.



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

>> Nope it isn't, the AVR32 running at 66 MHz will run mostly
>> at zero waitstates due to its interleaved flash controller design.
>> Each flash access done by the memory controller
>> will have 1 waitstate, but since the memory controller can do
>> two accesses in parallel, the CPU will only see waitstates
>> during jumps, and no waitstates during non jump instructions.
>> If you do jumps 20% of the time, then the average number of waitstates is
>> 0,2.
>> On top of that you will be able to perform dataaccesses to the flash
>> while eating from the instruction queue wihout any performance penalty.
>
> That is pointless.  It does not matter how large the FIFO is, if you
> are pulling data out at a given rate and you can only put data in at
> that same rate, as soon as you have to stop instruction reads to do a
> data read, you will not be filling the FIFO as fast as it is being
> emptied and performance will suffer.  Run through a simulation and see
> if that is not true.  Based on the info you provided, this is the
> result.

The AVR32 uC3000 series running at 66 MHz from a dual bank
33 MHz memory will read instructions from the flash faster than the 
execution
unit consumes the instruction in the queue.
Best case is if we assume that the CPU is only executing 16 bit instructions
and fetching 32 bit instructions. Then the CPU fetches (except for the 1st 
cycle
where you get hit by the waitstate) 2 instructions per cycle.

>> The ARM9 will fit almost any sockets where the user require an external 
>> bus.
>
> So you are agreeing with me that the ARM9 is not a good match for most
> ARM7 or CM3 designs?  The ARM9 may "fit" the design, but it will not
> be as good a fit if the ARM7 or CM3 can do the job.  If nothing else,
> the cost and power consumption will be higher with the ARM9.  In most
> cases the package size will be larger for the ARM9.  Why use a shotgun
> when a slingshot will do the job?
>

No, a large part of the ARM designs I see (~50%) , need an external bus
and then the ARM9 is likely to be a better choice than an ARM7.
If we look at volume, then the volume of ARM9 is higher than the volume
of ARM7 in my project list, since we have a large portion of Embedded Linux.

>> > What processor only uses 3 clock instructions to access 1 clock
>> > memory?  My understanding is that many processors not only use faster
>> > instructions to load, but can use memory in other instructions which
>> > allow single cycle back to back memory accesses.
>>
>> The simple three stage pipeline processors (and the CM3) normally use a 
>> few
>> clocks
>> in the execution stage to load data, but the uC3 family does not.
>
> Ok, I have to assume that you don't have any examples.  Regardless,
> this seems like a red herring in this discussion anyway.
>

There are plenty of examples.
I would be surprised if you found a lot of processors where loads/stores
execute in one clock cycle.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

rickman wrote:

>>Nope it isn't, the AVR32 running at 66 MHz will run mostly
>>at zero waitstates due to its interleaved flash controller design.
>>Each flash access done by the memory controller
>>will have 1 waitstate, but since the memory controller can do
>>two accesses in parallel, the CPU will only see waitstates
>>during jumps, and no waitstates during non jump instructions.
>>If you do jumps 20% of the time, then the average number of waitstates is
>>0,2.
>>On top of that you will be able to perform dataaccesses to the flash
>>while eating from the instruction queue wihout any performance penalty.
> 
> 
> That is pointless.  It does not matter how large the FIFO is, if you
> are pulling data out at a given rate and you can only put data in at
> that same rate, as soon as you have to stop instruction reads to do a
> data read, you will not be filling the FIFO as fast as it is being
> emptied and performance will suffer.  Run through a simulation and see
> if that is not true.  Based on the info you provided, this is the
> result.
> 
> 

On Cortex-M3 (and possibly AVR32 ? ), many instructions are 16-bit.
As a result, the instruction bus (32-bit) fetch upto two instructions 
each cycle, while most of the time only one instructions is executed per 
cycle. So it is possible to stall the instruction fetch for a cycle to 
to fetch data from flash, without seeing any stall at the execution stage.

Joseph

rickman wrote:

> On Jul 23, 5:14 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>I see you had much to say about the statistically insignificant FpSLIC,
>>but had no replies for my comments that NXP has Licensed Cortex A8, but
>>not bothered with the M3 (A decision I can well understand), nor
>>any comment on the non-usability of the new ST M3 to my app.
>>Having the M3 core was sadly of no use (either plus or minus), when they
>>chose to make USB and CAN mutually exclusive. That killed it stone dead,
>>off the list entirely. Perhaps they will fix that in a new revision ?
>>
>>Those 4P's again : Peripherals, Power, Package & Price
> 
> 
> I don't believe there is anything about the CM3 core that excludes the
> use of USB and CAN at the same time. 

Of course not, nor did I say that.

> This peripheral design also does
> not exclude the ST CM3 chips from every design or likely even many
> designs.  I have never done a design with CAN and will likely never do
> one.  If a chip has CAN capability, I will simply ignore that and
> consider the device on relevant merits to the application.  You seem
> to be very hung up on this combination of USB and CAN.

  Err, 'very hung up' because we had an App that NEEDED both !?
Hard to ignore the design spec - a classic 'deal breaker'.

  The point this underlines very well, is just how (ir)relevant the Core 
can be : in many design decisions, other factors can so easily dominate.

> As to the four Ps, price includes the development cost for most
> designs, also including time to market.  If you are accustomed to
> using ARM MCUs (which many, many people are) then using a CM3 is a lot
> less of a ramp than switching to an AVR32.  That is a cold, hard
> fact.  It will affect some of the most important aspects of any
> project, risk and time to market (far above simple technical issues
> such as which one of the bazillion MCUs do I choose)!!!
> 
> If you think the 4 Ps outweigh program issues, I would hate to be your
> program manager.  Or maybe you work a lot of late nights?

  I have not used an AVR32 yet (they are still relatively new).
We may have an app for the 'C' version, so we will track that.

  On your point of 'jumping cores' : I did do a design in the Zilog 
Z16F, which was surprisingly painless. This included C, and Assembler.
C code is highly portable, and Core agnostic, but with the good
simulator Zilog have for free, and their Free compiler, we
were able to also get the ASM code operational quickly.
  A couple of minor bugs in the tools, but no show-stoppers.
[ In this instance, ARM/M3 were off the list, because we needed
fast 64 bit operand scaling. ]

Development cost, and time, I'd tag here as both "minimal".
I even used the time efficently : I got my Son & Daughter
to ramp their maths skills, checking the operations :)

  Zilog did buy a Compiler company a while ago, so that's a factor
in why they had an edge here. A benefit of all under one roof, is you 
miss the fall-between-stools / not-invented-here problems.
  I have not used Freescale's sw, but I'd expect this to apply to them
as well : same history & structure.
We may yet look at their Coldfire V1 (also new).

  I see Simulate/Debug tools becoming more important in device 
selection. Everything 32 bit has a C compiler (which insulates the 
core), so it is the ease with which you can TRY a device, that becomes 
important.

  The ideal SW target here I see, is to have an IDE/Debug shell, that 
defaults to Simulate mode when no target is found, and ICE when a target 
is there. (ie operationally, Sim and ICE are the same.)
  Also tolerable is the Silabs offering, which has very cleap HW, so
there is almost no cost impact in running as a "HW based Simulator"

-jg

On Jul 23, 5:14 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> rickman wrote:
> > On Jul 16, 5:30 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>rickman wrote:
> >>>>>Look at what happened to Atmel programmable
> >>>>>logic.  When was the last time they added a new FPGA to the product
> >>>>>line?
>
> >>Atmel are adding new CPLDs, (but their FPGAs are in stable design mode).
> >>They have the new CAP series, with ARM7 and ARM9.
> >>The new family looks well placed, to pick up 'Cost Down Design Passes'
> >>on products that started commercial life in FPGAs, but as volume
> >>(and competition) ramps, they need more efficent silicon.
>
> > Now you are going off into left field.  My point was to compare the
> > single source AVR32 to other single source products such as the FPSLIC
> > which has failed in the market and will leave someone high and dry
> > when it is discontinued.  You bring an ASIC into the discussion as if
> > it were somehow relevant.  What was your point???
>
> Hmm, you asked a question, and I simply answered it.

You answered a question I didn't ask.

> You do have 'show quoted text' enabled, and can see your own
> question ?

Is this a real question.  If you think I don't know what I wrote,
please review it yourself.  You will see I said *nothing* about
programmable logic in the very general case, I asked about FPGAs which
is what the Atmel has abandoned in all forms including the FPSLIC.
Abaondoned in the sense of no new introductions to keep the product
line current and useful.

> The CAP7/CAP9 is relevant for three reasons :
> Clearly, it IS Atmel programmable Logic (so is a direct reply to your
> question)!
> Also, it will chase medium-volume business that presently
> uses ARMxx, and an FPGA; design win count will not be 1000's,
> but the revenue potential is much higher per design win.

It may be programmable logic, but it is not *field* programmable which
is what the FPSLIC is and what I asked about.  The CAP is an ASIC,
programmed at the factory.

> Thirdly, I've not seen the M3 available at all in such a medium-volume
> ASIC offering framework.
> So, it will clearly be quite a while before
> M3 can even start to crawl in that market space! ;)

So what is your point?  You just seem to like bashing the CM3 at any
turn for any reason.  I don't think I have seen a CM3 in automotive
temp range either... or in DIP packaging... or in gallium arsenide.
How is that relevant to anything we were discussing???

> I am sure Ulf is seeing customers start designs now,
> with CAP7/CAP9 on the long term Horizon.

Great, but it is a new product and nothing like the Atmel FPGAs or
FPSLICs that have been dropped because they were not viable in the
market.

> It makes good sense, if you are doing any 32 bit MCU/FPGA
> design with volume prospects, to at least target
> an intercept point with the CAP family.
> If you never get that large,
> it has cost little, but if you do, it looks very good indeed.
> So, it will influence more design-pathways.
>
> Once they have this flow working, Atmel could add an AVR32
> variant relatively easily. All it would need is one 'seed'
> customer.
>
> I see you had much to say about the statistically insignificant FpSLIC,
> but had no replies for my comments that NXP has Licensed Cortex A8, but
> not bothered with the M3 (A decision I can well understand), nor
> any comment on the non-usability of the new ST M3 to my app.

Now we are getting somewhere!!! That the FPSLIC was insignificant is
exactly my point.  It was introduced as a new product, pushed into as
many new designs as Atmel could sell into and when it didn't get the
volumes needed to be a viable product line it was abandoned for any
new designs.  Now you have to drop all the tools you used (assuming
you adopted this device) forget all the training and find entirely new
products to do the next job.  Don't even think about trying to
maintain the old designs with updates unless you keep someone on your
staff that is the "go to" guy for that project.

> Having the M3 core was sadly of no use (either plus or minus), when they
> chose to make USB and CAN mutually exclusive. That killed it stone dead,
> off the list entirely. Perhaps they will fix that in a new revision ?
>
> Those 4P's again : Peripherals, Power, Package & Price

I don't believe there is anything about the CM3 core that excludes the
use of USB and CAN at the same time.  This peripheral design also does
not exclude the ST CM3 chips from every design or likely even many
designs.  I have never done a design with CAN and will likely never do
one.  If a chip has CAN capability, I will simply ignore that and
consider the device on relevant merits to the application.  You seem
to be very hung up on this combination of USB and CAN.

As to the four Ps, price includes the development cost for most
designs, also including time to market.  If you are accustomed to
using ARM MCUs (which many, many people are) then using a CM3 is a lot
less of a ramp than switching to an AVR32.  That is a cold, hard
fact.  It will affect some of the most important aspects of any
project, risk and time to market (far above simple technical issues
such as which one of the bazillion MCUs do I choose)!!!

If you think the 4 Ps outweigh program issues, I would hate to be your
program manager.  Or maybe you work a lot of late nights?

On Jul 23, 5:14 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> rickman wrote:
> > On Jul 16, 5:30 pm, Jim Granville <no.s...@designtools.maps.co.nz>
> > wrote:
>
> >>rickman wrote:
> >>>>>Look at what happened to Atmel programmable
> >>>>>logic.  When was the last time they added a new FPGA to the product
> >>>>>line?
>
> >>Atmel are adding new CPLDs, (but their FPGAs are in stable design mode).
> >>They have the new CAP series, with ARM7 and ARM9.
> >>The new family looks well placed, to pick up 'Cost Down Design Passes'
> >>on products that started commercial life in FPGAs, but as volume
> >>(and competition) ramps, they need more efficent silicon.
>
> > Now you are going off into left field.  My point was to compare the
> > single source AVR32 to other single source products such as the FPSLIC
> > which has failed in the market and will leave someone high and dry
> > when it is discontinued.  You bring an ASIC into the discussion as if
> > it were somehow relevant.  What was your point???
>
> Hmm, you asked a question, and I simply answered it.

You answered a question I didn't ask.

> You do have 'show quoted text' enabled, and can see your own
> question ?

Is this a real question.  If you think I don't know what I wrote,
please review it yourself.  You will see I said *nothing* about
programmable logic in the very general case, I asked about FPGAs which
is what the Atmel has abandoned in all forms including the FPSLIC.
Abaondoned in the sense of no new introductions to keep the product
line current and useful.

> The CAP7/CAP9 is relevant for three reasons :
> Clearly, it IS Atmel programmable Logic (so is a direct reply to your
> question)!
> Also, it will chase medium-volume business that presently
> uses ARMxx, and an FPGA; design win count will not be 1000's,
> but the revenue potential is much higher per design win.

It may be programmable logic, but it is not *field* programmable which
is what the FPSLIC is and what I asked about.  The CAP is an ASIC,
programmed at the factory.

> Thirdly, I've not seen the M3 available at all in such a medium-volume
> ASIC offering framework.
> So, it will clearly be quite a while before
> M3 can even start to crawl in that market space! ;)

So what is your point?  You just seem to like bashing the CM3 at any
turn for any reason.  I don't think I have seen a CM3 in automotive
temp range either... or in DIP packaging... or in gallium arsenide.
How is that relevant to anything we were discussing???

> I am sure Ulf is seeing customers start designs now,
> with CAP7/CAP9 on the long term Horizon.

Great, but it is a new product and nothing like the Atmel FPGAs or
FPSLICs that have been dropped because they were not viable in the
market.

> It makes good sense, if you are doing any 32 bit MCU/FPGA
> design with volume prospects, to at least target
> an intercept point with the CAP family.
> If you never get that large,
> it has cost little, but if you do, it looks very good indeed.
> So, it will influence more design-pathways.
>
> Once they have this flow working, Atmel could add an AVR32
> variant relatively easily. All it would need is one 'seed'
> customer.
>
> I see you had much to say about the statistically insignificant FpSLIC,
> but had no replies for my comments that NXP has Licensed Cortex A8, but
> not bothered with the M3 (A decision I can well understand), nor
> any comment on the non-usability of the new ST M3 to my app.

Now we are getting somewhere!!! That the FPSLIC was insignificant is
exactly my point.  It was introduced as a new product, pushed into as
many new designs as Atmel could sell into and when it didn't get the
volumes needed to be a viable product line it was abandoned for any
new designs.  Now you have to drop all the tools you used (assuming
you adopted this device) forget all the training and find entirely new
products to do the next job.  Don't even think about trying to
maintain the old designs with updates unless you keep someone on your
staff that is the "go to" guy for that project.

> Having the M3 core was sadly of no use (either plus or minus), when they
> chose to make USB and CAN mutually exclusive. That killed it stone dead,
> off the list entirely. Perhaps they will fix that in a new revision ?
>
> Those 4P's again : Peripherals, Power, Package & Price

I don't believe there is anything about the CM3 core that excludes the
use of USB and CAN at the same time.  This peripheral design also does
not exclude the ST CM3 chips from every design or likely even many
designs.  I have never done a design with CAN and will likely never do
one.  If a chip has CAN capability, I will simply ignore that and
consider the device on relevant merits to the application.  You seem
to be very hung up on this combination of USB and CAN.

As to the four Ps, price includes the development cost for most
designs, also including time to market.  If you are accustomed to
using ARM MCUs (which many, many people are) then using a CM3 is a lot
less of a ramp than switching to an AVR32.  That is a cold, hard
fact.  It will affect some of the most important aspects of any
project, risk and time to market (far above simple technical issues
such as which one of the bazillion MCUs do I choose)!!!

If you think the 4 Ps outweigh program issues, I would hate to be your
program manager.  Or maybe you work a lot of late nights?