AREF bypass capacitance on ATMega2560?

[rickman]

Good grief. The issue wasn't to show YOU that YOUR application was
better in a DSP. Like many FGPA weenies, you're trying to sell a part
that has a niche market as the universal hammer.

Good grief is right. You don't need to be rude. It isn't just my
application, the Sigma parts are designed for a very limited set of DSP
apps and even the development software limits how you design with them.
They won't do the job of *most* DSP apps.

Hammer, meet nail.

If you don't want to discuss engineering, then please spare me.

That is *NOT* what you're arguing. You're making the general case
that FPGA>> DSP>> uC, which is just silly.


Hammer, meet nail.

You are repeating yourself.

I have.


Like DSPs. I agree with him. FPGAs aren't in his future. You keep
sugar-coating FPGAs and (erroneously) tear down DSPs. Note that I'm
more of an FPGA kind of guy than a DSP sort but in this case Joerg is
absolutely right. FPGAs only compete in small niche markets and those
where money is no object.

No one is tearing down DSPs. Can you just stick to the engineering and
skip the drama?

Your statement is exactly the sort of "mis-information" I am talking
about. At $3 I think you can use an FPGA in a low cost app. So your
"money is no object" claim is just BS.

The software is different in how it works, not what it does. That
difference makes *NO* difference to the end result or the cost of the
product. IOW, it's completely irrelevant. At one time it may have
been important but only in so much as that much of it didn't work
(making the hardware useless).

That is what I am saying. I find little difference in how the tools
work. You write your HDL in your editor or their built in editor, you
simulate it using the free tool they provide and you compile to a bit
stream that gets downloaded into the FPGA, Flash or RAM. No, the tools
aren't going to look exactly the same, but they do the same job and work
the same way. Most of the tool is actually third party anyway, except
for the Xilinx HDL in house compiler. But them most FPGA professionals
(read as working for a company that has a few bucks) pay for the third
party tools anyway.

Pile on more sugar. You clearly don't work where time is money.

Ok, very convincing argument. I have no idea what you are talking
about. Downloading an FPGA is no different than an MCU. You either
attach a cable for JTAG or your use the resources you designed into your
target.

That's all included in the port. I'm talking from working hardware to
working hardware (the target system not qualified, of course). There
is only about 10% of the code that even has to be looked at.

With FPGAs *none* of the code has to be looked at.

Wrong. That's all included.

You have identical peripheral interface libraries for different brands
of MCUs? Every timer function works the same, every SPI port sets up
the same, every power controller is operated the same?

Bullshit! More sugar!

You are the consummate debater...

Oh, you never use libraries? Yet you (erroneously) add that cost into
the DSP/uC bucket.

The only libraries I use are the HDL libraries which are standardized,
like using stdio. I don't add the libraries into the MCU column, I'm
not the one using the MCU.

You've TOTALLY forgotten about simulation, for instance. That's a
huge effort that you simply sweep under the rug.

What about it? I paid for a set of tools from Lattice. I had used the
Modelsim simulator at work and was used to it. The Lattice tools said
they came with the Modelsim simulator. But by the time I got the
package it had the Active HDL simulator. I complained about this
thinking I would have to learn a new simulator... but it was a no-op to
switch. Even my Modelsim scripts ran under the AHDL simulator.

So what is your concern?

Goal post shift added to the hammer.


Sigmas have them. I haven't looked for others.

But Sigmas aren't general purpose DSPs and can't do most DSP jobs. They
are designed to be filters, like in hearing aids.

The families all look the same and vary only in density and mix of
memory, speed, MCU, DSP(hmm), and other features.

Good grief, you're arguing both sides.

We've been down the road before. You are not enjoyable to discuss
things with. You get obnoxious and don't explain what you are talking
about. Do you really want to have this discussion? I don't think I do.

 

[John Devereux]

I think what you are saying is that the MCU is a key part of your
design and you use a lot of code in it.

Yes, basically. "a lot" being only e.g. about 64k probably, not much for
a MCU but would push the price up for an FPGA I think.

Ok, if your emphasis in on using a commercial MCU that will do the
job. But unless your MCU needs are just too large for something that
fits in an FPGA, you have it backwards in my opinion. Why have both
when you can just use an FPGA?

