AREF bypass capacitance on ATMega2560?

[John Devereux]

rickman <gnuarm@gmail.com> writes:

On 9/8/2013 2:04 PM, John Devereux wrote:
rickman<gnuarm@gmail.com> writes:

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

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?

Partly I suppose.

Or I could say that my projects so far all require a microcontroller
anyway, and it seemed likely that a separate FPGA was always going to be
more expensive than, say, choosing a faster CPU.

A STM32F4 can bitbang a PIO at 84MHz. (It can't do anything else then,
but still...)

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).

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.


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

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.

--

John Devereux

 

[Phil Hobbs]

On 09/08/2013 11:30 AM, krw@attt.bizz wrote:

On Sat, 07 Sep 2013 13:35:24 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/7/2013 11:32 AM, krw@attt.bizz wrote:
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.

Nonesense. I constantly look for MCU solutions for my designs.

You certainly don't look very hard. I keep looking for FPGA solutions
and haven't found one yet. ;-)

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.

I won't argue that. But I don't consider CPLDs in the same vein as
FPGAs, but you are right, the distinction is blurring.

The architecture is the same. They're the same.

OK, let me ask the question(s) I've asked every one of the FPGA
suppliers; Define FPGA. Define CPLD. They can't. It *IS* marketing.


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.

That is the sort of thinking that is just a pair of blinders. I don't
care if the real estate is "expensive". I care about my system cost.

Part cost ~= system cost. MCUs are so cheap that any soft core is
useless. The development costs are a lot less, too. The tool chains
for the embedded stuff suck.

Gates in an FPGA are very *inexpensive*. If I want to use them for a
soft core CPU that is just as good a use as a USB or SPI interface.

Good grief. Do you have diabetes?

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.

Your opinion. I don't sell 100,000 quantities, so the prices I get at
Digikey are often competitive with the other distis. Certainly they
give you a ball park number for comparison purposes.

If you're buying no more than 1K pieces, you're sorta stuck with the
DigiKeys of the world. I am for prototypes, though I build as many
prototypes as I did in production at my last job. ;-)

The point is that
with FPGAs, *no one* gives you a good price unless you get the
manufacturer involved. That is one down side to FPGAs.

Sure, I'll buy that but it just solidifies the fact that FPGAs really
aren't mainstream components. They are a niche and probably always
will be, unfortunately.

The Proper Fixation article posted above is an interesting read.

It's been over 15 years since I last did any programmable logic, but I'm
now in the process of learning Verilog, courtesy of the legal department
of a (large) client. I need to be able to testify about a little
250-line bit of Verilog for a CPLD in an accused product.

Given the amount of C/C++ I've written over the years, Verilog is pretty
easy to read, except for the ugly Pascalian begin/end blocks, but for
testimony it'll be helpful to be able to say that I've designed working
hardware in Verilog. Fun stuff.

The main thing the blogger leaves out of the equation is task switching.
People have been talking about reconfigurable processors for yonks,
but it never happens because you can't usefully run, say, 10 threads
using the same resources. In embedded applications, sure. In general
purpose computers? Not gonna happen.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

 

[Joerg]

krw@attt.bizz wrote:

On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:

[...]

... 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.

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* ...

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Stef]

In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:

Stef wrote:
In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
Nope. Not if it's in the worlds of medical or aerospace. There you have
a huge re-cert effort on your hands for changes. New layout? Back to the
end of the line.

That is not always true (at least for medical equipment, no experience
with aerospace). If the change is minor enough, it may be enough to
write a rationale that explains the change and how it does not impact
the function of the equipment. If the notified body agrees with the
rationale, only a limitied effort is required to re-cert.


I really doubt they would agree if a code re-compilation was required to
make this work. With code and firmware they have become very careful
because there have been to many mishaps.

That depends on the software risk class. If the software imposes no risk
(risk mitigated in hardware for example), I don't think they would care.

Most of the time the notified bodies or even the FDA do not care much
about the code, they care about your process. So then the onus is on the
company, and there mostly on the VP of Quality Control. He or she will
normally not take a re-compile lightly, or as something that can be
brushed under the carpet as "not too risky".

