Luminary Micro

Power requirements are too high, otherwise I would consider them.

No external BUS ability ?

You might find that GNU is compiler only. I have not seen comments on debug and simulator support ?

So far, I have not seen independant benchmarks, but the peripherals are slow. Only ARM seem to believe this is a 'hot new thing', worthy of the effort of change. (but of course, they have to say that..)

Good, just make sure you add a note that the C3M core is not _binary_ compatible with ARM7, (somewhat like the Z80 and 8080)- so you _will_ need new tool chains: Compilers/Libraries/Linkers/Debug/Simulator.

So, right now, this is single sourced & green : Given that, that's the same selection category as Zilog ZNEO, and Freescale Coldfire V1.

Then you think : Who has the most peripheral experience of Luminary, Zilog, Freescale ?

A common problem with 32 bit ARM cores, is they are not easy to speed-calculate. There is a large hole of information, between the ARM manuals, and the vendors user manuals. So, you pretty much have to get one up and running, before you find out just how fast/slow they really are at code details.

-jg

I've heard the power requirements will be eased in the final parts that go into mass production.

Down the road they'll definitely use a smaller process, but I don't know what the time table is for that.

Eric

CodeSourcery has provided a gdb driver, and Luminary makes a Debug Library available in source form to anyone who agrees to non-disclosure of the proprietary details.

True, but only the 8051 is not single-sourced these days. You can't replace Arm7 chips with parts from another maker, and not even the C source code will be completely portable between Arm7 chips of different makers.

Luminary licensed the peripheral support from a more experienced firm in this first set of chips so they could introduce a more mature set of support peripherals in a new chip.

The biggest thing I like right now is Luminary's free library source code. This is really non-trivial and better than any other offerings by Arm7 makers. It's far better than the library source offered by ST Micro.

Also, Luminary's tech support has been beyond belief. I've never had that kind of attention to my queries from any other maker. Philips was a favorite of mine until I tried dealing with their tech support. I'm a small player in this business and Philips really doesn't see small players on their radar screen at all. Half of the time they didn't answer my support requests at all, and the other half of the time I got back inappropriate form-letter style email responses that didn't address my questions.

Luminary is a small company that really cares. That carries some weight with me.

By the way, I understand that ST Micro also licensed the Cortex M3 core, but they haven't announced any specific chips yet. I was told there were 5 licensees at the time I asked several months ago, but only ST and Luminary were mentioned by name.

I'm more than a little confused by ST lately. They seem to be expanding in many directions at once. I hope they're not over-extending themselves.

Eric

That would be nice, but it seems that from the time of introduction of a new core to production units seems to always require a measurement unit of years, except for the Intel 4004, I think that was 6 months, and that was from a memory company :)

I just had a telecon with LM personel and specifically mentioned that their parts had nothing on the ARM7 competition when it came to power, most likely because they were still at 0.25 um while everyone else was doing 0.18 or finer. Asking if they had future plans for power reduction they offered nothing. They only talked about parts with more memory.

The two important aspects in our designs is size and power. They are in a good package, the TQFP48, but they are definitely not there on power. They also don't do any better on price although that is always negotiable. They made it very clear that price would not be an issue.

Keep in mind that as these things shrink, static Icc can climb markedly. So finer devices are not always lower power. (FPGAs are a good example)

I also see their Icc spec mentions SRAM execution and does not specify FLASH Icc ( which is often higher ) Remember Scenix, they got fast flash specs, but at the cost of very high Icc values.

Could you use two processors, a smaller, more frugal one to wake up the more powerful one, when needed ?

-jg

