AREF bypass capacitance on ATMega2560?

[Spehro Pefhany]

On Thu, 22 Aug 2013 19:17:10 -0500, the renowned "Tim Williams"
<tmoranwms@charter.net> wrote:

"Klaus Kragelund" <klauskvik@hotmail.com> wrote in message
news:ad74b41c-8232-48d5-8016-070e5c7a1107@googlegroups.com...
Its just a bypassing capacitor for the reference of the ADC (and what
other analog uses the REF)

I have never seen a microcontroller datasheet that spelled out that it
should be a certain value. It corresponds to bypassingm your average
bandgap IC...


No, I don't think it's that. If it's configured for internal reference,
yes, but otherwise, it's just a bypass to keep sampling and whatever
clean. As a result, one would assume it should be pretty simple (just
bypassing for external noise and low impedance), unless using the internal
reference, in which case, some stability concern might be warranted (give
or take how crappy the reference is... which, as has been mentioned, is
rather awful to begin with!).

Tim

Here's a similar requirement on a Microchip part:

The LDO voltage regulator requires an external bypass
capacitor for stability. The VUSB pin is required to have
an external bypass capacitor. It is recommended that
the capacitor be a ceramic cap between 0.22 to 0.47 uF.
On power-up, the external capacitor will look like a
large load on the LDO voltage regulator. To prevent
erroneous operation, the device is held in Reset while
a constant current source charges the external
capacitor. After the cap is fully charged, the device is
released from Reset. For more information, refer to...



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

 

[Spehro Pefhany]

On Thu, 22 Aug 2013 22:41:52 -0500, "Tim Williams"
<tmoranwms@charter.net> wrote:

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:imgd191h4qe9urhrpnsq4tg1k6mir76hb1@4ax.com...
Here's a similar requirement on a Microchip part:

The LDO voltage regulator requires an external bypass
capacitor for stability. The VUSB pin is required to have
an external bypass capacitor. It is recommended that
the capacitor be a ceramic cap between 0.22 to 0.47 uF.
snip

Considering the simplest absolute on-chip tolerances are factors of 2 to 5
(e.g., current limit on an average LDO), I wouldn't feel comfortable at
any point in that ridiculously narrow range!

Presumably they've already worked those tolerances into the
requirements. It's a valid point, though, and why testing a sample or
two is not a very good way to get a reliable product. The next batch
of chips may be quite a bit different even if they don't fool around
deliberately with process parameters, die shrinking etc.

The TL431 is, of course, an upside-down LDO, and must be compensated
accordingly. At least it's dominant-pole compensated, so it goes as
easily as any op-amp (keeping in mind the open collector output).

Tim

There's a nice figure here (bottom left page 8) illustrating the edges
of the (potential) instability zones:

http://www.diodes.com/datasheets/TL431_432.pdf

Again, "presumably" most typical devices would be stable well onshore
the islands of doom.

 

[Tim Williams]

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:vlqe19pgjlpbd2ugblv3db8vjjl6og99eo@4ax.com...

There's a nice figure here (bottom left page 8) illustrating the edges
of the (potential) instability zones:

http://www.diodes.com/datasheets/TL431_432.pdf

Again, "presumably" most typical devices would be stable well onshore
the islands of doom.

I think TI or On Semi published a similar figure as well; unfortunately,
the regions cover different ranges. If you need to use a bypass (0.01,
say), just make sure alternate-sourced components are approved by
engineering first!

Obvious solution, of course, is to add a zero (series resistor, and R+C
feedback compensation) so it behaves itself. I've done this, and it seems
to work. Haven't really tested it much (impedance, noise) though.

As long as we're speaking of TL431... why is it that ten manufacturers
provide SPICE models for the thing, totaling only two separate behavioral
models, neither of which is representative of the device?

Tim

--
Deep Friar: a very philosophical monk.
Website: http://seventransistorlabs.com

 

[Spehro Pefhany]

On Fri, 23 Aug 2013 13:19:14 -0500, "Tim Williams"
<tmoranwms@charter.net> wrote:

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:vlqe19pgjlpbd2ugblv3db8vjjl6og99eo@4ax.com...
There's a nice figure here (bottom left page 8) illustrating the edges
of the (potential) instability zones:

http://www.diodes.com/datasheets/TL431_432.pdf

Again, "presumably" most typical devices would be stable well onshore
the islands of doom.

I think TI or On Semi published a similar figure as well; unfortunately,
the regions cover different ranges. If you need to use a bypass (0.01,
say), just make sure alternate-sourced components are approved by
engineering first!

Obvious solution, of course, is to add a zero (series resistor, and R+C
feedback compensation) so it behaves itself. I've done this, and it seems
to work. Haven't really tested it much (impedance, noise) though.

As long as we're speaking of TL431... why is it that ten manufacturers
provide SPICE models for the thing, totaling only two separate behavioral
models, neither of which is representative of the device?

Tim

Because it only costs 5 cents (probably 2 cents in China)?

 

[Joerg]

Spehro Pefhany wrote:

On Fri, 23 Aug 2013 13:19:14 -0500, "Tim Williams"
tmoranwms@charter.net> wrote:

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:vlqe19pgjlpbd2ugblv3db8vjjl6og99eo@4ax.com...
There's a nice figure here (bottom left page 8) illustrating the edges
of the (potential) instability zones:

http://www.diodes.com/datasheets/TL431_432.pdf

Again, "presumably" most typical devices would be stable well onshore
the islands of doom.
I think TI or On Semi published a similar figure as well; unfortunately,
the regions cover different ranges. If you need to use a bypass (0.01,
say), just make sure alternate-sourced components are approved by
engineering first!

Obvious solution, of course, is to add a zero (series resistor, and R+C
feedback compensation) so it behaves itself. I've done this, and it seems
to work. Haven't really tested it much (impedance, noise) though.

As long as we're speaking of TL431... why is it that ten manufacturers
provide SPICE models for the thing, totaling only two separate behavioral
models, neither of which is representative of the device?

Tim

Because it only costs 5 cents (probably 2 cents in China)?

The KA431SLM in SOT23 is listed for 2.49 cents at Arrow North America
right now.

Of course, in China prices are different ...

http://www.aliexpress.com/item/Model-TL431A-TL431A-DIP-TO-92-transistor-transistor-new-regulator/1121236126.html

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Spehro Pefhany]

On Fri, 23 Aug 2013 12:04:32 -0700, Joerg <invalid@invalid.invalid>
wrote:

Spehro Pefhany wrote:
On Fri, 23 Aug 2013 13:19:14 -0500, "Tim Williams"
tmoranwms@charter.net> wrote:

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:vlqe19pgjlpbd2ugblv3db8vjjl6og99eo@4ax.com...
There's a nice figure here (bottom left page 8) illustrating the edges
of the (potential) instability zones:

http://www.diodes.com/datasheets/TL431_432.pdf

Again, "presumably" most typical devices would be stable well onshore
the islands of doom.
I think TI or On Semi published a similar figure as well; unfortunately,
the regions cover different ranges. If you need to use a bypass (0.01,
say), just make sure alternate-sourced components are approved by
engineering first!

Obvious solution, of course, is to add a zero (series resistor, and R+C
feedback compensation) so it behaves itself. I've done this, and it seems
to work. Haven't really tested it much (impedance, noise) though.