I'm pretty sure that a FPGA with enough RAM would be far too expensive
(compared to the $3 200 MIPS CPU).

A M3 or M4 with attached FPGA + memories would be interesting, if it was
at a reasonable price.

NXP have a M4 with attached M0 which sort of goes in that direction; the
M0 does the more deterministic simple stuff, the M4 does the number
crunching and runs the more complicated software.

[...]

OK, thanks, will check them out.

I haven't gotten a quote on these parts since they were bought by
Lattice. I'd appreciate a pricing update if you get one. They should
be able to do a lot better than the Digikey price, I know Xilinx and
Altera always do. Heck, the Digikey pricing for most FPGAs doesn't go
above qty 1... if nothing else there should be some quantity price
breaks.

Unfortunately I don't really have a live application, so would only be
able to buy them as "education" at this stage.

 

[rickman]

I do various designs, sometimes simultaneously. For DSP we often just
plop down a TMS320 bare-bones edition and be done with it. It's like
buying a Ford F-150 for the ranch, it may be too big but it is not
expensive and you almost can't go wrong with it. I had designs where the
DSP workload ended up at 5% but at $3 pop nobody was concerned.

And no, mostly I don't even have the requirements until after the
project already started. Sometimes weeks down the road the sensor guys
call in, "Houston, we have a problem". This is the kind of project
companies like to use consultants for, since it can be utterly
frustrating for engineers. Us guys are use to this stuff.


I was thinking about the case where whatever-02 becomes unobtanium.

In the FPGA world, they don't obsolete individual devices although they
do *very seldom* obsolete a package. They obsolete a family. So if
whatever-02 become obsolete, so does whatever-03. Fortunately this is
usually after a *very* long life and even then they usually make the
parts available through one of the extended life makers.

We did that and all we got was a "Sorry about that". The designed-in
device was discontinued.


Looks like a good business opportunity for you

It's a better opportunity if I don't have to redesign it. I am ready to
retire and this was bringing cash in with minimal effort. Very sporadic
cash, but cash nonetheless.

Well, you do have to look in the schematics. You only asked whether one
can still buy Pentium 4 and I said yes, and gave evidence. Are you
changing the game now?

Legacy stuff in the PC world does not go away fast. To this day you can
still easily buy brand-new ISA-bus PCs. Because scores of them are used
in production facilities. I helped replace one a few years ago and it
also had a processor from the days of Methusaleh.

I wasn't aware that conventional PCs were used in industry that much.

I merely said it matter in some cases. Not in all cases.



Well, let me show you a blast from the past ...

http://www.rocelec.com/search/finis...ins/?utm_source=supplyFrame&utm_medium=buyNow

20,286 in stock, ready to ship.



Analog Devices had the market first, they really ruled in the eearly
90's. We had boards with about a dozen 16-bit FP DSPs on there.

90's??? TI came out with their DSP in the early 80's by my memory.
They then captured the cell market. The FP DSPs were not the bread and
butter of DSP. Without the cell market DSPs would likely still be
rather a niche.

Not yet. That comes if I decide to have a DSP in a project. But mostly
my clients have those discussions because that's their turf, I am more
the analog guys. On large projects stuff gets put in writing about
guaranteed years of supply. On some chips it goes as far as putting the
mask data in escrow, especially with smaller companies where there is a
chance of them going belly-up down the road.

I only wish I could do that, but making chips from masks can be an
expensive proposition if the fab is being shut down. It would seem that
is what is behind the end of the XP series from Lattice.

 

[rickman]

That's a good point. How does one find out which ones those are?

All FPGA makers offer automotive lines. They advertise them as such.

Mil stuff is even better, that needs to remain available for decades.
That is the reason why the LM331 is still around and why I used it in a
long-life design many years ago.

You won't find many $3 parts in a MIL line...

 

[Joerg]

[...]

I was thinking about the case where whatever-02 becomes unobtanium.

In the FPGA world, they don't obsolete individual devices although they
do *very seldom* obsolete a package. They obsolete a family. So if
whatever-02 become obsolete, so does whatever-03. Fortunately this is
usually after a *very* long life and even then they usually make the
parts available through one of the extended life makers.