Indeed, you need to have procedures in place for changes and lifecycle
management.

It is the same with some hardware. I went through a whole re-cert once
just because we had to switcher the manufacturer for one little transformer.

I guess that was a safety critical (isolation?) transformer then.
Depending on the available paperwork and test data that could require
re-testing some parts. But re-certing the whole device sounds a bit
too much, but I don't know the circumstances.

What can also happen is that an old medical device was certified
under the 1st edition of the european 60601 standard. If you then
change something, chances are that you need to re-cert for the 2nd
edition.

At least that was until the release of the 3rd edition. That now
requires that everything you sell is certified under the 3rd edition,
not only changed devices. A huge re-certing effort for all older
devices, changed or not.

The bottomline is that in the unlikely but possible situation where
something bad happens you need to be prepared. Then there will be a
barrage of request for documents from the regression testing and all
that. Woe to those who then don't have them.

Yes, that is where having (and using!) procedures and standards is
a real benefit.

Sometimes changing is very time consuming. I recently learned that this
is even the case for alarm systems. "If we even add as much as one
capacitor for EMC we have to go through the whole insurer certification
process again".

Weird, I would expect a similar approach with a rationale or something
would be enough.


There are many other markets with similar requirements. One of them is
railroad electronics, especially for countries like Germany.

I understand that those markets have strict requirements. But it surprises
me that their only answer to (minor) changes would be: recertify the
entire device. Instead of: Show us the changes and their effect and we'll
then see if we need full re-cert or just partial.

In my experience, in medical device you can sometimes do changes without
re-certification, but certainly not always. Thats why I started with "That
is not always true".

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

I've already got a female to worry about. Her name is the Enterprise.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0

 

On Sun, 08 Sep 2013 17:18:44 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

krw@attt.bizz writes:
Like DSPs... You keep sugar-coating FPGAs and (erroneously) tear
down DSPs. ... FPGAs only compete in small niche markets and those
where money is no object.

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.

There is also a price to pay for hard macros that go unused. That
includes DSPs and even block RAM. There is a *lot* of waste silicon
in FPGAs.

 

[Joerg]

Stef wrote:

In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
Stef wrote:
In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
Nope. Not if it's in the worlds of medical or aerospace. There you have
a huge re-cert effort on your hands for changes. New layout? Back to the
end of the line.
That is not always true (at least for medical equipment, no experience
with aerospace). If the change is minor enough, it may be enough to
write a rationale that explains the change and how it does not impact
the function of the equipment. If the notified body agrees with the
rationale, only a limitied effort is required to re-cert.

I really doubt they would agree if a code re-compilation was required to
make this work. With code and firmware they have become very careful
because there have been to many mishaps.

That depends on the software risk class. If the software imposes no risk
(risk mitigated in hardware for example), I don't think they would care.

That is almost never the case. An FPGA, just like a DSP or uC, is too
close to the game to be able to make that kind of safety claim in most
cases.

Most of the time the notified bodies or even the FDA do not care much
about the code, they care about your process. So then the onus is on the
company, and there mostly on the VP of Quality Control. He or she will
normally not take a re-compile lightly, or as something that can be
brushed under the carpet as "not too risky".

Indeed, you need to have procedures in place for changes and lifecycle
management.

We always do. But then you must also follow those procedures and
document that you did. Meaning there will be a lot of effort after each
design change no matter what. It really doesn't make much of a
difference whether the FDA checks such compliance directly or you
self-certify (honesty assumed here).

It is the same with some hardware. I went through a whole re-cert once
just because we had to switcher the manufacturer for one little transformer.

I guess that was a safety critical (isolation?) transformer then.

Yup. In medical they almost all are, even signal transformers.

Depending on the available paperwork and test data that could require
re-testing some parts. But re-certing the whole device sounds a bit
too much, but I don't know the circumstances.

Not for the whole unit but, for example, a power module. It has to go
through the whole UL spiel again. Doesn't really matter if it's the
whole machine or a smaller part of it, the effort, time and cost are
quite similar.