As long as we're speaking of TL431... why is it that ten manufacturers
provide SPICE models for the thing, totaling only two separate behavioral
models, neither of which is representative of the device?

Tim

Because it only costs 5 cents (probably 2 cents in China)?


The KA431SLM in SOT23 is listed for 2.49 cents at Arrow North America
right now.

Of course, in China prices are different ...

http://www.aliexpress.com/item/Model-TL431A-TL431A-DIP-TO-92-transistor-transistor-new-regulator/1121236126.html

Good old WS (Wing Shing) can be counted upon to cut prices to the
bone. No doubt cheaper again if you negotiate with them.

 

[Joerg]

Spehro Pefhany wrote:

On Fri, 23 Aug 2013 12:04:32 -0700, Joerg <invalid@invalid.invalid
wrote:

Spehro Pefhany wrote:
On Fri, 23 Aug 2013 13:19:14 -0500, "Tim Williams"
tmoranwms@charter.net> wrote:

"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:vlqe19pgjlpbd2ugblv3db8vjjl6og99eo@4ax.com...
There's a nice figure here (bottom left page 8) illustrating the edges
of the (potential) instability zones:

http://www.diodes.com/datasheets/TL431_432.pdf

Again, "presumably" most typical devices would be stable well onshore
the islands of doom.
I think TI or On Semi published a similar figure as well; unfortunately,
the regions cover different ranges. If you need to use a bypass (0.01,
say), just make sure alternate-sourced components are approved by
engineering first!

Obvious solution, of course, is to add a zero (series resistor, and R+C
feedback compensation) so it behaves itself. I've done this, and it seems
to work. Haven't really tested it much (impedance, noise) though.

As long as we're speaking of TL431... why is it that ten manufacturers
provide SPICE models for the thing, totaling only two separate behavioral
models, neither of which is representative of the device?

Tim
Because it only costs 5 cents (probably 2 cents in China)?

The KA431SLM in SOT23 is listed for 2.49 cents at Arrow North America
right now.

Of course, in China prices are different ...

http://www.aliexpress.com/item/Model-TL431A-TL431A-DIP-TO-92-transistor-transistor-new-regulator/1121236126.html

Good old WS (Wing Shing) can be counted upon to cut prices to the
bone. No doubt cheaper again if you negotiate with them.

I've had designs where we calculated parts at well under one cent, to
two positions behind the decimal point. Sometimes we even eased
resistors to 10% and 20% where feasible, to save a few pennies.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[rickman]

On 8/22/2013 1:51 PM, Joerg wrote:

Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does raise
eyebrows if I request timers and port pins and MIPS, probably because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...

--

Rick

 

[Joerg]

rickman wrote:

On 8/22/2013 1:51 PM, Joerg wrote:
Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like
that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does raise
eyebrows if I request timers and port pins and MIPS, probably because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...

I nearly always need ADC capability. Not for the brownout, I never trust
anything on those chips for that, the POR/BOR/WDT goes external. FPGA
have some downsides, they tend to become large, expensive and sometimes
power-hungry when you need math capability or an MCU core. But the main
issue for many projects is people. If the client has the experts in
house like in this case, fine. But if not then one is better off using a
uC where one can find a programmer in nearly every town. This is one
reason I am often partial to the 8051.

Of course the beauty of FPGA is that the availability of very fast glue
logic. Most uC are sorely lacking in that domain.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[rickman]

On 9/6/2013 4:33 PM, Joerg wrote:

rickman wrote:
On 8/22/2013 1:51 PM, Joerg wrote:
Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like
that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does raise
eyebrows if I request timers and port pins and MIPS, probably because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...


I nearly always need ADC capability. Not for the brownout, I never trust
anything on those chips for that, the POR/BOR/WDT goes external. FPGA
have some downsides, they tend to become large, expensive and sometimes
power-hungry when you need math capability or an MCU core.

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly. They
don't need to use any more power than an MCU and in many cases less.
They certainly don't need to be significantly more expensive unless you
consider every dollar in your designs. At the very low end MCUs can be
under $1 and still have reasonable performance. For $1 you can't get
much in the way of programmable logic. For $3 however, you can get a
chip large enough for a CPU (with math) and room for your special logic.

But the main
issue for many projects is people. If the client has the experts in
house like in this case, fine. But if not then one is better off using a
uC where one can find a programmer in nearly every town. This is one
reason I am often partial to the 8051.

Do you work in *every* town? I find if I need a skill, it doesn't
matter where the worker is. I also find FPGA design is pretty common
these days. If you are ever short on FPGA design skills, give me a shout.

Of course the beauty of FPGA is that the availability of very fast glue
logic. Most uC are sorely lacking in that domain.

Yes, the ideal chip would add a section of FPGA fabric to a conventional
MCU and vary the size just as they do the RAM and Flash. I think at
this point the problem is cultural. Most FPGA companies are all about
the big iron selling for $100 a chip min and the MCU makers don't
understand programmable logic. Xilinx and Cypress is good examples.
Zync is a very high end solution, great if it matches your problem.
PSOC is not a bad idea, but their idea of programmable logic isn't worth
much.

Give me a good $10 MCU/FPGA combo and I'll design the world! In the
meantime I'll be using soft cores. They are a lot easier to program
than an MCU anyway.

--

Rick

 

[Joerg]

rickman wrote:

On 9/6/2013 4:33 PM, Joerg wrote:
rickman wrote:
On 8/22/2013 1:51 PM, Joerg wrote:
Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like
that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about
the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does
raise
eyebrows if I request timers and port pins and MIPS, probably
because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...


I nearly always need ADC capability. Not for the brownout, I never trust
anything on those chips for that, the POR/BOR/WDT goes external. FPGA
have some downsides, they tend to become large, expensive and sometimes
power-hungry when you need math capability or an MCU core.

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly. They
don't need to use any more power than an MCU and in many cases less.
They certainly don't need to be significantly more expensive unless you
consider every dollar in your designs. At the very low end MCUs can be
under $1 and still have reasonable performance. For $1 you can't get
much in the way of programmable logic. ...

That is often the problem. Sometimes a buck fifty is the pain threshold.
Not in this ATMega case, the 2560 is very expensive but comes with lots
of ADC and analog muxes and all that. Things that will cost extra with a
FPGA solution and eat real estate.


For $3 however, you can get a

chip large enough for a CPU (with math) and room for your special logic.

For $3 I can get a big DSP.

But the main
issue for many projects is people. If the client has the experts in
house like in this case, fine. But if not then one is better off using a
uC where one can find a programmer in nearly every town. This is one
reason I am often partial to the 8051.

Do you work in *every* town? I find if I need a skill, it doesn't
matter where the worker is. ...

Not in every town but sometimes way out there. For most work it doesn't
matter where the worker is but with uC programming that is often not so.
Mainly because things have to be optimized right there at the big
machine which for one reason or the other can't be moved into a
programmer's bedroom corner in Upper Sendusky. Then it does begin to
matter whether or not you have to start flying in people.

It's the same with myself. For many assigments I could as well live on
East Rarotonga. But not for EMC or noise fixing jobs with larger
installations.

