CASTalk.com

I am wondering if the SoC (ARM/AMBA architecture) (where a
whole system with upgradeable hardware modules/ IP cores can be stuffed
inside a single chip) will make all kinds of generalized
microcontrollers (like PIC) obsolete.
When PIC microcontrollers are used, they often need external hardware
to help them, DSP blocks cannot be integrated into the chip at will
(its all up to Microchip, whatever they decide to include in a chip).
Just seems to me like SoC will eventually replace every MCU based
system, because of the processing power, and application-specific
flexibility in hardware. And almost all systems can use extra
processing power, capabilities & etc.
Maybe a traffic light with video camera and remote alerts for
speeders + array radar sensing of speeding cars & reporting their
position via GPS. I'm not saying that developing a supercomputing
traffic light is a very high priority task, just using it as an
illustration of stuffing more capability into into a simple system.

What would be the problem will be with replacing almost all MCU-based
systems with SoC?

Telenochek wrote:

I am wondering if the SoC (ARM/AMBA architecture) (where a
whole system with upgradeable hardware modules/ IP cores can be stuffed
inside a single chip) will make all kinds of generalized
microcontrollers (like PIC) obsolete.

You're talking apples and oranges.

The PIC excels at simple jobs where the development
time is measured in days. Hang some stuff on the
I/O's and write some quick code. The parts cost
is measured in cents.

Moving IP cores around in an FPGA then converting
it to a custom design takes months and tens or
hundreds of thousands of dollars.

When PIC microcontrollers are used, they often need external hardware
to help them, DSP blocks cannot be integrated into the chip at will
(its all up to Microchip, whatever they decide to include in a chip).
Just seems to me like SoC will eventually replace every MCU based
system, because of the processing power, and application-specific
flexibility in hardware. And almost all systems can use extra
processing power, capabilities & etc.

No. Sometimes it's best to keep things as simple
as possible. Sometimes a PIC is the right thing,
sometimes an ARM is the right thing and sometimes
an op-amp is the right thing.

I don't see that changing in the next 5 years.

Maybe a traffic light with video camera and remote alerts for
speeders + array radar sensing of speeding cars & reporting their
position via GPS. I'm not saying that developing a supercomputing
traffic light is a very high priority task, just using it as an
illustration of stuffing more capability into into a simple system.

What would be the problem will be with replacing almost all MCU-based
systems with SoC?

Money, time, retraining.

Sure I understand that right now FPGA dev tools put a heavy burden on
the developer. Same goes for ARM development.

But when the development tools become advanced enough so that you can
go:
I want a 16bit 30MIPS processor in the center, and a CAN controller
over here and RF transmitter over here, and a FFT core right here.
Then write some code in software (Java/C++) (not VHDL/Verilog HDLs) or
better yet just draw it in a visual GUI in the form of a block diagram,
click the block, set some settings and it works. With all the hardware
correctly configured & clocking synchronization issues automatically
taken care of.
Like C++ application development, only in hardware.

How far away are we from the above scenario?

In article <1133203186.281807.245400@z14g2000cwz.googlegroups.com>,
interpasha@hotmail.com says...

Sure I understand that right now FPGA dev tools put a heavy burden on
the developer. Same goes for ARM development.

But when the development tools become advanced enough so that you can
go:
I want a 16bit 30MIPS processor in the center, and a CAN controller
over here and RF transmitter over here, and a FFT core right here.
Then write some code in software (Java/C++) (not VHDL/Verilog HDLs) or
better yet just draw it in a visual GUI in the form of a block diagram,
click the block, set some settings and it works. With all the hardware
correctly configured & clocking synchronization issues automatically
taken care of.
Like C++ application development, only in hardware.

How far away are we from the above scenario?


Probably not too far if one of the bigger software vendors thinks

they can sell enough units at about $10,000 each to pay for
a few million dollars in development cost. I wouldn't hold
my breath waiting for it, though!@ ;-)


When you get that package, you can then figure out how to pay
the license fees for the IP that will be included. I suspect
that will involve lawyers! ;-(


Mark Borgerson

Probably not too far if one of the bigger software vendors thinks
they can sell enough units at about $10,000 each to pay for
a few million dollars in development cost. I wouldn't hold
my breath waiting for it, though!@ ;-)

When you get that package, you can then figure out how to pay
the license fees for the IP that will be included. I suspect
that will involve lawyers! ;-(

Xilinx development tools don't cost that much if you don't buy "the
latest & the greatest".
In fact, the WebPack costs nothing.
And Spartan3 Starter Kit costs only 100$
Just the Spartan3 Starter Kit alone with the WebPack have the
capabilities unthinkable just a decade ago. 200K reprogrammable gates
of completely custom logic?!

IP cores & software are just a piece of plastic, that costs nothing to
produce apart from development costs (which can be a lot, of course).
Provided the software sells enough the price can easily go down.
Of course putting the design in silicon will be expensive...

Telenochek wrote:
<snip>

What would be the problem will be with replacing almost all MCU-based
systems with SoC?

Let's see: Price, and operational details, like battery life, Size etc.

Nothing really important :)

