Getting started with ARM processors - recommendations

Hi there,

I have been using 8/16 micros for a number of years and am finding the need
to step up to 32 bit processing.  I am tempted to jump into the use of
microchips 32bit processors, but based on extremely the poor technical
support I have received in the past I am thinking about moving over to an
ARM product. Another for moving to ARM is that I will also likely start
using the Actel lower power FPGAs, which some have a built in ARM hard -
Core.

Based on our use of mostly low power applications and the mid level
performance needed, it sounds like ARM7 would be a good fit?  The actel
FPGA that we will also migrate to offers Cortex M1,M3.  

1. Are there discrete Cortex M1, M3 processors available?  

2. What vendors would you most highly recommend?  I would like to get in
with somebody who is reputable for support and low count - part
availability.  I also would like to start with something that is widely
used, so that I can easily access code to test and learn with. It looks
like Ateml, NXP, freescale may be options?

3. Are there other aspects I should be looking into? 

4. Would anyone recommend biting the bullet and staying with microchip, as
I have the tools already? It sounds like the PIC32 has a decent M4K MIPS32
Core.

5. Anything else I should be considering?

TIA	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Mon, 25 Oct 2010 14:25:35 -0500, "fvnktion"
<fvnktionforums@n_o_s_p_a_m.yahoo.com> wrote:

>Hi there,
>
>I have been using 8/16 micros for a number of years and am finding the need
>to step up to 32 bit processing.  I am tempted to jump into the use of
>microchips 32bit processors, but based on extremely the poor technical
>support I have received in the past I am thinking about moving over to an
>ARM product. Another for moving to ARM is that I will also likely start
>using the Actel lower power FPGAs, which some have a built in ARM hard -
>Core.
>
>Based on our use of mostly low power applications and the mid level
>performance needed, it sounds like ARM7 would be a good fit?  The actel
>FPGA that we will also migrate to offers Cortex M1,M3.  
>
>1. Are there discrete Cortex M1, M3 processors available? 

Yes. 

>2. What vendors would you most highly recommend?  I would like to get in
>with somebody who is reputable for support and low count - part
>availability.  I also would like to start with something that is widely
>used, so that I can easily access code to test and learn with. It looks
>like Ateml, NXP, freescale may be options?

I've been happy with NXP. Your mileage may vary, of course. One thing
you may want to do is to look at what dev boards are available for the
various chips, at the usual places. See what Digikey et al. carry as
well as http://www.sparkfun.com/commerce/categories.php?c=2 (drill down
to the specific vendors) and
http://microcontrollershop.com/default.php?cPath=154_170 (drill down for
specific cores).

>3. Are there other aspects I should be looking into? 

Compilers, development environments, JTAG adapters. I've been using
Imagecraft's ARM tools with the NoICE debugger. Rowley CrossWorks is
another option, as well as the usual gcc releases and the compilers from
The Big Boys.

>4. Would anyone recommend biting the bullet and staying with microchip, as
>I have the tools already? It sounds like the PIC32 has a decent M4K MIPS32
>Core.

I got turned off PICs after having to force world+dog through that one
damned W register. Found life was much more pleasant over in the AVR
world and downright cheerful in the ARM universe.

>5. Anything else I should be considering?

One thing that Microchip offers that few others still do is ROM-based
vice flash-based processors. One-time programmable ROMs have a longer
expectancy than flash and are reasonably well protected alteration.

-- 
Rich Webb     Norfolk, VA

I'd recommend getting one of the very affordable SM32 eval kits from ST. 
The upside is they have good affordable parts (and kits).  The downside is 
good dev SW is kinda pricey but well worth the price if you're a pro.  I use 
IAR EWB but I'm sure you can use less expensive tools maybe even some 
supposedly free tools.

JJS

"fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com> wrote in message 
news:U4GdnZxiJJQyRFjRnZ2dnUVZ_g-dnZ2d@giganews.com...
> Hi there,
>
> I have been using 8/16 micros for a number of years and am finding the 
> need
> to step up to 32 bit processing.  I am tempted to jump into the use of
> microchips 32bit processors, but based on extremely the poor technical
> support I have received in the past I am thinking about moving over to an
> ARM product. Another for moving to ARM is that I will also likely start
> using the Actel lower power FPGAs, which some have a built in ARM hard -
> Core.
>
> Based on our use of mostly low power applications and the mid level
> performance needed, it sounds like ARM7 would be a good fit?  The actel
> FPGA that we will also migrate to offers Cortex M1,M3.
>
> 1. Are there discrete Cortex M1, M3 processors available?
>
> 2. What vendors would you most highly recommend?  I would like to get in
> with somebody who is reputable for support and low count - part
> availability.  I also would like to start with something that is widely
> used, so that I can easily access code to test and learn with. It looks
> like Ateml, NXP, freescale may be options?
>
> 3. Are there other aspects I should be looking into?
>
> 4. Would anyone recommend biting the bullet and staying with microchip, as
> I have the tools already? It sounds like the PIC32 has a decent M4K MIPS32
> Core.
>
> 5. Anything else I should be considering?
>
> TIA
>
> --------------------------------------- 
> Posted through http://www.EmbeddedRelated.com 

On Mon, 25 Oct 2010 14:25:35 -0500, "fvnktion"
<fvnktionforums@n_o_s_p_a_m.yahoo.com> wrote:

>I have been using 8/16 micros for a number of years and am finding the need
>to step up to 32 bit processing.  I am tempted to jump into the use of
>microchips 32bit processors, but based on extremely the poor technical
>support I have received in the past I am thinking about moving over to an
>ARM product.

I have only had very good experiences with Microchip support,
but there may be an entirely different reason for ARM to
consider.  Once you have invested in the toolset (and by this
I mean invested time _and_ money _and_ tools _and_ operating
environment and everything else that in some fashion diverts
needed energy away from the product focus ahead of you), you
aren't nearly so tied to one manufacturer as you might be
with single sources.  Yes, the boards may need a redesign if
you shift.  Yes, the peripherals may be different.  Yes, the
initialization code will have to be changed, too.  But you
will do all that without (usually) having to relearn how to
properly use the compiler tools and so on.  So you get to
preserve at least _some_ of your prior investment should it
come to pass that you feel a strong need to once again choose
a different manufacturer or product line.

It seems that way to me, anyway.  So it's not a bad way to
go.

>Another for moving to ARM is that I will also likely start
>using the Actel lower power FPGAs, which some have a built in ARM hard -
>Core.
>
>Based on our use of mostly low power applications and the mid level
>performance needed, it sounds like ARM7 would be a good fit?  The actel
>FPGA that we will also migrate to offers Cortex M1,M3.  

Your definition of "mostly low power" may be different than
mine.  1-10 milliWatt average is more like it.  Does Actel
make FPGAs anywhere near there?

>1. Are there discrete Cortex M1, M3 processors available?  
>
>2. What vendors would you most highly recommend?  I would like to get in
>with somebody who is reputable for support and low count - part
>availability.  I also would like to start with something that is widely
>used, so that I can easily access code to test and learn with. It looks
>like Ateml, NXP, freescale may be options?
>
>3. Are there other aspects I should be looking into? 
>
>4. Would anyone recommend biting the bullet and staying with microchip, as
>I have the tools already? It sounds like the PIC32 has a decent M4K MIPS32
>Core.

You wrote that you've had "extremely poor technical support."
I don't know why.  It's not my experience.  Poor support is a
totality thing, though, and that can be caused by reality
(the vendor really is poor at it) or by a customer's (you)
attitude.  But assuming you aren't a "customer from hell" for
now and that it is the reality:

I consider good support pretty important.  And if you have
had very poor experiences with Microchip and have enough
experience with them to know that you can't uncover the
problem and make it get better, then you should definitely
look elsewhere until you find that positive support from
another company.

By the way, when you do decide to shift over, write me a
letter if you have any inclination to sell your Microchip
tools.  I have good experiences and wouldn't mind getting
more tools if offered at a very reasonable cost to me.