... I also find FPGA design is pretty common
these days. If you are ever short on FPGA design skills, give me a shout.

Could happen.

What I often find is people only doing Altera or only Xilinx. With uC
it's a bit easier, a PIC guy can be cajoled into programming an AVR,
usually.

Of course the beauty of FPGA is that the availability of very fast glue
logic. Most uC are sorely lacking in that domain.

Yes, the ideal chip would add a section of FPGA fabric to a conventional
MCU and vary the size just as they do the RAM and Flash. I think at
this point the problem is cultural. Most FPGA companies are all about
the big iron selling for $100 a chip min and the MCU makers don't
understand programmable logic. Xilinx and Cypress is good examples.
Zync is a very high end solution, great if it matches your problem. PSOC
is not a bad idea, but their idea of programmable logic isn't worth much.

Give me a good $10 MCU/FPGA combo and I'll design the world! In the
meantime I'll be using soft cores. They are a lot easier to program
than an MCU anyway.

Things quickly unravel when you start relying on real hardware that is
on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.

Last week I reviewed a design with some larger FPGA on there. What I
found fairly disgusting was how much they had to be babied with the
power sequencing. uCs don't have that problem.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[rickman]

On 9/6/2013 7:10 PM, Joerg wrote:

rickman wrote:
On 9/6/2013 4:33 PM, Joerg wrote:
rickman wrote:
On 8/22/2013 1:51 PM, Joerg wrote:
Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like
that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about
the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does
raise
eyebrows if I request timers and port pins and MIPS, probably
because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...


I nearly always need ADC capability. Not for the brownout, I never trust
anything on those chips for that, the POR/BOR/WDT goes external. FPGA
have some downsides, they tend to become large, expensive and sometimes
power-hungry when you need math capability or an MCU core.

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly. They
don't need to use any more power than an MCU and in many cases less.
They certainly don't need to be significantly more expensive unless you
consider every dollar in your designs. At the very low end MCUs can be
under $1 and still have reasonable performance. For $1 you can't get
much in the way of programmable logic. ...


That is often the problem. Sometimes a buck fifty is the pain threshold.
Not in this ATMega case, the 2560 is very expensive but comes with lots
of ADC and analog muxes and all that. Things that will cost extra with a
FPGA solution and eat real estate.


For $3 however, you can get a
chip large enough for a CPU (with math) and room for your special logic.


For $3 I can get a big DSP.

What "big" DSP can you get for $3? It has been a while since I looked
hard at DSP chips, but I don't recall any I would call remotely "big"
for $3. The TI chips that would be "big" are the TMS6xxx line which
start somewhere around $20 the last time I looked and that requires all
memory and I/O to be separate. The smaller DSP chips that you can get
for the $3 range are not "big" in any sense and only a very few of them
include Flash memory. So you still need another chip.

Even a "small" FPGA can run rings around a DSP when it comes to
performance. Usually "big" in DSPs means fast and when you want really
fast DSP you use an FPGA with all the parallelism you can handle. DSPs
can't touch FPGAs for speed, even with low power.

But the main
issue for many projects is people. If the client has the experts in
house like in this case, fine. But if not then one is better off using a
uC where one can find a programmer in nearly every town. This is one
reason I am often partial to the 8051.

Do you work in *every* town? I find if I need a skill, it doesn't
matter where the worker is. ...


Not in every town but sometimes way out there. For most work it doesn't
matter where the worker is but with uC programming that is often not so.
Mainly because things have to be optimized right there at the big
machine which for one reason or the other can't be moved into a
programmer's bedroom corner in Upper Sendusky. Then it does begin to
matter whether or not you have to start flying in people.

It's the same with myself. For many assigments I could as well live on
East Rarotonga. But not for EMC or noise fixing jobs with larger
installations.

I'm confused. Are you saying that on most jobs you don't care where the
programmer lives and works? I think that is what you said, but it
sounds like you are trying to disagree with me.

... I also find FPGA design is pretty common
these days. If you are ever short on FPGA design skills, give me a shout.


Could happen.

What I often find is people only doing Altera or only Xilinx. With uC
it's a bit easier, a PIC guy can be cajoled into programming an AVR,
usually.

I'm totally device agnostic. I have worked with all brands other than
MicroSemi (formerly Actel). I even worked with Lucent which was bought
by Lattice and I believe is still sold and supported (but not the GD XP
line which I had designed into a cash cow product and will have to
redesign now). Ever hear of Concurrent? They were bought by Atmel.
Their devices were followed by the AT40K. I worked with the Concurrent
devices. lol So you can see I go way back.

I've used schematic based tools and both VHDL and Verilog. I've worked
with the vendor's tools and third party tools including the NeoCAD tools
which became Xilinx tools when Xilinx bought them.

If anyone tells you they only know one brand of FPGA you are talking to
an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in
terms of usage. MCUs need all sorts of start up code and peripheral
drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly
have the same features and most of that can be inferred from the HDL so
you never need to look too hard under the hood.

In short, there is a lot of FUD about FPGAs. Talk to someone who
doesn't buy into the FUD.

Of course the beauty of FPGA is that the availability of very fast glue
logic. Most uC are sorely lacking in that domain.

Yes, the ideal chip would add a section of FPGA fabric to a conventional
MCU and vary the size just as they do the RAM and Flash. I think at
this point the problem is cultural. Most FPGA companies are all about
the big iron selling for $100 a chip min and the MCU makers don't
understand programmable logic. Xilinx and Cypress is good examples.
Zync is a very high end solution, great if it matches your problem. PSOC
is not a bad idea, but their idea of programmable logic isn't worth much.

Give me a good $10 MCU/FPGA combo and I'll design the world! In the
meantime I'll be using soft cores. They are a lot easier to program
than an MCU anyway.


Things quickly unravel when you start relying on real hardware that is
on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.

If you really need it all on a single chip, then yes, you won't find
that on so many FPGAs although Microsemi has their Fusion line with
analog. My cash cow uses a single FPGA and a stereo CODEC. That was
smaller than any MCU design because the MCU would still require the
CODEC (CD quality) and some of the control logic and interface could not
be done with any conventional MCU. I had to vary the speed of the CODEC
clock via an ADPLL to synchronize it with an incoming data stream. I
don't know how to do that with an MCU and no logic. But I can do it all
with FPGA logic and no MCU.

Last week I reviewed a design with some larger FPGA on there. What I
found fairly disgusting was how much they had to be babied with the
power sequencing. uCs don't have that problem.

If you want to work with the wrong device, then you will find it hard to
work with. There are still single voltage devices on the market. If
this was an old design, most likely it was a Spartan 3 or similar era
device when they (for still unknown reasons) used three, yes, count
them, *three* voltages on the FPGA. The 2.5 volt aux supply was there
solely for the configuration interface which was normally to a 3.3 volt
device! Only from Xilinx...

If this was a new device, then I guess they picked one based on
something other than ease of use, eh? Don't assume all FPGAs are the same.

You are aware that there are Flash based FPGAs that don't require the
external Flash chip, right?

--

Rick

 

[John Devereux]

rickman <gnuarm@gmail.com> writes:

On 9/6/2013 4:33 PM, Joerg wrote:
rickman wrote:
On 8/22/2013 1:51 PM, Joerg wrote:
Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like
that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does raise
eyebrows if I request timers and port pins and MIPS, probably because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...