-jg

Price, and operational details, like battery life, Size etc.

Actually, size of a SoC is much smaller than of a system composed of
individual hardware pieces put together on a board.

On 28 Nov 2005 11:39:49 -0800, the renowned "Telenochek"
<interpasha@hotmail.com> wrote:

I expect a continuing trend for
more and better peripherals to be included on-chip.

So in your opinion instead of having highly customizable chip and
systems, the trend is to offer a wider variety of chips for developers
to choose from?

Well, that's a different question.

It can be made highly (?) customizable by simply throwing everything
but the kitchen sink onto the chip (as hard logic) along with some
muxes and allowing the programmer to select what goes to the (limited)
I/O lines. Already you're seeing that happen with many micros
including low-end 10-bit ADCs and such like as standard. As well, the
number of slightly different micros in given families has been
expanding greatly, so I'm not sure any trend one way or the other is
yet evident. I suspect that it's business strategy driven rather than
depending on technology beyond the obvious application of Moore's law.

Many companies also make their own business decision to standardize on
chips that are not the absolute minimum required so that they can
decrease stocking requirements, improve time to market, and get better
quantity discounts.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

Jim Stewart wrote:

Telenochek wrote:

I am wondering if the SoC (ARM/AMBA architecture) (where a
whole system with upgradeable hardware modules/ IP cores can be stuffed
inside a single chip) will make all kinds of generalized
microcontrollers (like PIC) obsolete.

You're talking apples and oranges.

The PIC excels at simple jobs where the development
time is measured in days. Hang some stuff on the
I/O's and write some quick code. The parts cost
is measured in cents.

IMHO most of embedded devices do not live up to >1k quantities, there is
probably plenty of system integration teams that care about the budget
and do not have the comfort of own ASIC or spending hundreeds on
universal SBCs with volumes of 10-100. If they do not find required
device off shelf, or if

device_price * expected_volume > 2-4 weeks_of_development

they choose to create their own. There is advantage of higher control
over functionality and bugs and subsequent needs for the device can be
fullfiled for the price of parts and labour.

We have all these specialized embedded devices being designed and
produced in 1-2 digit quantities each year. I tend to agree with OP that
there is a need for highly reconfigurable highly integrated ~30 MIPS SoC.

Telenochek wrote:

Sure I understand that right now FPGA dev tools put a heavy burden on
the developer. Same goes for ARM development.

But when the development tools become advanced enough so that you can
go:
I want a 16bit 30MIPS processor in the center, and a CAN controller
over here and RF transmitter over here, and a FFT core right here.
Then write some code in software (Java/C++) (not VHDL/Verilog HDLs) or
better yet just draw it in a visual GUI in the form of a block diagram,
click the block, set some settings and it works. With all the hardware
correctly configured & clocking synchronization issues automatically
taken care of.
Like C++ application development, only in hardware.

How far away are we from the above scenario?

If you want to look at trends, the problem is not going to be
software, it will be power consumption.
Yes, SW has been getting steadily better, but the Static Icc of
FPGAs has been getting worse for a number of generations.

Take something like a MSP430, and try and get even close to replace
that electrical performance in a FPGA.

Another flaw of the SoC mindset, is the resource wastage. For
some designs it looks a good solution, but for many others, the
components the SoC vendor has chosen, have hard ceilings, and
you end up more constrained in design, than when using more
conventional components.

The number of generalized microcontrollers has been growing, not
declining, over the last decade, and that is not about to reverse.

-jg

I expect a continuing trend for
more and better peripherals to be included on-chip.

So in your opinion instead of having highly customizable chip and
systems, the trend is to offer a wider variety of chips for developers
to choose from?

On 28 Nov 2005 10:39:46 -0800, the renowned "Telenochek"
<interpasha@hotmail.com> wrote:

Sure I understand that right now FPGA dev tools put a heavy burden on
the developer. Same goes for ARM development.

But when the development tools become advanced enough so that you can
go:
I want a 16bit 30MIPS processor in the center, and a CAN controller
over here and RF transmitter over here, and a FFT core right here.
Then write some code in software (Java/C++) (not VHDL/Verilog HDLs) or
better yet just draw it in a visual GUI in the form of a block diagram,
click the block, set some settings and it works. With all the hardware
correctly configured & clocking synchronization issues automatically
taken care of.
Like C++ application development, only in hardware.