In some markets such a change requires full re-cert, the whole enchilada.

What can also happen is that an old medical device was certified
under the 1st edition of the european 60601 standard. If you then
change something, chances are that you need to re-cert for the 2nd
edition.

At least that was until the release of the 3rd edition. That now
requires that everything you sell is certified under the 3rd edition,
not only changed devices. A huge re-certing effort for all older
devices, changed or not.

A boondoggle for test labs.

The bottomline is that in the unlikely but possible situation where
something bad happens you need to be prepared. Then there will be a
barrage of request for documents from the regression testing and all
that. Woe to those who then don't have them.

Yes, that is where having (and using!) procedures and standards is
a real benefit.

For my office I have them even for non-med and non-aero designs.

Sometimes changing is very time consuming. I recently learned that this
is even the case for alarm systems. "If we even add as much as one
capacitor for EMC we have to go through the whole insurer certification
process again".
Weird, I would expect a similar approach with a rationale or something
would be enough.

There are many other markets with similar requirements. One of them is
railroad electronics, especially for countries like Germany.

I understand that those markets have strict requirements. But it surprises
me that their only answer to (minor) changes would be: recertify the
entire device. Instead of: Show us the changes and their effect and we'll
then see if we need full re-cert or just partial.

All I can tell you is what my clients tell me, "If we add this one diode
we would have to do this all over ..."

In my experience, in medical device you can sometimes do changes without
re-certification, but certainly not always. Thats why I started with "That
is not always true".

In the end the effort is mostly almost the same. In SW or firmware it's
regression testing et cetera. For safety boundary changes it's module
tests. And there it hardly makes a difference how much of it must be
re-tested.

Similar in aerospace. You change something on a module that goes into
aircraft and whoops, the whole RTCA/DO-160 testing has to be done all
over again. There are very few changes that would not trigger this.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

Joerg wrote:

krw@attt.bizz wrote:
On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:

[...]

... 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.
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* ...

Question: What do you do with an FPGA in a radio?

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Paul]

In article <b96e9jF51t3U1@mid.individual.net>, invalid@invalid.invalid
says...

Stef wrote:
In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
Stef wrote:
In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
Nope. Not if it's in the worlds of medical or aerospace. There you have
a huge re-cert effort on your hands for changes. New layout? Back to the
end of the line.
That is not always true (at least for medical equipment, no experience
with aerospace). If the change is minor enough, it may be enough to
write a rationale that explains the change and how it does not impact
the function of the equipment. If the notified body agrees with the
rationale, only a limitied effort is required to re-cert.

I really doubt they would agree if a code re-compilation was required to
make this work. With code and firmware they have become very careful
because there have been to many mishaps.

That depends on the software risk class. If the software imposes no risk
(risk mitigated in hardware for example), I don't think they would care.


That is almost never the case. An FPGA, just like a DSP or uC, is too
close to the game to be able to make that kind of safety claim in most
cases.

Agreed it would have to be the change to the switch for the courtesy
ADDITIONAL reading light to assist any reading of paper documents
that MIGHT not need ANY retesting.

Most of the time the notified bodies or even the FDA do not care
much
about the code, they care about your process. So then the onus is on the
company, and there mostly on the VP of Quality Control. He or she will
normally not take a re-compile lightly, or as something that can be
brushed under the carpet as "not too risky".

Indeed, you need to have procedures in place for changes and lifecycle
management.


We always do. But then you must also follow those procedures and
document that you did. Meaning there will be a lot of effort after each
design change no matter what. It really doesn't make much of a
difference whether the FDA checks such compliance directly or you
self-certify (honesty assumed here).

Thats the important thing must be documented as tested and how.

It is the same with some hardware. I went through a whole re-cert
once
just because we had to switcher the manufacturer for one little transformer.

I guess that was a safety critical (isolation?) transformer then.


Yup. In medical they almost all are, even signal transformers.

And in aerospace..