I nearly always need ADC capability. Not for the brownout, I never trust
anything on those chips for that, the POR/BOR/WDT goes external. FPGA
have some downsides, they tend to become large, expensive and sometimes
power-hungry when you need math capability or an MCU core.

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly.
They don't need to use any more power than an MCU and in many cases
less. They certainly don't need to be significantly more expensive
unless you consider every dollar in your designs. At the very low end
MCUs can be under $1 and still have reasonable performance. For $1
you can't get much in the way of programmable logic. For $3 however,
you can get a chip large enough for a CPU (with math) and room for
your special logic.

I've never used an FPGA, microcontrollers have increased in speed faster
than my needs so far. So I can usually bitbang everything or use a
peripheral. I used PLDs for glue logic back in the day but that's it. Oh
and I bought a small xilinx dev kit which I got to make a led flash then
put in a drawer for 15 years.

But could you give an example of your $3 one? Or a favorite?


[...]


--

John Devereux

 

[rickman]

On 9/7/2013 4:24 AM, John Devereux wrote:

rickman<gnuarm@gmail.com> writes:

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly.
They don't need to use any more power than an MCU and in many cases
less. They certainly don't need to be significantly more expensive
unless you consider every dollar in your designs. At the very low end
MCUs can be under $1 and still have reasonable performance. For $1
you can't get much in the way of programmable logic. For $3 however,
you can get a chip large enough for a CPU (with math) and room for
your special logic.

I've never used an FPGA, microcontrollers have increased in speed faster
than my needs so far. So I can usually bitbang everything or use a
peripheral. I used PLDs for glue logic back in the day but that's it. Oh
and I bought a small xilinx dev kit which I got to make a led flash then
put in a drawer for 15 years.

So your use of MCUs is based on inertia?


> But could you give an example of your $3 one? Or a favorite?

A startup company called Silicon Blue came out with a line of FPGAs
targeted to the high volume, low power market that exists for portable
devices. They were preparing their second device family and were bought
by Lattice Semi. The first family was dropped and the second family is
the iCE40 (for 40 nm). They are very low power although smallish. The
largest one has 8 kLUTs, the smallest 384 LUTs.

Last winter I was looking at designing a very low power radio controlled
clock to run in one of these. They were still playing a shell game with
the devices in the lineup and the 640 LUT part I wanted to use was
dropped... The only real problem I have with these devices is the
packaging. Because of the target market the packages are mostly fine
pitch BGAs. Great if you are making a cell phone, not so great if you
are designing other equipment.

You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts.
It has been a while since I got a quote. The 1 kLUT part is big
enough for a soft core MCU plus some custom logic.

BTW, with MCUs Digikey will give you a realistic price quote. In the
FPGA world the distis never give you a good price unless you ask for a
quantity quote. I have gotten prices quoted to me that were half the
list price. FPGA companies play a different marketing game and have a
lot of room to negotiate in order to buy a socket.

--

Rick

 

[Joerg]

rickman wrote:

On 9/6/2013 7:10 PM, Joerg wrote:
rickman wrote:
On 9/6/2013 4:33 PM, Joerg wrote:
rickman wrote:
On 8/22/2013 1:51 PM, Joerg wrote:
Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like
that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about
the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does
raise
eyebrows if I request timers and port pins and MIPS, probably
because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...


I nearly always need ADC capability. Not for the brownout, I never
trust
anything on those chips for that, the POR/BOR/WDT goes external. FPGA
have some downsides, they tend to become large, expensive and sometimes
power-hungry when you need math capability or an MCU core.

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly. They
don't need to use any more power than an MCU and in many cases less.
They certainly don't need to be significantly more expensive unless you
consider every dollar in your designs. At the very low end MCUs can be
under $1 and still have reasonable performance. For $1 you can't get
much in the way of programmable logic. ...


That is often the problem. Sometimes a buck fifty is the pain threshold.
Not in this ATMega case, the 2560 is very expensive but comes with lots
of ADC and analog muxes and all that. Things that will cost extra with a
FPGA solution and eat real estate.


For $3 however, you can get a
chip large enough for a CPU (with math) and room for your special logic.


For $3 I can get a big DSP.

What "big" DSP can you get for $3? ...

For example, this:

http://www.ti.com/lit/ds/symlink/tms320c5535.pdf

... It has been a while since I looked
hard at DSP chips, but I don't recall any I would call remotely "big"
for $3. The TI chips that would be "big" are the TMS6xxx line which
start somewhere around $20 the last time I looked and that requires all
memory and I/O to be separate. The smaller DSP chips that you can get
for the $3 range are not "big" in any sense and only a very few of them
include Flash memory. So you still need another chip.

It has tons of memory on board.

Even a "small" FPGA can run rings around a DSP when it comes to
performance. Usually "big" in DSPs means fast and when you want really
fast DSP you use an FPGA with all the parallelism you can handle. DSPs
can't touch FPGAs for speed, even with low power.

Most of the really powerful FPGA that I connected to or had to review
designs with them in there were painfully expensive.

But the main
issue for many projects is people. If the client has the experts in
house like in this case, fine. But if not then one is better off
using a
uC where one can find a programmer in nearly every town. This is one
reason I am often partial to the 8051.

Do you work in *every* town? I find if I need a skill, it doesn't
matter where the worker is. ...


Not in every town but sometimes way out there. For most work it doesn't
matter where the worker is but with uC programming that is often not so.
Mainly because things have to be optimized right there at the big
machine which for one reason or the other can't be moved into a
programmer's bedroom corner in Upper Sendusky. Then it does begin to
matter whether or not you have to start flying in people.

It's the same with myself. For many assigments I could as well live on
East Rarotonga. But not for EMC or noise fixing jobs with larger
installations.

I'm confused. Are you saying that on most jobs you don't care where the
programmer lives and works? ...

Yes, on most but _not_ all. That's key.

... I think that is what you said, but it
sounds like you are trying to disagree with me.

I disagree with the statement "it doesn't matter where the worker is".
Because sometimes (not always) it does matter. And when it does, close
proximity is very important. Then you need to literally work
side-by-side. Done it many times.

Our local SW guy sold his horse ranch and moved out of California. Only
to Reno which is under 2h drive but that's already a bit far. And in
winter you might not get through the pass or can't get back home.

... I also find FPGA design is pretty common
these days. If you are ever short on FPGA design skills, give me a
shout.


Could happen.

What I often find is people only doing Altera or only Xilinx. With uC
it's a bit easier, a PIC guy can be cajoled into programming an AVR,
usually.

I'm totally device agnostic. I have worked with all brands other than
MicroSemi (formerly Actel). I even worked with Lucent which was bought
by Lattice and I believe is still sold and supported (but not the GD XP
line which I had designed into a cash cow product and will have to
redesign now). Ever hear of Concurrent? They were bought by Atmel.
Their devices were followed by the AT40K. I worked with the Concurrent
devices. lol So you can see I go way back.

My only foray into the world of programmable logic was an old Intel
series. Because it was the first that didn't guzzle power as if it was
free. But in hindsight I was glad I abandoned that. Because Intel did.