>5. Anything else I should be considering?

You should look at everything when considering a move.  What
compiler development tools will you use?  (With ARM, you'd be
wise using gcc but that doesn't mean not paying -- as you can
secure excellent libraries, IDEs, support, and so on from
vendors who use gcc but also deal with all the associated and
related issues so that you can focus on the applications with
confidence.)  Will you be using JTAG debugging and, if so,
which tool?  Check out the datasheets and see if you feel
they are complete and readable and make sense.  (I've had the
experience where a cpu I chose [there were no alternatives,
so I was stuck anyway] had incomplete information on the DMA
and it required them spending months tracking down the
original designer [done 8 years beforehand] of that section
to get the answers back.)  Ask yourself how long you expect
to support all this, as well, and whether or not the company
you choose has the kind of past behavior that matches your
need here well.  That goes not only for the chip itself, but
the compiler vendor and JTAG tool and whatever else you will
add to the development infrastructure.

I'm sure others will add many more.

Good luck,
Jon

Thank you for the comprehensive responses.

I see that there are some very nice options from all of the above mentioned
ARM variant suppliers ( AVR, NXP, Freescale, ST).  From what I see most of
them offer the power, peripheral requirements that I would be looking for.
I will have to look further to see what kind of of the shelf availablities
are.  We do a lot of R&D, making high quantity purchases  = NULL. 

One major thing that I have like about using microchip is the pin to pin
compatibility from 16 bit devices MCU's, DSPs and 32 bit MCUs.  As well the
debuggers are cross compatible.  The code libraries are immense and the
forum support has been good.  The only downfall being the separate purchase
of the 32 bit compiler.  The hardware has operated quite well.

" You wrote that you've had "extremely poor technical support."
I don't know why.  It's not my experience.  Poor support is a
totality thing, though, and that can be caused by reality
(the vendor really is poor at it) or by a customer's (you)
attitude.  But assuming you aren't a "customer from hell" for
now and that it is the reality:"

Microchip touts "the best technical support in the industry", but I have
definitely not received it. I have heard from some like yourself, that they
also have received good support.  I do not beleive that it is the vendor's
inability to supply it and I hope that I am not the "customer from hell". 
I have asked a number of newbie questions, as I was quite new to embedded
design and i was in process of getting up the learning curve, and as a
company we don't buy mass quantities or parts( not that they would know
this).  As a company we have been using them for over three years. My last
open case is weeks old with no repsonse, and previous was closed with a
quick guess as to what the problem was.  Most of my support tickets are
resolved with a guess and then closed.  Would someone please let them know
I am really not the "cutomer from hell"  :).  Because of the
proportionately degraging support with time I have been left wondering if
there is something better out there, hardware, support.

"Your definition of "mostly low power" may be different than
mine.  1-10 milliWatt average is more like it.  Does Actel
make FPGAs anywhere near there?" 

The very impressive spec given in data sheet is 4uW is flash freeze( power
down) on igloos devices,  gate configuration and clock speed is the main
driver of power consumption, so active power is dependent on final gate
configuration.  I was quoted that I should be able to get active current in
the range of 100uW, which is very suitable for our battery operating
needs.

The main items that I am left open ended in question are the tool set
options / supplier.  I have been using microchip's IDE with their ICE, ICD
programming/debug tools so I am unfamiliar with the more universal
solutions.  I like the sounds of the approach you mention here in being
able to migrate from mfg to mfg with minimal impact.

"Once you have invested in the toolset (and by this
I mean invested time _and_ money _and_ tools _and_ operating
environment and everything else that in some fashion diverts
needed energy away from the product focus ahead of you), you
aren't nearly so tied to one manufacturer as you might be
with single sources."

6. So what would most univeral toolset solution be?  Already mentioned has
been: ImageCraft, Keil,  I like the sounds of the mention GCC solutions. 
Who offers these solutions?