Depending on the available paperwork and test data that could
require
re-testing some parts. But re-certing the whole device sounds a bit
too much, but I don't know the circumstances.


Not for the whole unit but, for example, a power module. It has to go
through the whole UL spiel again. Doesn't really matter if it's the
whole machine or a smaller part of it, the effort, time and cost are
quite similar.

In some markets such a change requires full re-cert, the whole enchilada.


What can also happen is that an old medical device was certified
under the 1st edition of the european 60601 standard. If you then
change something, chances are that you need to re-cert for the 2nd
edition.

At least that was until the release of the 3rd edition. That now
requires that everything you sell is certified under the 3rd edition,
not only changed devices. A huge re-certing effort for all older
devices, changed or not.


A boondoggle for test labs.


The bottomline is that in the unlikely but possible situation where
something bad happens you need to be prepared. Then there will be a
barrage of request for documents from the regression testing and all
that. Woe to those who then don't have them.

Yes, that is where having (and using!) procedures and standards is
a real benefit.


For my office I have them even for non-med and non-aero designs.


Sometimes changing is very time consuming. I recently learned that this
is even the case for alarm systems. "If we even add as much as one
capacitor for EMC we have to go through the whole insurer certification
process again".
Weird, I would expect a similar approach with a rationale or something
would be enough.

There are many other markets with similar requirements. One of them is
railroad electronics, especially for countries like Germany.

I understand that those markets have strict requirements. But it surprises
me that their only answer to (minor) changes would be: recertify the
entire device. Instead of: Show us the changes and their effect and we'll
then see if we need full re-cert or just partial.


All I can tell you is what my clients tell me, "If we add this one diode
we would have to do this all over ..."


In my experience, in medical device you can sometimes do changes without
re-certification, but certainly not always. Thats why I started with "That
is not always true".


In the end the effort is mostly almost the same. In SW or firmware it's
regression testing et cetera. For safety boundary changes it's module
tests. And there it hardly makes a difference how much of it must be
re-tested.

Similar in aerospace. You change something on a module that goes into
aircraft and whoops, the whole RTCA/DO-160 testing has to be done all
over again. There are very few changes that would not trigger this.

Then you get what I have seen for Mil spec ASICs, every new wafer batch
has a small sample packaged and built up, as these are engine sensor
devices, they have to after normal testing do at least 100 hours in
aircraft flight time tests before the reste of the devices can be
tested and assembled.

This happens on EVERY wafer batch.

--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

 

[Joerg]

Paul wrote:

In article <b96e9jF51t3U1@mid.individual.net>, invalid@invalid.invalid
says...

Hey, I have a new code name

Stef wrote:
In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
Stef wrote:
In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
Nope. Not if it's in the worlds of medical or aerospace. There you have
a huge re-cert effort on your hands for changes. New layout? Back to the
end of the line.
That is not always true (at least for medical equipment, no experience
with aerospace). If the change is minor enough, it may be enough to
write a rationale that explains the change and how it does not impact
the function of the equipment. If the notified body agrees with the
rationale, only a limitied effort is required to re-cert.

I really doubt they would agree if a code re-compilation was required to
make this work. With code and firmware they have become very careful
because there have been to many mishaps.
That depends on the software risk class. If the software imposes no risk
(risk mitigated in hardware for example), I don't think they would care.

That is almost never the case. An FPGA, just like a DSP or uC, is too
close to the game to be able to make that kind of safety claim in most
cases.

Agreed it would have to be the change to the switch for the courtesy
ADDITIONAL reading light to assist any reading of paper documents
that MIGHT not need ANY retesting.

And only if there is a stern warning "Hot! Caliente! Do not put in
mouth! No introduzca en la boca! Children under the age of 65 shall not
....".

[...]

In my experience, in medical device you can sometimes do changes without
re-certification, but certainly not always. Thats why I started with "That
is not always true".

In the end the effort is mostly almost the same. In SW or firmware it's
regression testing et cetera. For safety boundary changes it's module
tests. And there it hardly makes a difference how much of it must be
re-tested.