I've used schematic based tools and both VHDL and Verilog. I've worked
with the vendor's tools and third party tools including the NeoCAD tools
which became Xilinx tools when Xilinx bought them.

If anyone tells you they only know one brand of FPGA you are talking to
an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in
terms of usage. MCUs need all sorts of start up code and peripheral
drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly
have the same features and most of that can be inferred from the HDL so
you never need to look too hard under the hood.

In short, there is a lot of FUD about FPGAs. Talk to someone who
doesn't buy into the FUD.

Yeah, maybe next time I need major logic we should talk. But better not
about politics

Of course the beauty of FPGA is that the availability of very fast glue
logic. Most uC are sorely lacking in that domain.

Yes, the ideal chip would add a section of FPGA fabric to a conventional
MCU and vary the size just as they do the RAM and Flash. I think at
this point the problem is cultural. Most FPGA companies are all about
the big iron selling for $100 a chip min and the MCU makers don't
understand programmable logic. Xilinx and Cypress is good examples.
Zync is a very high end solution, great if it matches your problem. PSOC
is not a bad idea, but their idea of programmable logic isn't worth
much.

Give me a good $10 MCU/FPGA combo and I'll design the world! In the
meantime I'll be using soft cores. They are a lot easier to program
than an MCU anyway.


Things quickly unravel when you start relying on real hardware that is
on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.

If you really need it all on a single chip, then yes, you won't find
that on so many FPGAs although Microsemi has their Fusion line with
analog. My cash cow uses a single FPGA and a stereo CODEC. That was
smaller than any MCU design because the MCU would still require the
CODEC (CD quality) and some of the control logic and interface could not
be done with any conventional MCU. I had to vary the speed of the CODEC
clock via an ADPLL to synchronize it with an incoming data stream. I
don't know how to do that with an MCU and no logic. But I can do it all
with FPGA logic and no MCU.

Hmm, I was looking at audio interfacing just yesterday because I am
going to need that on one new project. There's plenty out there that
should be directly adressable via MCU. For me it's probably going to be
something from the PCM290x series but there's also SPI variants and so on.

Anyhow, I am also going to need ADC and comparator, including muxes for
them, so this one will likely be a uC case again because otherwise all
this has to be added externally.

Last week I reviewed a design with some larger FPGA on there. What I
found fairly disgusting was how much they had to be babied with the
power sequencing. uCs don't have that problem.

If you want to work with the wrong device, then you will find it hard to
work with. There are still single voltage devices on the market. If
this was an old design, most likely it was a Spartan 3 or similar era
device when they (for still unknown reasons) used three, yes, count
them, *three* voltages on the FPGA. The 2.5 volt aux supply was there
solely for the configuration interface which was normally to a 3.3 volt
device! Only from Xilinx...

If this was a new device, then I guess they picked one based on
something other than ease of use, eh? Don't assume all FPGAs are the same.

Well, this guy is a real expert on high-end FPGA and the project
requires stuff with tons of horsepower.

You are aware that there are Flash based FPGAs that don't require the
external Flash chip, right?

Same with uCs, since a very long time

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Fri, 06 Sep 2013 23:59:59 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/6/2013 7:10 PM, Joerg wrote:
rickman wrote:
On 9/6/2013 4:33 PM, Joerg wrote:
rickman wrote:
On 8/22/2013 1:51 PM, Joerg wrote:
Tim Williams wrote:
"Joerg"<invalid@invalid.invalid> wrote in message
news:b7l1blFlu93U2@mid.individual.net...
I saw people
using 0.1uF and 0.47uF. The datasheet is silent about stuff like
that,
as usual.
It doesn't really matter.

However, not everyone knows that because they don't say much about
the
innards of the chip. It's my first ATMega case, or maybe the 2nd.

Finally gave up and bit the uC bullet? ;-)


Sometimes you need it. A while ago I even had a switcher design that
would have been totally impossible to do without a uC. But it does
raise
eyebrows if I request timers and port pins and MIPS, probably
because of
my analog background. "YOU want some of the uC resources? What for?"

Sounds to me like you need FPGA resources moreso than an MCU. Are you
using the ADC or DAC, guess so or are you using the reference for the
brownout or something else? DACs are easy in FPGAs, ADCs not as easy.
Otherwise FPGAs do everything an MCU does plus...


I nearly always need ADC capability. Not for the brownout, I never trust
anything on those chips for that, the POR/BOR/WDT goes external. FPGA
have some downsides, they tend to become large, expensive and sometimes
power-hungry when you need math capability or an MCU core.

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly. They
don't need to use any more power than an MCU and in many cases less.
They certainly don't need to be significantly more expensive unless you
consider every dollar in your designs. At the very low end MCUs can be
under $1 and still have reasonable performance. For $1 you can't get
much in the way of programmable logic. ...


That is often the problem. Sometimes a buck fifty is the pain threshold.
Not in this ATMega case, the 2560 is very expensive but comes with lots
of ADC and analog muxes and all that. Things that will cost extra with a
FPGA solution and eat real estate.


For $3 however, you can get a
chip large enough for a CPU (with math) and room for your special logic.


For $3 I can get a big DSP.

What "big" DSP can you get for $3? It has been a while since I looked
hard at DSP chips, but I don't recall any I would call remotely "big"
for $3. The TI chips that would be "big" are the TMS6xxx line which
start somewhere around $20 the last time I looked and that requires all
memory and I/O to be separate. The smaller DSP chips that you can get
for the $3 range are not "big" in any sense and only a very few of them
include Flash memory. So you still need another chip.

We pay less than that for the largest of the ADI sigma DSPs. I just
received a quote for the smallest CPLD for around $.75. I have use
for CPLDs and FPGAs but they're simply too expensive for most of my
applications.

Even a "small" FPGA can run rings around a DSP when it comes to
performance. Usually "big" in DSPs means fast and when you want really
fast DSP you use an FPGA with all the parallelism you can handle. DSPs
can't touch FPGAs for speed, even with low power.

Comparing the two is silly. Each has its place.

<snip>

What I often find is people only doing Altera or only Xilinx. With uC
it's a bit easier, a PIC guy can be cajoled into programming an AVR,
usually.

I'm totally device agnostic. I have worked with all brands other than
MicroSemi (formerly Actel). I even worked with Lucent which was bought
by Lattice and I believe is still sold and supported (but not the GD XP
line which I had designed into a cash cow product and will have to
redesign now). Ever hear of Concurrent? They were bought by Atmel.
Their devices were followed by the AT40K. I worked with the Concurrent
devices. lol So you can see I go way back.

The difference anymore is very small. The only reason I prefer one
over the other is software and that takes a back seat to most other
variables (in rough order of importance, 1. cost, 2. cost, 3. cost).

The one feature that isn't universal is programming modes. This can
make a big difference in indirect costs (field upgrade, SKU
personalization, etc.) that may not show up directly on the raw BOM.

I've used schematic based tools and both VHDL and Verilog. I've worked
with the vendor's tools and third party tools including the NeoCAD tools
which became Xilinx tools when Xilinx bought them.

If anyone tells you they only know one brand of FPGA you are talking to
an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in
terms of usage. MCUs need all sorts of start up code and peripheral
drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly
have the same features and most of that can be inferred from the HDL so
you never need to look too hard under the hood.