It would be good to know which manufacturers have the best reputation
regarding longevity. I've seen a few cases where programmable logic was
discontinued and that has caused a lot of grief. But I do not remember
the brands because it wasn't really my turf.

Often longevity is way more important than performance.

[...]

It's a better opportunity if I don't have to redesign it. I am ready to
retire ...

Lucky you. It's still some time away for me and I'll probably never
fully retire, electronics design is fun. But I already talked with a
neighbor about making beer together once I slow down the EE design work
a bit. He is retired and I used to brew when I was at the university.

... and this was bringing cash in with minimal effort. Very sporadic
cash, but cash nonetheless.

If the grand total per year is worth it, why not?

I wasn't aware that conventional PCs were used in industry that much.

Oh yeah, it's all PCs there. Even the CNC stuff ultimately gets
controlled by someone on a PC. Lots of legacy devices because production
machines remain in service for decades.

At church they just switched to Apple. <sigh> So today when I looked at
the song projector software I couldn't make heads or tails of it.
That'll take a learning curve.

[...]

90's??? TI came out with their DSP in the early 80's by my memory. They
then captured the cell market. The FP DSPs were not the bread and
butter of DSP. Without the cell market DSPs would likely still be
rather a niche.

It was actually 1990. Analog Devices had the medical devices market
pretty much covered AFAICT and our product was medical. IIRC it was the
ADSP-2105 and you can still buy them today. Except now they want over
$20 a piece. Highway robbery

[...]

I only wish I could do that, but making chips from masks can be an
expensive proposition if the fab is being shut down. It would seem that
is what is behind the end of the XP series from Lattice.

It is a hassle if the whole process is discontinued. But there are IC
houses that cater to this market. They'll take the old design and
migrate it onto a newer process. However, that only works if you have
one of those escrow deals. The important thing is to make the original
design not depend on the sluggishness of contemporary ICs because on a
new process you might get the same IC functionality but on steroids.

 

[Joerg]

All FPGA makers offer automotive lines. They advertise them as such.

Ok then, next time I'll ask them. When I selected 125C devices Atmel
dropped out of the list at Digikey. Could it be that they don't do
automotive?

You won't find many $3 parts in a MIL line...

The LM331 costs slightly above $1 in bulk. But it only comes in
through-hole packages.

 

[[email protected]]

That's a good point. How does one find out which ones those are?

Click on the "Automotive" tab on the applications page in their web
site? Look for the ACQ- compliance designations?

Mil stuff is even better, that needs to remain available for decades.
That is the reason why the LM331 is still around and why I used it in a
long-life design many years ago.

The difference is that while Mil stuff may be available until the end
of times, that doesn't mean that it'll be priced within the range of
mere mortals for that time.

 

[[email protected]]

Ok then, next time I'll ask them. When I selected 125C devices Atmel
dropped out of the list at Digikey. Could it be that they don't do
automotive?

http://www.altera.com/end-markets/auto/aut-index.html
http://www.latticesemi.com/automotive
http://www.xilinx.com/applications/automotive/index.htm

Atmel makes a lot of automotive stuff but apparently they see no
reason to go there with FPGAs. Don't blame them.

 

[[email protected]]

I think what you are saying is that the MCU is a key part of your design
and you use a lot of code in it. Ok, if your emphasis in on using a
commercial MCU that will do the job. But unless your MCU needs are just
too large for something that fits in an FPGA, you have it backwards in
my opinion. Why have both when you can just use an FPGA?

First, you're assuming an FPGA (hammer).
Second, you're going to need a bigger FPGA (even bigger hammers aren't
free).

 

[Joerg]

Click on the "Automotive" tab on the applications page in their web
site? Look for the ACQ- compliance designations?

I usually go in via Digikey. No automotive tab in that segment but the
temperature range gives it away.

The difference is that while Mil stuff may be available until the end
of times, that doesn't mean that it'll be priced within the range of
mere mortals for that time.

Not the certified parts or rad-hard. But with other semiconductors it
usually means that the consumer-grade stuff remains available. Like the
LM331 which they even brought out in lead-free which the military folks
wouldn't even touch. At $4 not exactly a bargain but in situations where
you need true analog V/F conversion that is a great help.

[...]

 

[[email protected]]