Similar in aerospace. You change something on a module that goes into
aircraft and whoops, the whole RTCA/DO-160 testing has to be done all
over again. There are very few changes that would not trigger this.

Then you get what I have seen for Mil spec ASICs, every new wafer batch
has a small sample packaged and built up, as these are engine sensor
devices, they have to after normal testing do at least 100 hours in
aircraft flight time tests before the reste of the devices can be
tested and assembled.

This happens on EVERY wafer batch.

For mission-critical parts it has to be strict. Sometimes when you probe
through conformal coating this has to be documented. Who probed, when,
why, who re-sealed the puncture breach, signed and dated.

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Mon, 09 Sep 2013 12:17:34 -0700, Joerg <invalid@invalid.invalid>
wrote:

Joerg wrote:
krw@attt.bizz wrote:
On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:

[...]

... 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.
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* ...


Question: What do you do with an FPGA in a radio?

Lotsa possibilities. So far very few real applications; too
expensive. These are not your father's Blaupunkts. ;-)

 

[Joerg]

krw@attt.bizz wrote:

On Mon, 09 Sep 2013 12:17:34 -0700, Joerg <invalid@invalid.invalid
wrote:

Joerg wrote:
krw@attt.bizz wrote:
On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
[...]

... 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.
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* ...

Question: What do you do with an FPGA in a radio?

Lotsa possibilities. So far very few real applications; too
expensive. ...

I look at radio and other consumer gear a lot, mainly to spot
interesting ICs and other parts that I might be able to use on my
designs. Never seen an FPGA in there, ever.

... These are not your father's Blaupunkts. ;-)

I know, dad's Blaupunkts were better :-(

Still got one in the garage. In terms of large signal handling and
intermodulation it runs circles around just about anything made today.

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Mon, 09 Sep 2013 16:38:32 -0700, Joerg <invalid@invalid.invalid>
wrote:

krw@attt.bizz wrote:
On Mon, 09 Sep 2013 12:17:34 -0700, Joerg <invalid@invalid.invalid
wrote:

Joerg wrote:
krw@attt.bizz wrote:
On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
[...]

... 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.
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* ...

Question: What do you do with an FPGA in a radio?

Lotsa possibilities. So far very few real applications; too
expensive. ...


I look at radio and other consumer gear a lot, mainly to spot
interesting ICs and other parts that I might be able to use on my
designs. Never seen an FPGA in there, ever.

They're not common yet but they will find their way in. Again, cost
is the biggest barrier. OTOH, function will eventually demand them.

... These are not your father's Blaupunkts. ;-)


I know, dad's Blaupunkts were better :-(

Hardly. Dad never had a 17" LCD display on his and the XM reception
sucked. ;-)

Still got one in the garage. In terms of large signal handling and
intermodulation it runs circles around just about anything made today.

You want to listen to AM/FM radio stations? What kind of nut are you,
anyway? ;-)

 

[rickman]

On 9/9/2013 1:13 PM, krw@attt.bizz wrote:

On Sun, 08 Sep 2013 17:18:44 -0700, Paul Rubin
no.email@nospam.invalid> wrote:

krw@attt.bizz writes:
Like DSPs... You keep sugar-coating FPGAs and (erroneously) tear
down DSPs. ... FPGAs only compete in small niche markets and those
where money is no object.

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.

There is also a price to pay for hard macros that go unused. That
includes DSPs and even block RAM. There is a *lot* of waste silicon
in FPGAs.

As there is in *any* complex device. Even your car likely has lots of
features most people don't use, they all cost something. But each
feature adds value for some users and the cost is relatively small. In
the end it is much cheaper than each user having a custom design and
that is the point.

--

Rick

 

On Tue, 10 Sep 2013 23:41:47 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/10/2013 2:02 PM, krw@attt.bizz wrote:
On Mon, 09 Sep 2013 16:38:32 -0700, Joerg<invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Mon, 09 Sep 2013 12:17:34 -0700, Joerg<invalid@invalid.invalid
wrote:

Joerg wrote:
krw@attt.bizz wrote:
On Sun, 08 Sep 2013 17:15:18 -0700, Joerg<invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
[...]