Hmmm. They buy the core from ARM, and the peripherals from someone else :( - that suggests the errata will be a long time being resolved ? Some of the errata sound fundamental.

yes, that's a plus.

CM3 makes sense in an ASIC, but is a harder sell into the merchant uC market, where you a buying a lot more than just the core. ( see rickman's comments on the Icc )

Yes, they have lots of cores!. All the 8 bit ones, ARM7, ARM9, and their newest ST10 devices are quite powerful, if not super-cheap. There was talk of an ARM uPSD as well !

-jg

Crossworks supports it with their debugger and simulator. I haven't tried them, though.

Leon

I have used all the available tools. CrossWorks tools work nicely:

as in fact do the Keil, GCC and IAR tools.

Regards, Richard.

• formatting link

• formatting link
  for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *

The high static Icc is a feature of some 4 or 5 generations beyond the

0.25 um they are using. I think you will find that core voltages of 1.8 and even 1.5 still allow low static currents with modern processing. The person I spoke to referred to their process as "mature" as if that was automatically a good thing. There is a reason why we keep moving ahead with processing. Likely they work with 0.25 um because it gives them a lower startup cost to get their first 20 devices out the door. I would like to see a plan for moving forward with 0.18 or even 0.15 um to reduce the cost and power. But they indicated all the currently planed devices will also be 0.25 um.

See the first consideration, size? Besides, I can get lower power ARM devices and the speed advantage of the LM parts is not that clear.

Where do you get this stuff??? How does using third party peripherals equate to errata? For any number of companies I would prefer that they get third party peripherals... besides, there are more parts of the MCU that are from ARM on the Cortex M3. The interrupt controller is one and I don't recall the others, but it may include the IO ports. It also includes a MPU. The UART is a standard 16550 which has TONS of code base around. These common peripherals alone are a big boost to porting your code between ARM vendors once the Cortex M3 is more common.

If the power issue is dealt with by the other vendors the Cortex M3 may be the next 8051. The ARM7 is called the 32 bit equivalent to the

8051, but the Cortex M3 may actually replace it in all but the lowest cost apps! Now, if someone would make an FPGA with a hard Cortex M3 core, I would be in heaven. I could use that in so many places.

I don't see why you make this claim. The Icc of the Luminary devices has to do with the implementation that is at least one generation behind the rest of the field. If they used a more current technology (which the other vendors certainly will when they produce product) the current consumption would likely beat anything on the market. Maybe I should have said "a LESS 'current' technology" ;^)

That does not bother me. If they are making chips that compete internally with their ARM cores, I feel that provides the highest level of competition. Competition is what makes a group push their designs and make real progress.

My comment related to the time to resolve the errata, not the errata themselves.

When they buy from 3rd parties, first they have to 'discuss' who pays for the mistakes, then assuming that is settled, they have to go into the queue to be fixed.....

A look at the errata on the S815, has some eyebrow raising ones :

Two involved Debug port lockup - hmm, I thought this was all from ARM ?

One involves poor ADC noise : classic cut & paste errata, that one.

A 0% operation on temperature sensor ?

LDO aspects also look rather untested, but their LDO is ambitious.

All the same, Freescale and SiLabs can get much lower power, on similar processes.

-jg

That is an assumption that the peripheral core is new. The peripherals are often things that are existing, well debugged designs such as the

16550 UART. In fact that is a good reason for using third party IP, that other customers have debugged it for you. You can speculate, but do you have any basis for your claim?

I have never seen an new chip that did not have errata the first time out of the shoot. I don't see how any of this supports your contention that their designs will be more buggy than normal because of the third party peripherals. I remember some very notable failures by very experienced companies such as TI. There was more than one product that never made it to market because of the year long delay getting the TMS320C50xx core onto a general chip rather than the custom chips in cell phones. Do you think that was due to third party peripherals?

Or how about the errata with the Atmel SAM7 parts so that the quiescent current goes up dramatically if you try to use the JTAG interface? I'm not so familiar with the Philips or Freescale ARM chips so I don't know what problems they had coming out of the shoot.

Design problems are par for the course. If anything these chips will have problems because they are brand new, not because of the source of their IP.

The shoot? Your spell checker run amok? ;)

More on point. The Philips parts seem to have a problem with race conditions. A lot of the errata appear as if they were race conditions of one form or another.

Robert

Again, I did not claim their designs are more buggy, per se, but commented on the time to resolve those bugs.

If you want an example of the perils of "cut and paste" design, just look at the ADC specs in the errata. Or the high Idle Icc....

Let's see how long to takes to clear all those errata, from the B5 silicon ?

I recall an 80C51 variant some years back, that pasted in a nice 32Khz cell, and yes, they got a low uA Oscillator. Problem was, they followed it with a HCMOS grade buffer, and so the non square wave icc was much higher : The cut and paste operator, did not realise the linear Icc of the buffer was very important as well.

Their 6.1 errata sounds broadly similar, tho I suspect some workarounds could be found, even tho they say 'none' (depends on the precise fault location). We did manage to discover a couple of work-arounds for that 80C51 Osc oops.

Of course all devices have errata, and I have also seen some real clangers from companies that should have known better.

-jg

Actually, it is understood that the Philips LPC2xxx parts have a problem with race conditions on the ARM High Speed Bus (AHB), which is used to communicate with many peripherals; the problems are with the (ARM- designed) bus, not with the Philips peripherals.

--Gene

The bus or the interface between the bus and Philips peripherals? I would have thought the latter.

Robert

Funny you mention that. Atmel has simlar errata on their SAM7 parts that has been in place for a year or so with no fix in sight. I counted 27 errata on the SAM7S64 device. Obviously, long standing errata is not an uncommon thing.

I just don't see your point. You are saying that because they might have to communicate with a different company (who will be getting the same complaints from other customers) rather than a different department, there will be a noticable delay in a fix to the errata? I just don't see this as significant. All the chip vendors fix problems based on a priority of how it affects their customers (and by that I mean their *major* customers). If they need for it to be fixed, it will get fixed. If not, the huge cost of respinning the chip will make a much larger impact than the delay in negotiating with a vendor.

Yes, now you get it!