New ARM Cortex Microcontroller Product Family from STMicroelectronics

You answered a question I didn't ask.

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.

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.

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

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.

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.

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?

You answered a question I didn't ask.

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.

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.

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

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.

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.

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?

Of course not, nor did I say that.

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.

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

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.

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.

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

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

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.

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.

The top level of the FIFO is a pipeline register.

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

meddelandetnews: snipped-for-privacy@k79g2000hse.googlegroups.com...

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.

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.

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

You can't, because it is not faster to have single cycle access if your MHz is low. We ARE comparing a 50 MHz chip to a 66 MHz chip.

If we assume each jump is followed by 4 instructions, then

• it will take 5 clocks @ 50 MHz for the CM3: 50/5 = 10

• It will take 6 clocks @ 66 MHz for the AVR32: 66/6 = 11

The AVR32 is faster, even with 1 waitstate on the first access...

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