I usually go in via Digikey. No automotive tab in that segment but the
temperature range gives it away.

Not at all. Automotive and industrial temperatures are quite alike
but the qualifications certainly are not. Automotive needs 85C
ambient. What that does to Tj varies by component.

Not the certified parts or rad-hard. But with other semiconductors it
usually means that the consumer-grade stuff remains available. Like the
LM331 which they even brought out in lead-free which the military folks
wouldn't even touch. At $4 not exactly a bargain but in situations where
you need true analog V/F conversion that is a great help.

No, it sometimes means that they've squirreled away enough parts to
satisfy (infinite pockets) Uncle Sam. Yes, Mil stuff has that evil
lead, in it but again, the price bathtubs are quite different (and not
symmetrical)

 

[Joerg]

Not at all. Automotive and industrial temperatures are quite alike
but the qualifications certainly are not. Automotive needs 85C
ambient. What that does to Tj varies by component.

85C in a vehicle? Yikes. I would not dare to design that in.

 

[[email protected]]

Good grief is right. You don't need to be rude. It isn't just my
application, the Sigma parts are designed for a very limited set of DSP
apps and even the development software limits how you design with them.
They won't do the job of *most* DSP apps.

That doesn't alter the fact that you're constantly moving the goal
posts. You *are* defending the FPGA as the general solution when it
is quite decidedly only applicable in the niches. You wanted to know
what DSP had a CODEC. I told you but now you whine that it won't
solve YOUR problem. It's not my job to do your work.

If you don't want to discuss engineering, then please spare me.

If you refuse to understand, why do you bother coming here?

You are repeating yourself.

Only because you are repeating your silly FPGA uber alles, nonsense.

No one is tearing down DSPs. Can you just stick to the engineering and
skip the drama?

WFT are you talking about? You *are* saying that FPGAs are the cat's
ass for all applications when nothing could be further from the truth.
they're a niche and the solution of last resort. Well, and ASSC is
the solution of last resort, but...

Your statement is exactly the sort of "mis-information" I am talking
about. At $3 I think you can use an FPGA in a low cost app. So your
"money is no object" claim is just BS.

Absolutely wrong. FPGAs are *only* useful when there is no other
choice. For anything else, they will always be the most expensive
solution. Your position is exactly a nail looking at every tool as a
hammer.

That is what I am saying. I find little difference in how the tools
work. You write your HDL in your editor or their built in editor, you
simulate it using the free tool they provide and you compile to a bit
stream that gets downloaded into the FPGA, Flash or RAM. No, the tools
aren't going to look exactly the same, but they do the same job and work
the same way. Most of the tool is actually third party anyway, except
for the Xilinx HDL in house compiler. But them most FPGA professionals
(read as working for a company that has a few bucks) pay for the third
party tools anyway.



Ok, very convincing argument. I have no idea what you are talking
about. Downloading an FPGA is no different than an MCU. You either
attach a cable for JTAG or your use the resources you designed into your
target.

You clearly don't simulate. You've completely ignored the issue here.
Like the elephant in the phone booth, FPGA zealots want to ignore it.
Simulation is much more work than design, yet it is always forgotten
in these discussions.

With FPGAs *none* of the code has to be looked at.

Oh, good grief! You never have to rework libraries? Roll your own,
for what was free in the other vendor's? All of the peripherals
function the same, for each vendors'? Come on, get real!

You have identical peripheral interface libraries for different brands
of MCUs? Every timer function works the same, every SPI port sets up
the same, every power controller is operated the same?

That's all in the two weeks. From working code to working code. We
just did it from a TI to Freescale SoC.

....yet you claim that you can do that all between X and A without even
looking at the code. Unbelievable!

You are the consummate debater...

I call bullshit when I see bullshit and that is *BULLSHIT*.

The only libraries I use are the HDL libraries which are standardized,
like using stdio. I don't add the libraries into the MCU column, I'm
not the one using the MCU.

What bullshit. There are no PCIe libraries? USB? uC? GMAFB!

What about it? I paid for a set of tools from Lattice.

Tools? TOOLS?! What do they do all by themselves?