Sure, the feature set and peripherals of micros varies widely. We use
a variety of SoCs from just about everyone. Since most are settling
on ARM, switching from one to the other is pretty simple. Our last
port from one manufacturer to the other took a couple of weeks.

In short, there is a lot of FUD about FPGAs. Talk to someone who
doesn't buy into the FUD.

The FUD is on both sides. The support costs aren't as low as you
pretend.

Of course the beauty of FPGA is that the availability of very fast glue
logic. Most uC are sorely lacking in that domain.

Yes, the ideal chip would add a section of FPGA fabric to a conventional
MCU and vary the size just as they do the RAM and Flash. I think at
this point the problem is cultural. Most FPGA companies are all about
the big iron selling for $100 a chip min and the MCU makers don't
understand programmable logic. Xilinx and Cypress is good examples.
Zync is a very high end solution, great if it matches your problem. PSOC
is not a bad idea, but their idea of programmable logic isn't worth much.

Give me a good $10 MCU/FPGA combo and I'll design the world! In the
meantime I'll be using soft cores. They are a lot easier to program
than an MCU anyway.


Things quickly unravel when you start relying on real hardware that is
on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.

If you really need it all on a single chip, then yes, you won't find
that on so many FPGAs although Microsemi has their Fusion line with
analog. My cash cow uses a single FPGA and a stereo CODEC. That was
smaller than any MCU design because the MCU would still require the
CODEC (CD quality) and some of the control logic and interface could not
be done with any conventional MCU. I had to vary the speed of the CODEC
clock via an ADPLL to synchronize it with an incoming data stream. I
don't know how to do that with an MCU and no logic. But I can do it all
with FPGA logic and no MCU.

Nonsense. DSPs are also available with CODECs, as are UCs.

Last week I reviewed a design with some larger FPGA on there. What I
found fairly disgusting was how much they had to be babied with the
power sequencing. uCs don't have that problem.

If you want to work with the wrong device, then you will find it hard to
work with. There are still single voltage devices on the market. If
this was an old design, most likely it was a Spartan 3 or similar era
device when they (for still unknown reasons) used three, yes, count
them, *three* voltages on the FPGA. The 2.5 volt aux supply was there
solely for the configuration interface which was normally to a 3.3 volt
device! Only from Xilinx...

If this was a new device, then I guess they picked one based on
something other than ease of use, eh? Don't assume all FPGAs are the same.

I thought you just said that there weren't many differences between
FPGA manufacturers?

You are aware that there are Flash based FPGAs that don't require the
external Flash chip, right?

 

On Sat, 07 Sep 2013 10:00:51 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/7/2013 4:24 AM, John Devereux wrote:
rickman<gnuarm@gmail.com> writes:

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly.
They don't need to use any more power than an MCU and in many cases
less. They certainly don't need to be significantly more expensive
unless you consider every dollar in your designs. At the very low end
MCUs can be under $1 and still have reasonable performance. For $1
you can't get much in the way of programmable logic. For $3 however,
you can get a chip large enough for a CPU (with math) and room for
your special logic.

I've never used an FPGA, microcontrollers have increased in speed faster
than my needs so far. So I can usually bitbang everything or use a
peripheral. I used PLDs for glue logic back in the day but that's it. Oh
and I bought a small xilinx dev kit which I got to make a led flash then
put in a drawer for 15 years.

So your use of MCUs is based on inertia?

It seems that the "when all you have is a nail..." argument is
prevalent on both sides of this discussion.

But could you give an example of your $3 one? Or a favorite?

A startup company called Silicon Blue came out with a line of FPGAs
targeted to the high volume, low power market that exists for portable
devices. They were preparing their second device family and were bought
by Lattice Semi. The first family was dropped and the second family is
the iCE40 (for 40 nm). They are very low power although smallish. The
largest one has 8 kLUTs, the smallest 384 LUTs.

Everyone has $3 parts, now. It's a matter of finding the FPGA that
fits the application. The line between CPLDs and FPGAs isn't very
sharp anymore and is mostly marketing. CPLDs go well under a buck.

Last winter I was looking at designing a very low power radio controlled
clock to run in one of these. They were still playing a shell game with
the devices in the lineup and the 640 LUT part I wanted to use was
dropped... The only real problem I have with these devices is the
packaging. Because of the target market the packages are mostly fine
pitch BGAs. Great if you are making a cell phone, not so great if you
are designing other equipment.

A very good point. I've beat up all of the FPGA supplier on exactly
this point. I can't use fine-pitch BGAs. Less than .8mm pitch is a
real problem, though with some arm twisting we can go to .5mm. The
business case for an FPGA hasn't materialized (it affects the entire
board design), though. There is always another solution.

You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts.
It has been a while since I got a quote. The 1 kLUT part is big
enough for a soft core MCU plus some custom logic.

IMO, a soft core MCU negates the whole reason for an FPGA. You're
using *expensive* realestate to do what a cheap piece of silicon can
easily do. There is probably an application somewhere that makes
sense but I've always found a better/cheaper solution.

BTW, with MCUs Digikey will give you a realistic price quote. In the
FPGA world the distis never give you a good price unless you ask for a
quantity quote. I have gotten prices quoted to me that were half the
list price. FPGA companies play a different marketing game and have a
lot of room to negotiate in order to buy a socket.

"DigiKey" and "realistic quote" don't belong in the same sentence. For
any quantity catalogs just don't cut it.

 

[Joerg]

rickman wrote:

On 9/7/2013 4:24 AM, John Devereux wrote:
rickman<gnuarm@gmail.com> writes:

If your FPGA designs are expensive or power hungry, then you are doing
things you can't do in an MCU or you are not using FPGAs properly.
They don't need to use any more power than an MCU and in many cases
less. They certainly don't need to be significantly more expensive
unless you consider every dollar in your designs. At the very low end
MCUs can be under $1 and still have reasonable performance. For $1
you can't get much in the way of programmable logic. For $3 however,
you can get a chip large enough for a CPU (with math) and room for
your special logic.

I've never used an FPGA, microcontrollers have increased in speed faster
than my needs so far. So I can usually bitbang everything or use a
peripheral. I used PLDs for glue logic back in the day but that's it. Oh
and I bought a small xilinx dev kit which I got to make a led flash then
put in a drawer for 15 years.

So your use of MCUs is based on inertia?


But could you give an example of your $3 one? Or a favorite?

A startup company called Silicon Blue came out with a line of FPGAs
targeted to the high volume, low power market that exists for portable
devices. They were preparing their second device family and were bought
by Lattice Semi. The first family was dropped and the second family is
the iCE40 (for 40 nm). They are very low power although smallish. The
largest one has 8 kLUTs, the smallest 384 LUTs.

Last winter I was looking at designing a very low power radio controlled
clock to run in one of these. They were still playing a shell game with
the devices in the lineup and the 640 LUT part I wanted to use was
dropped... The only real problem I have with these devices is the
packaging. Because of the target market the packages are mostly fine
pitch BGAs. Great if you are making a cell phone, not so great if you
are designing other equipment.

You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts.
It has been a while since I got a quote. The 1 kLUT part is big enough
for a soft core MCU plus some custom logic.