7. Unlike Microchip, are most other devices programmed debugged through
jtag? What is one of the better jtag hardware devices?  I would like
something that works with FPGA as well, if possible.

Thank you immensely for the advice.












	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

>Thank you for the comprehensive responses.
>
>I see that there are some very nice options from all of the above
mentioned
>ARM variant suppliers ( AVR, NXP, Freescale, ST).  From what I see most
of
>them offer the power, peripheral requirements that I would be looking
for.
>I will have to look further to see what kind of of the shelf
availablities
>are.  We do a lot of R&D, making high quantity purchases  = NULL. 
>
>One major thing that I have like about using microchip is the pin to pin
>compatibility from 16 bit devices MCU's, DSPs and 32 bit MCUs.  As well
the
>debuggers are cross compatible.  The code libraries are immense and the
>forum support has been good.  The only downfall being the separate
purchase
>of the 32 bit compiler.  The hardware has operated quite well.
>
>" You wrote that you've had "extremely poor technical support."
>I don't know why.  It's not my experience.  Poor support is a
>totality thing, though, and that can be caused by reality
>(the vendor really is poor at it) or by a customer's (you)
>attitude.  But assuming you aren't a "customer from hell" for
>now and that it is the reality:"
>
>Microchip touts "the best technical support in the industry", but I have
>definitely not received it. I have heard from some like yourself, that
they
>also have received good support.  I do not beleive that it is the
vendor's
>inability to supply it and I hope that I am not the "customer from hell".

>I have asked a number of newbie questions, as I was quite new to embedded
>design and i was in process of getting up the learning curve, and as a
>company we don't buy mass quantities or parts( not that they would know
>this).  As a company we have been using them for over three years. My
last
>open case is weeks old with no repsonse, and previous was closed with a
>quick guess as to what the problem was.  Most of my support tickets are
>resolved with a guess and then closed.  Would someone please let them
know
>I am really not the "cutomer from hell"  :).  Because of the
>proportionately degraging support with time I have been left wondering if
>there is something better out there, hardware, support.
>
>"Your definition of "mostly low power" may be different than
>mine.  1-10 milliWatt average is more like it.  Does Actel
>make FPGAs anywhere near there?" 
>
>The very impressive spec given in data sheet is 4uW is flash freeze(
power
>down) on igloos devices,  gate configuration and clock speed is the main
>driver of power consumption, so active power is dependent on final gate
>configuration.  I was quoted that I should be able to get active current
in
>the range of 100uW, which is very suitable for our battery operating
>needs.
>
>The main items that I am left open ended in question are the tool set
>options / supplier.  I have been using microchip's IDE with their ICE,
ICD
>programming/debug tools so I am unfamiliar with the more universal
>solutions.  I like the sounds of the approach you mention here in being
>able to migrate from mfg to mfg with minimal impact.
>
>"Once you have invested in the toolset (and by this
>I mean invested time _and_ money _and_ tools _and_ operating
>environment and everything else that in some fashion diverts
>needed energy away from the product focus ahead of you), you
>aren't nearly so tied to one manufacturer as you might be
>with single sources."
>
>6. So what would most univeral toolset solution be?  Already mentioned
has
>been: ImageCraft, Keil,  I like the sounds of the mention GCC solutions. 
>Who offers these solutions?
>
>7. Unlike Microchip, are most other devices programmed debugged through
>jtag? What is one of the better jtag hardware devices?  I would like
>something that works with FPGA as well, if possible.
>
>Thank you immensely for the advice.
>


I had problems with Microchip too. Their PIC32MS460F516L were suposed to
have a UART that can work up to 20Mbps. After designing a prototype to run
some tests i was having some communication problem. After some time i found
out that the problem was with the start-bit timing. It was 33% shorter than
it should be, After that i could find this problem described on a hidden
ERRATA. The problem would happen for baud rates higher than 5Mbps. And the
fantastic workaround was: Do not use it at that boudrate! So far, after 7
months and 3 tickets, i cant get any kind of further information about this
problem, if it has been solved, or if there is any new version with the
problem solved. All the 3 tickets were closed with some stupid and random
aswer as check the baud rate registers. 