... 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.
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* ...

Question: What do you do with an FPGA in a radio?

Lotsa possibilities. So far very few real applications; too
expensive. ...


I look at radio and other consumer gear a lot, mainly to spot
interesting ICs and other parts that I might be able to use on my
designs. Never seen an FPGA in there, ever.

They're not common yet but they will find their way in. Again, cost
is the biggest barrier. OTOH, function will eventually demand them.

Not until you can get them for $3...

Good Lord, you sure are a clueless twit.

 

[rickman]

On 9/9/2013 3:56 AM, John Devereux wrote:

rickman<gnuarm@gmail.com> writes:

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.

Yes, that is another way of saying "we don't want to design the thing,
let's just code it and see how it works." My point is when asking
software folks how much RAM they need they look off to the corner of the
room for a moment and then give me a number. I'm sure there are those
who know how to estimate realistically, but it's not common. So they
just want more than they think they *might* need. I'm sure a *lot* of
RAM goes unused in most MCU designs. Someone in this thread would refer
to that as silicon inefficiency.

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!

No, it is a statement that you have to size a buffer to design it into
hardware just like to do in software. But in software realistic
estimates are often put off and the numbers are played with until the
design is done. If you blow your RAM budget on an MCU you need to use
the next bigger one. Fine, but then you have a new BOM cost. Same with
FPGAs, but hardware designers are used to actually coming up with hard
numbers before they start.

No, this is just a statement that when doing hardware design it is
customary to actually spec out all the details. That is another reason
why FPGA designs typically have fewer issues in test and integration.

--

Rick

 

On Tue, 10 Sep 2013 20:21:29 -0400, rickman <gnuarm@gmail.com> wrote:

On 9/9/2013 1:13 PM, krw@attt.bizz wrote:
On Sun, 08 Sep 2013 17:18:44 -0700, Paul Rubin
no.email@nospam.invalid> wrote:

krw@attt.bizz writes:
Like DSPs... You keep sugar-coating FPGAs and (erroneously) tear
down DSPs. ... FPGAs only compete in small niche markets and those
where money is no object.

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.

There is also a price to pay for hard macros that go unused. That
includes DSPs and even block RAM. There is a *lot* of waste silicon
in FPGAs.

As there is in *any* complex device.

Oh, GMAFB. FPGAs are *designed* to have waste silicon. The whole
concept of programmable logic wastes silicon.

Even your car likely has lots of
features most people don't use, they all cost something. But each
feature adds value for some users and the cost is relatively small. In
the end it is much cheaper than each user having a custom design and
that is the point.

Good grief. At least rent a clue.

 

[rickman]

On 9/8/2013 3:56 PM, Joerg wrote:

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.

You can't measure longevity and past performance is no assurance of
future success.

Performance is actually binary, good enough or not.

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.

I kayak. At least some. Dodgy hip is impacting me these days. Once
the ACA is fully in force I'll be able to get insurance to pay for a new
one. I had insurance through my company until my colleague left, then
it was 1 employee and didn't qualify for the group plan anymore... just
before I was going to get it done.

... 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?

Marginal given the hassle of keeping a company going, tracking expenses,
taxes, state registration BS. Then there is the "vacation" issue. If I
get an order, I have to be on it. Hard to take a vacation if you don't
know when orders are expected... or maybe that should be "order". But I
shouldn't complain. I had enough surprise business this year to retire.
I guess it is a comfort level issue of cutting off any future cash flow.

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

According to wikipedia, TI had DSPs out in the early 80's which jibes
with what I recall. TI was the first with a successful product so they
got the market share early on. Once they had an established code base
in a given industry they continued to hold their lead. I can't say who
is dominant in what industry, but I know TI was rather dominant in the
cell industry which was the cash cow.

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.

Yes, but usually they do it in cooperation with the original vendor. I
assume there is a lot more to making a chip than the mask sets. The fab
process has many variables, plus there is the issue of testing and
packaging. You would think packaging would be pretty routine, but the
FPGA makers treat a chip in a different package almost as if it were a
different chip. I guess for some uses the difference in parasitics have
significant impact on noise immunity and SI issues.