I had used the
Modelsim simulator at work and was used to it. The Lattice tools said
they came with the Modelsim simulator. But by the time I got the
package it had the Active HDL simulator. I complained about this
thinking I would have to learn a new simulator... but it was a no-op to
switch. Even my Modelsim scripts ran under the AHDL simulator.

So what is your concern?

Simulation takes TIME and SKILL that most don't have. That's in
addition to the skills and time needed to do a uC or DSP solution. If
there is *any* way to do a project with either, the FPGA loses. That's
the whole point here; FPGAs are a solution to niches - always will be.

But Sigmas aren't general purpose DSPs and can't do most DSP jobs. They
are designed to be filters, like in hearing aids.

They do a lot and some better than other DSPs. It was an example, to
counter your point. BTW, I'm not trying to say that DSPs are the
end-all solution, like you are trying to, with FPGAs. ...and like I
said, I've done way more FPGA design than DSP (I only do hardware).

We've been down the road before. You are not enjoyable to discuss
things with. You get obnoxious and don't explain what you are talking
about. Do you really want to have this discussion? I don't think I do.

I can't help it if you don't like being called on your bullshit. If
you don't like being called on it, don't bullshit.

 

[[email protected]]

85C in a vehicle? Yikes. I would not dare to design that in.

It's a fact of life. Think JimT's car interior, parked in the
driveway in August. Design to 85C isn't just a good idea, it's the
spec (-40C to 85C).

 

[Joerg]

It's a fact of life. Think JimT's car interior, parked in the
driveway in August.

The last measurement I remember for under the dash where electronics
often live was 190F on a 98F day, with sun exposure and windows up.
Meaning the classic situation in the airport economy lot where the car
bakes 8-10h per day. That is over 87C, and this assumes the electronics
do not run and thus do not generate heat in addition. Now imagine a 115F
day which is not unusual in places like AZ or NM.

... Design to 85C isn't just a good idea, it's the
spec (-40C to 85C).

It is a bad spec. The result of such flawed design evidences itself over
and over. For example, the minivan of friends of ours would not start
when parked at a mall on a hot day after more than 15mins of driving. It
would (sometimes) come back to life if you let it sit for half an hour
so the radiated engine heat became less. In the winter it was mostly ok.
That design is IMHO junk.

 

[Paul Rubin]

I liked this article and it's one of the things that has me interested
in FPGA's:

http://www.yosefk.com/blog/how-fpgas-work-and-why-youll-buy-one.html