I still use microchip uC, but not for important tasks. 

For ARM i would sugest you getting a STM32 b
oard that costs 10 USD. You can hack as much you want with it, and it comes
with a jtag and a ARM Cortex-M3

Cya	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Mon, 25 Oct 2010 17:41:11 -0500, "fvnktion"
<fvnktionforums@n_o_s_p_a_m.yahoo.com> wrote:

>Thank you for the comprehensive responses.
>
>I see that there are some very nice options from all of the above mentioned
>ARM variant suppliers ( AVR, NXP, Freescale, ST).  From what I see most of
>them offer the power, peripheral requirements that I would be looking for.
>I will have to look further to see what kind of of the shelf availablities
>are.  We do a lot of R&D, making high quantity purchases  = NULL. 

For small-quantity work and R&D, I'd push the importance of readily
available dev boards up a notch. You could use something like
http://www.sparkfun.com/commerce/product_info.php?products_id=263
(also available at
<http://microcontrollershop.com/product_info.php?cPath=154_170_267&products_id=643>
pretty much as-is on a breadboard or proto-board.

>One major thing that I have like about using microchip is the pin to pin
>compatibility from 16 bit devices MCU's, DSPs and 32 bit MCUs.

The ARM cores themselves will be (nearly) the same but how the cores
interoperate with on-chip peripherals, what peripherals are present, and
the ultimate pinouts vary widely. The price of choice, I guess.

>As well the debuggers are cross compatible.

Fortunately, they all speak JTAG.

>6. So what would most univeral toolset solution be?  Already mentioned has
>been: ImageCraft, Keil,  I like the sounds of the mention GCC solutions. 
>Who offers these solutions?

Rowley has a commercially-supported gcc with their own libraries,
relieving end-users of LGPL licensing concerns (insofar as there may be
LGPL concerns...). YAGARTO http://www.yagarto.de/ is the "standard"
(AFAIK) fully GPL gcc environment for ARMs.

>7. Unlike Microchip, are most other devices programmed debugged through
>jtag? What is one of the better jtag hardware devices?  I would like
>something that works with FPGA as well, if possible.

Some (many? most?) also support some flavor of bootloader over a serial
port. NXP has an "LPC2000 Flash Utility" for example. As far as JTAG
goes, the standard seems to be the J-Link from Segger. There are less
expensive options (search for "JTAG Wiggler clone").

As far as JTAG interoperation with FPGAs, if you're lucky your
programmer supports "skipping" uninterested devices on the JTAG chain.
Programming isn't going to happen; they all seem to use different
protocols.

-- 
Rich Webb     Norfolk, VA

On 26/10/2010 14:26, Rich Webb wrote:
> On Mon, 25 Oct 2010 17:41:11 -0500, "fvnktion"
> <fvnktionforums@n_o_s_p_a_m.yahoo.com>  wrote:

> The ARM cores themselves will be (nearly) the same but how the cores
> interoperate with on-chip peripherals, what peripherals are present, and
> the ultimate pinouts vary widely. The price of choice, I guess.
>
>> As well the debuggers are cross compatible.
>
> Fortunately, they all speak JTAG.
>

All ARM core devices should speak JTAG, but not all hardware JTAG 
interfaces will talk with the debugger software on the host.  So make 
sure that these match up when picking tools.

>> 6. So what would most univeral toolset solution be?  Already mentioned has
>> been: ImageCraft, Keil,  I like the sounds of the mention GCC solutions.
>> Who offers these solutions?
>
> Rowley has a commercially-supported gcc with their own libraries,
> relieving end-users of LGPL licensing concerns (insofar as there may be
> LGPL concerns...). YAGARTO http://www.yagarto.de/ is the "standard"
> (AFAIK) fully GPL gcc environment for ARMs.
>

Yagarto is very popular, and totally free (AFAIK), but CodeSourcery has 
a better claim to being the "standard".  They are the people that 
actually write the compiler and tools (or at least, they are the 
official maintainers of the ARM port of gcc, and very heavy 
contributors).  They have options ranging from free through cheap and up 
to expensive, depending on your requirements for support, library 
features, etc.

Yagarto, Rowley, Code Red, etc., all get their basic compiler from 
CodeSourcery, and provide their own additional features - support, 
libraries, bundling and integration with an IDE, and so on.

I think that before you choose your toolset, you should pick your main 
chip vendor.  The different vendors will have more or less support for 
different toolchain suppliers.  For example, if you pick TI's Stellaris 
devices, all their application notes, libraries, demos, etc., have 
direct support for IAR, Keil, Code Red and CodeSourcery.  This doesn't 
mean that you can't then use e.g., ImageCraft - but it might be easier 
to get started using one of the vendor-supported toolchains.

The best toolchain for /you/ will depend on your experience, your 
budget, your needs, your particular project, your personal preferences, 
and the needs of other projects (for consistency between different 
processors).  Ignore anyone who tells you you have to spend vast amounts 
of money on IAR or Keil for professional work, or that those tools will 
save you money in the long run.  They /may/ be the best choice for you, 
but equally they may be far more costly in time and effort than cheaper 
or free tools would have been - cost price is never a guarantee of 
quality or time efficiency.  Look at the web sites of the vendors and 
try out evaluation versions of tools that are within your budget and see 
what suits.


>> 7. Unlike Microchip, are most other devices programmed debugged through
>> jtag? What is one of the better jtag hardware devices?  I would like
>> something that works with FPGA as well, if possible.
>

JTAG devices come in two basic forms.  You get simple USB devices, which 
are very often based on an FTDI usb chip - these are typically cheap, 
and work reasonably well but may be slow if you are working with very 
large programs.  The other main type are "intelligent" devices, that 
typically have an Ethernet interface to the host PC.  These will be a 
lot more powerful - they will handle things like watchpoints much more 
efficiently, downloads are faster, they may support tracing, etc.  But 
they cost a lot more.

As for the FPGA, I'd recommend buying a USB Blaster for Altera, or the 
equivalent for other FPGA manufacturers, and using that.  It is 
typically /possible/ to program ARMs and FPGAs on the same JTAG chain, 
but it is almost certainly going to be more effort than it's worth. 
It's a lot easier just to put two separate jtag connectors on the board.



> Some (many? most?) also support some flavor of bootloader over a serial
> port. NXP has an "LPC2000 Flash Utility" for example. As far as JTAG
> goes, the standard seems to be the J-Link from Segger. There are less
> expensive options (search for "JTAG Wiggler clone").
>
> As far as JTAG interoperation with FPGAs, if you're lucky your
> programmer supports "skipping" uninterested devices on the JTAG chain.
> Programming isn't going to happen; they all seem to use different
> protocols.
>

Thank you all for the very informed advice.  This will greatly benefit me
in the transition.  I will likely start working with some of these newer
devices until comfortable and then fully transition away from the microchip
product.  

By the way I just got off the phone with sourcery.  They highly recommended
the TI stellaris cortex M3 famil as they offer very wide support and a very
discounted dicounted G++ package directed for its use.  Interestingly the
Stellaris has not been aforementioned.  It looks like a nice product with
TI support.  I will continue to do further research and try and narrow down
a supplier.    	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

Your initial post mentioned the ARM7.  That is a much older variation
of the ARM architecture and has some significant drawbacks compared to
the Cortex Cx parts.  The CM3 is the first out of the gate and the
most common currently.  The CM0 is the smallest and should be the
lowest power, but that is also a matter of implementation, so check
the data sheets.  The CM1 is a soft core for FPGAs and I only know of
the Actel version which has not caught on from what I can tell.

On Oct 25, 6:41 pm, "fvnktion" <fvnktionforums@n_o_s_p_a_m.yahoo.com>
wrote:
> Thank you for the comprehensive responses.
>
> I see that there are some very nice options from all of the above mentioned
> ARM variant suppliers ( AVR, NXP, Freescale, ST).  From what I see most of
> them offer the power, peripheral requirements that I would be looking for.
> I will have to look further to see what kind of of the shelf availablities
> are.  We do a lot of R&D, making high quantity purchases  = NULL.

Don't forget Atmel, TI and there are some other, newer players.


> One major thing that I have like about using microchip is the pin to pin
> compatibility from 16 bit devices MCU's, DSPs and 32 bit MCUs.  As well the
> debuggers are cross compatible.  The code libraries are immense and the
> forum support has been good.  The only downfall being the separate purchase
> of the 32 bit compiler.  The hardware has operated quite well.

People tout the advantages of the ARM CPU popularity as allowing you
to switch vendors easily, but that is over rated in my book.  It is
still a ton of work to switch because of all the differences, pinout,
peripherals, init code, clocking, etc... That is one really good
reason to pick a vendor with a wide portfolio of CPUs, they will be
much more compatible within the line.


> Because of the
> proportionately degraging support with time I have been left wondering if
> there is something better out there, hardware, support.

I can't say anything about Microchip as I have not worked with their
parts.  With so many alternatives, there has to be good vendors in the
ARM market... or they don't last long in the ARM market.  TI is making
a VERY strong push in the ARM market.  In addition to the CM3 line
from Luminary Micro, they have higher end devices and will be coming
out with a CM4, I believe.


> "Your definition of "mostly low power" may be different than
> mine.  1-10 milliWatt average is more like it.  Does Actel
> make FPGAs anywhere near there?"
>
> The very impressive spec given in data sheet is 4uW is flash freeze( power
> down) on igloos devices,  gate configuration and clock speed is the main
> driver of power consumption, so active power is dependent on final gate
> configuration.  I was quoted that I should be able to get active current in
> the range of 100uW, which is very suitable for our battery operating
> needs.

Don't confused the Igloo parts with the SmartFusion parts.  Igloo has
a few chips which will support the soft core CM1.  I haven't seem much
to indicate these are selling well.  With the CM1 taking up nearly the
entire die in the smallest member of this short line, I expect there
are few designs that are enhanced by this approach.  The SmartFusion
chip has FPGA, CM3 and analog all on one chip... one $40 chip.  These
parts are all much cheaper if bought separately.  They will take up
more room on the board, but your cost will still be lower,
significantly.

If you want to see low power, check out Silicon Blue parts.  They have
very low static current and the dynamic current scales with
frequency.  Even at the same rates, they are lower power than any
other FPGA.


> The main items that I am left open ended in question are the tool set
> options / supplier.  I have been using microchip's IDE with their ICE, ICD
> programming/debug tools so I am unfamiliar with the more universal
> solutions.  I like the sounds of the approach you mention here in being
> able to migrate from mfg to mfg with minimal impact.

WHOA!!!  Don't think the impact is "minimal".  You may not need to buy
a new code tools, but literally everything else will change, possibly
even the download/debug cable.  Embedded designs often require the
software to be tightly coupled to the hardware and everything other
than the CMx will be different with different mfgs.


> "Once you have invested in the toolset (and by this
> I mean invested time _and_ money _and_ tools _and_ operating
> environment and everything else that in some fashion diverts
> needed energy away from the product focus ahead of you), you
> aren't nearly so tied to one manufacturer as you might be
> with single sources."
>
> 6. So what would most univeral toolset solution be?  Already mentioned has
> been: ImageCraft, Keil,  I like the sounds of the mention GCC solutions.
> Who offers these solutions?
>
> 7. Unlike Microchip, are most other devices programmed debugged through
> jtag? What is one of the better jtag hardware devices?  I would like
> something that works with FPGA as well, if possible.

Oh, I almost forgot.  Freescale is coming out with a CM4 device which
should be pretty much a hot rod.  The Kinetis K10 looks like a really
nice chip.  It even has good analog on board.  Packages range from 5x5
mm 32QFN to 144QFP or BGA.  I expect this chip, if priced right, to
find sockets in my designs in the future.

Rick