How far away are we from the above scenario?

Synthesizeable cores take more silicon, use more power and are lower
performance than hard cores, all other things being equal. One trend
is to put hard processors onto FPGA chips, where, like unused
peripherals on a microcontroller, they can be ignored if not used,
since they only add a few percent to the chip area.

I don't think we'll see anything like you suggest anytime soon (at
least not at a popular price point). I expect a continuing trend for
more and better peripherals to be included on-chip (and you can use or
not use them) and for processors to be included on FPGAs, but the
latter would have to have a lot of flash ROM included to start to look
very attractive, and the chips are already *way* too big and expensive
for many volume applications (even with state-of-the-art 90nm
processes etc.).

Some things are limited by process too-- it may not be economical to
put a large flash array on the same chip as an RF periperal etc. or
FPGA RAM-based structure or high-precision analog circuitry like
delta-sigma converters and voltage references.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

Telenochek wrote:

Sure I understand that right now FPGA dev tools put a heavy burden on
the developer. Same goes for ARM development.

I've heard similar arguments for software development: "The powerful
UML-based tools will make conventional programming languages like C/C++
obsolete for most programming."

In fact, I know of one company that replaced a legacy 8051 design
(written in C and assembly) with a new one based on a ColdFire and
developed entirely in state-machine UML that is compiled down to
executable code with a custom run-time environment.

They seem happy with their new implementation, although they managed to
replace a $30 BoM with a $100 BoM, upped their power usage, and upped
their physical volume. And (IMHO) made their code largely
unmaintainable to "conventional" embedded systems developers. Ever seen
a UML state machine for bit-banging I2C? Blech.

A few years back I was convinced that we'd be seeing large-scale use of
Java for embedded devices, mostly based on the availability of cheap
Java programmers and MCU that speak Java natively. Hasn't happened yet.
Now I doubt that it ever will, although Ajile is still making their
CPUs and seems sustainable, if not profitable.

Horses for courses.

Kelly

Telenochek wrote:

I expect a continuing trend for
more and better peripherals to be included on-chip.


So in your opinion instead of having highly customizable chip and
systems, the trend is to offer a wider variety of chips for developers
to choose from?

Yes, that is happening already. ARM uC's start at $1.47,
and what you get for <$1 is always improving.
You now have ARM devices with 12 bit ADC/DAC and ones with
USB and Ethernet - and all these are true single chip devices.

Look at the lineups from Freescale, Microchip, Philips, Atmel....

FPGA solutions still have a serious memory blind-spot : ie they
are not actually SoC, but system on multiple chips....
Until the code memory issue is solved, they are a niche
solution. ( relative to microcontrollers )

The Atmel FpSLIC is a classic example of the problems in so called SoC.
Another example of a company that only offered "highly customizable"
devices, is Triscend -> never hit critical mass....

Microcontrollers ship in huge volumes, orders of magnitude greater than
FPGAs, or any SoC solutions.

FPGA's are also a little like PCs in their price models : You get more
for your $$,every year, but the absolute cheapest price is not dropping
- Indeed, on some CPLDs, the lowest price node is actually increasing...


-jg

Telenochek wrote:

Probably not too far if one of the bigger software vendors thinks
they can sell enough units at about $10,000 each to pay for
a few million dollars in development cost. I wouldn't hold
my breath waiting for it, though!@ ;-)

When you get that package, you can then figure out how to pay
the license fees for the IP that will be included. I suspect
that will involve lawyers! ;-(

Xilinx development tools don't cost that much if you don't buy "the
latest & the greatest".
In fact, the WebPack costs nothing.
And Spartan3 Starter Kit costs only 100$
Just the Spartan3 Starter Kit alone with the WebPack have the
capabilities unthinkable just a decade ago. 200K reprogrammable gates
of completely custom logic?!

IP cores & software are just a piece of plastic, that costs nothing to
produce apart from development costs (which can be a lot, of course).
Provided the software sells enough the price can easily go down.
Of course putting the design in silicon will be expensive...

Typical IP cores for FPGAs for things like CAN controllers, Ethernet,
DDR memory interfaces, USB, etc., cost many thousands of dollars, and
typically impose restrictions such as the devices they work with, or
being locked to a single workstation. When you take into account the
cost of the FPGA space to implement them, the additional hardware
components (you will always need external driver chips), along with the
development costs, including testing and debugging, and you see that the
only make sense if you are making very large quantities, or have very
specific requirements. There are plenty of situations where FPGAs with
such cores are appropriate - especially if you already have the FPGA on
board for specialised logic. And there are plenty of things that an
FPGA can do better than anything else. But there is no way they are
going to replace microcontrollers or other specific hardware devices -
there is some overlap, but they are basically complementary technologies.