The attractive thing there (compared to DSP's) is having multiple DSP
blocks right there on the FPGA, even in fairly cheap ones. Even at low
clock rates you can outcompute a pretty serious DSP by using those
multipliers in parallel. And more and more powerful function blocks
(hard macros) on the FPGA are on their way. But, for computing directly
in the LUTs, there is obviously a price to be paid.

 

[[email protected]]

The last measurement I remember for under the dash where electronics
often live was 190F on a 98F day, with sun exposure and windows up.
Meaning the classic situation in the airport economy lot where the car
bakes 8-10h per day. That is over 87C, and this assumes the electronics
do not run and thus do not generate heat in addition. Now imagine a 115F
day which is not unusual in places like AZ or NM.




It is a bad spec. The result of such flawed design evidences itself over
and over. For example, the minivan of friends of ours would not start
when parked at a mall on a hot day after more than 15mins of driving. It
would (sometimes) come back to life if you let it sit for half an hour
so the radiated engine heat became less. In the winter it was mostly ok.
That design is IMHO junk.

Oh, the spec I mentioned above isn't for the engine compartment or any
of the ignition or safety gadgets. It's for the noise makers. ;-)
yes, that's the unpowered temperature. Temp rise has to be added to
that.

 

[Paul Rubin]

You have a bias against soft cores because you want to analyze them in
a meaningless way. How about analyzing them in the terms that you
care about?

Nothing I have seen indicates any problem with my analysis, which is
grounded in basic knowledge of how these circuits work. FPGA's don't
run on magic pixie dust. They have the same gates, memory cells,
etc. that other chips do. If you've got some evidence saying otherwise,
I think it's on you to put up the numbers.q

The GA144 isn't 0.5 Watts either, it is close to 1 Watt with all nodes
running.

Still not too bad.

I don't have much confidence GA will be around in 10 years. Do you
know of one major design win they have had?

I have doubts about GA too, but it's irrelevant. They did something
with a quite low tech ASIC design and fab process, which doesn't appear
to be possible with FPGA's without much more advanced fab tech.

No, you can't use an FPGA to implement some existing processor and
improve on cost, power or any other parameter. I never said you
could.

Why are you going on about softcores then? A big attraction of
softcores is to use code and compilers that you already have, instead of
building your application from scratch in Verilog. That generally means
implementing an existing processor. How else are you going to run that
code?

But if you have an application - it may well be easier to implement in
an FPGA than in a GA144...

The comparison was simply between hard and soft processors of similar
programmability to see how they did in terms of cost and speed.

 

[John Devereux]

I won't pretend that an FPGA is the right solution for every task.
But I think MCUs are often used because that is what the designer is
used to and FPGAs aren't understood well enough to consider. Is
"enough" RAM more than what a given FPGA has? I don't know, how much
RAM do you really need? Most MCU projects I have worked on never had
a realistic RAM estimate, it was all by the seat of the pants.

It's not always known how much you need, you discover things during
development, rework algorithms, sometimes trade RAM for speed. Customers
want more features.

The fact that code uses RAM makes it harder to estimate. FPGAs are a
lot easier to design with in that regard. RAM quantities have to be
known exactly.

Hmm, now that really sounds like turning a constraint into a feature!

LUT counts have to be estimated though, so its not totally different.



Or even an AVR... are you reading Ulf? I think the requirements for
MCUs are often overstated. Most of the sort of work I do could be
done with an 8051 (ugh!) if one of the higher performance devices
especially, but I often don't have the real estate for a separate MCU
unless I can treat it as an I/O expander.

Yes, if you have a powerful FPGA you could use a less powerful CPU
usually.

NXP have a M4 with attached M0 which sort of goes in that direction; the
M0 does the more deterministic simple stuff, the M4 does the number
crunching and runs the more complicated software.

Hell, I'd be estatic if they provided FPGAs in small enough packages
so I can use a 32 pin QFN for an MCU and the same footprint for an
FPGA. Well, Lattice *does* put an XO2 in a 32 QFN, but only 256 LUTs
which is not big enough for much. Why not 1 or 2 or 4 kLUT? For some
reason FPGA vendors all think you need more I/O and less LUTs.

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

[...]

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.

OK, thanks, will check them out.

I haven't gotten a quote on these parts since they were bought by
Lattice. I'd appreciate a pricing update if you get one. They should
be able to do a lot better than the Digikey price, I know Xilinx and
Altera always do. Heck, the Digikey pricing for most FPGAs doesn't go
above qty 1... if nothing else there should be some quantity price
breaks.

Unfortunately I don't really have a live application, so would only be
able to buy them as "education" at this stage.

I got a freebie eval board for the iCE40 but haven't fired it up. I
want to measure some power consumption numbers. The data sheets
changed the static current a while back, well after they had been out,
just after Lattice bought SiliconBlue so I'm not sure what that was
about. The 1 kLUT part went from around 40 uA to 100 uA quiescent
current. The dynamic current is still very low though, single digit
mA with the device full of 16 bit counters running at 32 MHz. But
they seem to have removed that data when they changed data sheet
formats.

 

[Joerg]

[email protected] wrote:

[...]

It is a bad spec. The result of such flawed design evidences itself over
and over. For example, the minivan of friends of ours would not start
when parked at a mall on a hot day after more than 15mins of driving. It
would (sometimes) come back to life if you let it sit for half an hour
so the radiated engine heat became less. In the winter it was mostly ok.
That design is IMHO junk.

Oh, the spec I mentioned above isn't for the engine compartment or any
of the ignition or safety gadgets. It's for the noise makers. ;-)
yes, that's the unpowered temperature. Temp rise has to be added to
that.

Ok, if the radio quits on a hot day that isn't going to cause much
grief. Happened to me but luckily within the warranty period. It's
annoying though, leaves kind of a cheap feeling about the whole car even
though the car doesn't deserve that. Radios are usually in the dash and
that can exceed 80C on hot days. Then the driver hops into the car,
turns on the stereo, pops in the Eric Clapton CD, listens to "Cocaine"
with the volume on 10 and ... *PHUT* ...