--

Rick

 

[rickman]

On 9/8/2013 4:01 PM, Joerg wrote:

rickman wrote:
On 9/8/2013 12:34 PM, Joerg wrote:
krw@attt.bizz wrote:

Pick ones that are in the automotive market. Support for fifteen
years is required.


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.


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?

Atmel doesn't really do FPGAs. They have PLDs, but I'm not even sure
they have any CPLDs.

--

Rick

 

[rickman]

On 9/8/2013 11:19 PM, Paul Rubin wrote:

rickman<gnuarm@gmail.com> writes:
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

Paul, it is silly to guesstimate cost, etc from a parameter distantly
related when you can just measure the... well, *cost*.

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

Still not too bad.

Really? That's the same ballpark as the high end ARMs powering phone
and tablets. The difference is the GA144 can't do as much. Lots of
paper MIPs, but a pointless parameter in this case.

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.

They did something that has no real value that I can tell. How is that
irrelevant? That is actually the *point*. Who cares if an FPGA can do
something of no value... actually I'm sure they can. But why bother to
figure it out?

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?

I never said any of that. If you have a huge library of existing code
running on ARM processors then maybe you should stick with what you
know. Besides, it is illegal to implement an ARM in a softcore. Ask
ARM, they will be happy to point out all the patents you would be
violating.

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.

It is not a comparison I care about. Your measure of cost is rather
bogus if you base it on silicon area. Your measure of performance of
the GA144 is totally bogus. Who cares about MIPS of a processor that
uses an instruction set unlike nearly any other? Lets measure the GA144
in terms of some useful app it actually runs. Maybe because we don't
know of any...?

Ya know, I'm actually a proponent of the GA144. But in trying to use
the device, I discovered how limited its applications really are. I
used to argue that you just needed to learn how to divide your app into
appropriate sized pieces for the many, limited processors on the chip.
But there is a lot more to an MCU than MIPS. The GA144 was never
designed to be a very useful MCU, at least in the professional world. I
think it makes a good hobby chip.

Now to swing back the other way, my cash cow board uses an FPGA which is
going EOL. I can't find a replacement FPGA that I can use with 6 mil
space and trace and 10 mil vias on my PCB. Everything else I find
either is also very long in the tooth or is too little logic or comes in
a package that requires 4/4 design rules (or smaller). But the GA144
might just do the job. One limitation is the tiny memory. A delay
buffer is needed that might be too much for the on chip RAM. But I
don't know how I could ever trust that GA will be around for the next
year much less the next 10.

--

Rick

 

[rickman]

On 9/10/2013 2:02 PM, krw@attt.bizz wrote:

On Mon, 09 Sep 2013 16:38:32 -0700, Joerg<invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
On Mon, 09 Sep 2013 12:17:34 -0700, Joerg<invalid@invalid.invalid
wrote:

Joerg wrote:
krw@attt.bizz wrote:
On Sun, 08 Sep 2013 17:15:18 -0700, Joerg<invalid@invalid.invalid
wrote:

krw@attt.bizz wrote:
[...]

... 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.
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* ...

Question: What do you do with an FPGA in a radio?

Lotsa possibilities. So far very few real applications; too
expensive. ...


I look at radio and other consumer gear a lot, mainly to spot
interesting ICs and other parts that I might be able to use on my
designs. Never seen an FPGA in there, ever.

They're not common yet but they will find their way in. Again, cost
is the biggest barrier. OTOH, function will eventually demand them.

Not until you can get them for $3...

... These are not your father's Blaupunkts. ;-)


I know, dad's Blaupunkts were better :-(

Hardly. Dad never had a 17" LCD display on his and the XM reception
sucked. ;-)

Still got one in the garage. In terms of large signal handling and
intermodulation it runs circles around just about anything made today.

You want to listen to AM/FM radio stations? What kind of nut are you,
anyway? ;-)

--

Rick