Got a mfg and part number? Or a Digikey link?

BTW, with MCUs Digikey will give you a realistic price quote. In the
FPGA world the distis never give you a good price unless you ask for a
quantity quote. I have gotten prices quoted to me that were half the
list price. FPGA companies play a different marketing game and have a
lot of room to negotiate in order to buy a socket.

Yeah, the old haggle game. Beats my why they still cling to such
medieval sales tactics. The only other market where that is customary is
with used car salesmen.

They don't even know how much in business opportunity they are missing
because of this. Guys like me need pricing info here, this minute, right
now. If there is even as much as a label "Call" I usually move on.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[rickman]

On 9/7/2013 11:10 AM, Joerg wrote:

rickman wrote:
On 9/6/2013 7:10 PM, Joerg wrote:

That is often the problem. Sometimes a buck fifty is the pain threshold.
Not in this ATMega case, the 2560 is very expensive but comes with lots
of ADC and analog muxes and all that. Things that will cost extra with a
FPGA solution and eat real estate.


For $3 however, you can get a
chip large enough for a CPU (with math) and room for your special logic.


For $3 I can get a big DSP.

What "big" DSP can you get for $3? ...


For example, this:

http://www.ti.com/lit/ds/symlink/tms320c5535.pdf

I don't see it for $3. Did you get a quote for your project? TI says
it is $5 to $8 at qty 1k depending on the flavor. You still need to add
Flash.

... It has been a while since I looked
hard at DSP chips, but I don't recall any I would call remotely "big"
for $3. The TI chips that would be "big" are the TMS6xxx line which
start somewhere around $20 the last time I looked and that requires all
memory and I/O to be separate. The smaller DSP chips that you can get
for the $3 range are not "big" in any sense and only a very few of them
include Flash memory. So you still need another chip.


It has tons of memory on board.

Yes, and many FPGAs have "tons" of memory on board although not for
$3... but then this isn't a $3 part either...

Even a "small" FPGA can run rings around a DSP when it comes to
performance. Usually "big" in DSPs means fast and when you want really
fast DSP you use an FPGA with all the parallelism you can handle. DSPs
can't touch FPGAs for speed, even with low power.


Most of the really powerful FPGA that I connected to or had to review
designs with them in there were painfully expensive.

Because you were looking at FPGAs that were "painfully" large I'm sure.
How many pins, 256, 400+...? 20,000 LUTs, 40,000 LUTs?

It's the same with myself. For many assigments I could as well live on
East Rarotonga. But not for EMC or noise fixing jobs with larger
installations.

I'm confused. Are you saying that on most jobs you don't care where the
programmer lives and works? ...


Yes, on most but _not_ all. That's key.

So you could use FPGA instead of an MCU on most of your designs? I'm
still confused. Are you saying if you can't use a part on all of your
designs you don't want to use it on any?

... I think that is what you said, but it
sounds like you are trying to disagree with me.


I disagree with the statement "it doesn't matter where the worker is".
Because sometimes (not always) it does matter. And when it does, close
proximity is very important. Then you need to literally work
side-by-side. Done it many times.

Our local SW guy sold his horse ranch and moved out of California. Only
to Reno which is under 2h drive but that's already a bit far. And in
winter you might not get through the pass or can't get back home.

I have done many jobs remotely and it has *never* been a problem. If
debugging is needed in the field, that is not the same thing as saying
the developer has to be in the field. You are welcome to disagree on
this.

I can only remember one time where I iterated through design changes in
the field and that was actually a case where I could have done it all
remotely, but I was pleasing the customer to be there. Turns out he
wasn't initializing the design right and it was hard to detect.

One big advantage to FPGAs is the ability to simulate at a low level.
it is very easy to emulate the I/O in an HDL simulation. I don't know
how they do that with MCUs, but in the FPGA world I've never had a problem.

... I also find FPGA design is pretty common
these days. If you are ever short on FPGA design skills, give me a
shout.


Could happen.

What I often find is people only doing Altera or only Xilinx. With uC
it's a bit easier, a PIC guy can be cajoled into programming an AVR,
usually.

I'm totally device agnostic. I have worked with all brands other than
MicroSemi (formerly Actel). I even worked with Lucent which was bought
by Lattice and I believe is still sold and supported (but not the GD XP
line which I had designed into a cash cow product and will have to
redesign now). Ever hear of Concurrent? They were bought by Atmel.
Their devices were followed by the AT40K. I worked with the Concurrent
devices. lol So you can see I go way back.


My only foray into the world of programmable logic was an old Intel
series. Because it was the first that didn't guzzle power as if it was
free. But in hindsight I was glad I abandoned that. Because Intel did.

Wow! That was a *long* time ago. FPGAs have changed a lot. Just not
so much from Xilinx.

I've used schematic based tools and both VHDL and Verilog. I've worked
with the vendor's tools and third party tools including the NeoCAD tools
which became Xilinx tools when Xilinx bought them.

If anyone tells you they only know one brand of FPGA you are talking to
an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in
terms of usage. MCUs need all sorts of start up code and peripheral
drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly
have the same features and most of that can be inferred from the HDL so
you never need to look too hard under the hood.

In short, there is a lot of FUD about FPGAs. Talk to someone who
doesn't buy into the FUD.


Yeah, maybe next time I need major logic we should talk. But better not
about politics

Yeah... Even if you need minor logic let's talk. I find the real
advantage to FPGAs is in the fact that I can do almost *anything* in
one. I don't need to add stuff unless it is very application specific
like the CD quality CODEC on my current production board. I could get
CD quality from an FPGA design, but it wouldn't be worth the work to
save a $3 part.

Things quickly unravel when you start relying on real hardware that is
on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.

If you really need it all on a single chip, then yes, you won't find
that on so many FPGAs although Microsemi has their Fusion line with
analog. My cash cow uses a single FPGA and a stereo CODEC. That was
smaller than any MCU design because the MCU would still require the
CODEC (CD quality) and some of the control logic and interface could not
be done with any conventional MCU. I had to vary the speed of the CODEC
clock via an ADPLL to synchronize it with an incoming data stream. I
don't know how to do that with an MCU and no logic. But I can do it all
with FPGA logic and no MCU.


Hmm, I was looking at audio interfacing just yesterday because I am
going to need that on one new project. There's plenty out there that
should be directly adressable via MCU. For me it's probably going to be
something from the PCM290x series but there's also SPI variants and so on.

Anyhow, I am also going to need ADC and comparator, including muxes for
them, so this one will likely be a uC case again because otherwise all
this has to be added externally.

You do know that it is not hard to add an ADC to an FPGA? No need for a
mux if all the inputs can be connected to separate pins. It all depends
on the resolution you need. 8 bits is easy, 16 bits - not so easy.

Last week I reviewed a design with some larger FPGA on there. What I
found fairly disgusting was how much they had to be babied with the
power sequencing. uCs don't have that problem.

If you want to work with the wrong device, then you will find it hard to
work with. There are still single voltage devices on the market. If
this was an old design, most likely it was a Spartan 3 or similar era
device when they (for still unknown reasons) used three, yes, count
them, *three* voltages on the FPGA. The 2.5 volt aux supply was there
solely for the configuration interface which was normally to a 3.3 volt
device! Only from Xilinx...

If this was a new device, then I guess they picked one based on
something other than ease of use, eh? Don't assume all FPGAs are the same.


Well, this guy is a real expert on high-end FPGA and the project
requires stuff with tons of horsepower.

That's fine, just don't judge all FPGAs by the ones you have seen. If
the only MCU you had worked with were ARM 11s using 3 Watts and running
a cell phone down in 8 hours, would you think the PIC MCUs were the same?

You are aware that there are Flash based FPGAs that don't require the
external Flash chip, right?


Same with uCs, since a very long time

You are missing my point.

--

Rick

 

[rickman]

On 9/7/2013 11:17 AM, krw@attt.bizz wrote:

On Fri, 06 Sep 2013 23:59:59 -0400, rickman<gnuarm@gmail.com> wrote:

On 9/6/2013 7:10 PM, Joerg wrote:
That is often the problem. Sometimes a buck fifty is the pain threshold.
Not in this ATMega case, the 2560 is very expensive but comes with lots
of ADC and analog muxes and all that. Things that will cost extra with a
FPGA solution and eat real estate.


For $3 however, you can get a
chip large enough for a CPU (with math) and room for your special logic.


For $3 I can get a big DSP.

What "big" DSP can you get for $3? It has been a while since I looked
hard at DSP chips, but I don't recall any I would call remotely "big"
for $3. The TI chips that would be "big" are the TMS6xxx line which
start somewhere around $20 the last time I looked and that requires all
memory and I/O to be separate. The smaller DSP chips that you can get
for the $3 range are not "big" in any sense and only a very few of them
include Flash memory. So you still need another chip.

We pay less than that for the largest of the ADI sigma DSPs. I just
received a quote for the smallest CPLD for around $.75. I have use
for CPLDs and FPGAs but they're simply too expensive for most of my
applications.

It seems the prices have come down in recent years, but still, the parts
I have seen have no Flash. So you need to add in that cost. But the
Sigma parts aren't really general purpose. They are good if you can
make you app fit the DSP design, otherwise they aren't much use. I
pursued them hard a few years ago until an FAE just threw in the towel
and said I couldn't do my app on their part.

Even a "small" FPGA can run rings around a DSP when it comes to
performance. Usually "big" in DSPs means fast and when you want really
fast DSP you use an FPGA with all the parallelism you can handle. DSPs
can't touch FPGAs for speed, even with low power.

Comparing the two is silly. Each has its place.

That makes no sense. There will always be some designs that a given
part is a perfect fit for, but that doesn't mean different devices can't
be compared. The question is what is the best fit for a given job. I
am hearing some say that FPGAs aren't the best fit and I find they often
are a better fit than an MCU. Much of it has to do with mis-information
about what FPGAs can and can't do and what is required to make them run.
Just read Joerge's post. Much of the stuff he objects to is specific
to the individual devices he has worked with.

What I often find is people only doing Altera or only Xilinx. With uC
it's a bit easier, a PIC guy can be cajoled into programming an AVR,
usually.

I'm totally device agnostic. I have worked with all brands other than
MicroSemi (formerly Actel). I even worked with Lucent which was bought
by Lattice and I believe is still sold and supported (but not the GD XP
line which I had designed into a cash cow product and will have to
redesign now). Ever hear of Concurrent? They were bought by Atmel.
Their devices were followed by the AT40K. I worked with the Concurrent
devices. lol So you can see I go way back.

The difference anymore is very small. The only reason I prefer one
over the other is software and that takes a back seat to most other
variables (in rough order of importance, 1. cost, 2. cost, 3. cost).

I have not found a big difference in software. The software is
different, but those differences are not important. It all compiles my
HDL fine (mostly because they often use the same third party tool
vendors) and simulation just works anymore.

The one feature that isn't universal is programming modes. This can
make a big difference in indirect costs (field upgrade, SKU
personalization, etc.) that may not show up directly on the raw BOM.

I don't know what devices you work with, but the ones I use are easy to
program.

I've used schematic based tools and both VHDL and Verilog. I've worked
with the vendor's tools and third party tools including the NeoCAD tools
which became Xilinx tools when Xilinx bought them.

If anyone tells you they only know one brand of FPGA you are talking to
an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in
terms of usage. MCUs need all sorts of start up code and peripheral
drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly
have the same features and most of that can be inferred from the HDL so
you never need to look too hard under the hood.

Sure, the feature set and peripherals of micros varies widely. We use
a variety of SoCs from just about everyone. Since most are settling
on ARM, switching from one to the other is pretty simple. Our last
port from one manufacturer to the other took a couple of weeks.

The CPU is the easy part to port, the compiler handles that for you. It
is the drivers for the I/O that is harder. Their libraries have to have
compatible interfaces and every port is a port. With FPGAs, all you
need to do to switch between brands is normally a new pin list and
timing constraints. The HDL just compiles to suit the new device. It
has been a while since I ported between brands but it would make sense
if they provide tools to port the timing constraints. That is the only
part that might be any work at all.

In short, there is a lot of FUD about FPGAs. Talk to someone who
doesn't buy into the FUD.

The FUD is on both sides. The support costs aren't as low as you
pretend.

Care to elaborate?

Things quickly unravel when you start relying on real hardware that is
on uC but not on FPGA. Comparators, ADCs, analog muxes, for example.

If you really need it all on a single chip, then yes, you won't find
that on so many FPGAs although Microsemi has their Fusion line with
analog. My cash cow uses a single FPGA and a stereo CODEC. That was
smaller than any MCU design because the MCU would still require the
CODEC (CD quality) and some of the control logic and interface could not
be done with any conventional MCU. I had to vary the speed of the CODEC
clock via an ADPLL to synchronize it with an incoming data stream. I
don't know how to do that with an MCU and no logic. But I can do it all
with FPGA logic and no MCU.

Nonsense. DSPs are also available with CODECs, as are UCs.

You can find a small number of DSPs with CD qualitity CODECs and the
same for MCUs. I know, I did this search recently. I didn't find much
and none that suited my other critera. So the redo of my board will
likely have another FPGA on it.

I would appreciate a list of the MCUs/DSPs which have stereo CD quality
CODECs on chip. The Sigma parts from ADI don't count because their DSPs
can *only* be used for certain coding like filters, not general purpose
use.

Last week I reviewed a design with some larger FPGA on there. What I
found fairly disgusting was how much they had to be babied with the
power sequencing. uCs don't have that problem.

If you want to work with the wrong device, then you will find it hard to
work with. There are still single voltage devices on the market. If
this was an old design, most likely it was a Spartan 3 or similar era
device when they (for still unknown reasons) used three, yes, count
them, *three* voltages on the FPGA. The 2.5 volt aux supply was there
solely for the configuration interface which was normally to a 3.3 volt
device! Only from Xilinx...

If this was a new device, then I guess they picked one based on
something other than ease of use, eh? Don't assume all FPGAs are the same.

I thought you just said that there weren't many differences between
FPGA manufacturers?

You are mixing apples and oranges. One manufacturer has many different
families of FPGAs, no? Some are huge power hungry devices that burn a
hole in your board. Others are much lower power and don't burn a hole
in your pocketbook either.

--

Rick