AREF bypass capacitance on ATMega2560?

[Stef]

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

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.

Why do you mention the FPGA? I think we are not talking about the same
thing here.

What I meant was adding some 'real' hardware to limit things that could
get dangerous and are under software control. It is very common to add
such protection to reduce the software risk class.

Example:
A device generates a train of current pulses that pass through a
patients body for some kind of measurement. The safety of these pulses
depends on the duration, frequency and current. All of these parameters
are under software control, so in theory the software can create a
dangerous situation. This puts the software in a high risk class.

If you add hardware that monitors the output signal (timers,
comparators) and that switches off the output when the signal goes out
off bounds, the software can no longer create a dangerous situation.
That reduces the risk class of that piece of software.

This practice of adding hardware to remove the safety risk from
software is very common.

<snip, a whole lot we mostly agree on>

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.

That's where I don't agree. If I change something in my software that
is protected by hardware like in the above example. I can do my
internal tests and write a document for the notified body. This
ofcourse takes time and care but it is much less work than a full
re-certification effort. I don't need to repeat my safety tests, EMC
tests etc.


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

Think lucky. If you fall in a pond, check your pockets for fish.
-- Darrell Royal

 

[Joerg]

Stef wrote:

In comp.arch.embedded,
Joerg <invalid@invalid.invalid> wrote:
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.

Why do you mention the FPGA? I think we are not talking about the same
thing here.

The thread has moved there, Rickman advocates that a lot of things can
be better handled by FPGA. In the end it doesn't matter, programmable is
programmable and that gets scrutinized. Has to be.

What I meant was adding some 'real' hardware to limit things that could
get dangerous and are under software control. It is very common to add
such protection to reduce the software risk class.

Example:
A device generates a train of current pulses that pass through a
patients body for some kind of measurement. The safety of these pulses
depends on the duration, frequency and current. All of these parameters
are under software control, so in theory the software can create a
dangerous situation. This puts the software in a high risk class.

If you add hardware that monitors the output signal (timers,
comparators) and that switches off the output when the signal goes out
off bounds, the software can no longer create a dangerous situation.
That reduces the risk class of that piece of software.

This practice of adding hardware to remove the safety risk from
software is very common.

I generally have that. But this does not always suffice. Take dosage,
for example. Suppose a large patient needs a dose of 25 units while a
kid should never get more than 5. How would the hardware limiter know
whether the person sitting outside the machine is a heavy-set adult or a
skinny kid?

snip, a whole lot we mostly agree on

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.

That's where I don't agree. If I change something in my software that
is protected by hardware like in the above example. I can do my
internal tests and write a document for the notified body. This
ofcourse takes time and care but it is much less work than a full
re-certification effort. I don't need to repeat my safety tests, EMC
tests etc.

You can take your chances but it carries risks. For example, I have seen
a system blowing EMC just because the driver software for the barcode
reader was changed. The reason turned out not to be the machine but the
barcode reader itself. One never knows.

The other factor is the agency. If they mandate re-testing after certain
changes you have to do it. In aerospace it can also be the customer
demanding it, for example an airline.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

rickman wrote:

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.

Nope. Longevity is measure by years in production without the need for
re-design or ECOs.

Performance is actually binary, good enough or not.

Not really. With some parts you can do more things, with some less. Just
like with cars, some will haul a 2-ton trailer and some can barely do it
or not at all.

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.

Hopefully Obamacare will not cause them to deny or put you on a waiting
list because it's not "bad enough". For us, it looks like we'll be
looking at a price increase in premiums north of 50%. Ouch, ouch. Age
discrimination in those "plans" seems to be worse than what we have now.
Some folks are mulling about semi-retirement so they drop under the
magic $62k or whatever family limit. Above that, according to the
exchange calculator subsidies almost digitally stop, meaning that
earning $1k more can "earn" you $5k in penalty. What a stupid law.

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

Well, we are in America, where one does not let a good deal slip

Just send a notice to your clients ahead of time, "Will be kayaking from
San Francisco to Tokyo the 1st half of 2014. If you need help send a
speedboat or call in July"

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.

Cell phones are short-lived products. One year, if that. Med/aero is a
whole different set of metrics. We need to rely on parts still being
there 10, 20 or more years doen the road.

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

Not if it has gone belly-up. That is usually the main reason for escrow.

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

Those are not really major factors. The process will cause differences
but if you have a good IC engineer running the salvage project one can
make it work. I have witnessed process migrations (old process was being
discontinued) with our own chip design, it wasn't a major chore.
Packaging was never an issue, but then again some of ours are bare die
that then get flip-chip bonded.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

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.

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

Those things aren't important to me. What is importnat to me is large
signal handling. For example, the new radios fall apart on the Bass Lake
Grade on Hwy 50 because there are all the TV towers for the valley. The
Blaupunkt doesn't fall apart.

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? ;-)

I actually still listen to AM a lot. Oh, and I do not have a smart phone

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Paul]

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

rickman wrote:
On 9/8/2013 3:56 PM, Joerg wrote:
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.


Cell phones are short-lived products. One year, if that. Med/aero is a
whole different set of metrics. We need to rely on parts still being
there 10, 20 or more years doen the road.

Around 2002 to 2004 I had an enquiry to look at improving an NMR system
at a hospital. When I asked them what the age of the machine was they
said -

"The earliest record we have is when it MOVED to the new building
in 1968"


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

 

[Tim Williams]

"Paul" <paul@pcserviceselectronics.co.uk> wrote in message
news:MPG.2c9aa28779fcf69b98977c@172.16.0.1...

Around 2002 to 2004 I had an enquiry to look at improving an NMR system
at a hospital. When I asked them what the age of the machine was they
said -

"The earliest record we have is when it MOVED to the new building
in 1968"

Geez, was it a frequency-sweep unit? LOL

Tim

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

 

[Joerg]

Paul wrote:

In article <b9be8tF6561U1@mid.individual.net>, invalid@invalid.invalid
says...
rickman wrote:
On 9/8/2013 3:56 PM, Joerg wrote:
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.

Cell phones are short-lived products. One year, if that. Med/aero is a
whole different set of metrics. We need to rely on parts still being
there 10, 20 or more years doen the road.

Around 2002 to 2004 I had an enquiry to look at improving an NMR system
at a hospital. When I asked them what the age of the machine was they
said -

"The earliest record we have is when it MOVED to the new building
in 1968"

Some stuff lasts a long time. Here is Betsy, we used her to split firewood:

http://www.analogconsultants.com/ng/images/splitter.JPG

1942 surplus army motor, all mounted on the front axle of a 1939 DeSoto.
You can still get the tires.

--
Regards, Joerg

http://www.analogconsultants.com/

 

On Wed, 11 Sep 2013 07:53:16 -0700, Joerg <invalid@invalid.invalid>
wrote:

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.

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


Those things aren't important to me. What is importnat to me is large
signal handling. For example, the new radios fall apart on the Bass Lake
Grade on Hwy 50 because there are all the TV towers for the valley. The
Blaupunkt doesn't fall apart.

The reality is that these things are important to the vast majority of
consumers, therefore customers. Your wishes don't make a significant
market.

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? ;-)


I actually still listen to AM a lot. Oh, and I do not have a smart phone

So do I, actually, but also XM, now (very little FM - decent reception
area is too small to bother). I also use an MP3 player and I'd like
to pipe my smart phone's navi through it, but it's broken (designed
broken by Microsoft).

 

[Piotr Wyderski]

rickman wrote:

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

As long as the softcore is just a supplement to the really complex
logic. Otherwise it is not the best way to use the FPGA resources
in order to emulate an ARM. There already are dirt-cheap ARMs on
the market. I've done just a single hobby project based on FPGA
(and think about the next one), but it works and my experience is
as follows. Pros:

1. You can solder the chip and *then* start thinking what
actually it should do.

2. The PCB routing in case of not very demanding signals
is so easy...

3. There is no problem with resource conflicts. When I want
an ARM with 6 UARTS, there are not many of them and then...
look... I can't use CAN becase it reuses the pins of one
of the UARTs... remap... damn, now the Ethernet MII bus
collides with that. On an FPGA I can have 134 UARTS if
I want and no pin collisions.

4. There is simply no competition for FPGAs when precise
timing is required. It is just so indecently easy. Doing
something as "complex" as 40 PWM channels (which is what
I need now) on an MCU is a nightmare.

Cons:

1. You can simulate basically anything, but most of the
time there is no need for that. Some functional blocks
have the only sacred specification and you better not
"improve" them. Memory controllers, serial protocol
controllers, the CPU.

2. Why on Earth is there something as bizarre as NIOS
or *blaze? We don't need the next invention of a wheel.
The world pretty much converged to the ARM architecture,
so I do not want to waste my time on learning about
a niche design just because it is the only thing I can
have there because it doesn't exceed the resources
available (opencores) or because of legal issues. I do
want an ARM in every Spartan-class FPGA. I am not going
to buy a Virtex just for that purpose.

3. No analog stuff. Everything interesting needs to
be external. Welcome back to the 80s... :-/

4. Supply voltage issues. Do we really need 3 of them?

5. Why does it take so long to recompile the design?

6. Using a ready-made MCU at least the core has been debugged.
Do I really need to debug the processor in addition to debugging
its program?

Best regards, Piotr

 

[Piotr Wyderski]

Joerg wrote:

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

As a matter of fact, it is one of the best places to use an FPGA.
SDR with FPGA reconfiguration capabilities is the ideal solution.
Not for a regular FM noisemaker, though...

Best regards, Piotr

*) It was exactly the only time in my life when I used an FPGA.
+ a 14-bit@65MHz Analog Devices ADC + 104 MHz DAC.

 

[Robert Wessel]

On Mon, 09 Sep 2013 09:56:12 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

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.

IBM's POWER8 can be configured to un eight SMT threads per core.
Obviously not quite ten, but close. POWER7 can be configured to run
in SMT1/2/4 modes, with that number of SMT threads. While much of the
core is shared, the various modes also introduce different hard
partitions in various resources. POWER8 adds SMT8 mode.

In both cases the core is really overbuilt for a single thread, but
many workloads show significant throughput gains with multiple threads
running.

 

[Joerg]

krw@attt.bizz wrote:

On Wed, 11 Sep 2013 07:53:16 -0700, Joerg <invalid@invalid.invalid
wrote:

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.

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

Those things aren't important to me. What is importnat to me is large
signal handling. For example, the new radios fall apart on the Bass Lake
Grade on Hwy 50 because there are all the TV towers for the valley. The
Blaupunkt doesn't fall apart.

The reality is that these things are important to the vast majority of
consumers, therefore customers. Your wishes don't make a significant
market.

Vast majority = GUM

What matters is a sticker with very high PMPO number on there and lots
of blue LEDs.

Since new radios are mostly junk I haven't bought one in over 20 years
except a new living room stereo. And only because SWMBO kept complaining
that the old (well running ...) Kenwood tower was too large and "ugly".
Boy did I regret that, the new stereo is completely useless on the AM band.

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? ;-)

I actually still listen to AM a lot. Oh, and I do not have a smart phone

So do I, actually, but also XM, now (very little FM - decent reception
area is too small to bother). I also use an MP3 player and I'd like
to pipe my smart phone's navi through it, but it's broken (designed
broken by Microsoft).

I have yet to migrate into that sort of gear. Didn't have a need yet.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

Piotr Wyderski wrote:

Joerg wrote:

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

As a matter of fact, it is one of the best places to use an FPGA.
SDR with FPGA reconfiguration capabilities is the ideal solution.
Not for a regular FM noisemaker, though...

Best regards, Piotr

*) It was exactly the only time in my life when I used an FPGA.
+ a 14-bit@65MHz Analog Devices ADC + 104 MHz DAC.

It's going to be a tough sell for a radio. Even if they found one for $3
that's too much and they also can't stomach the 10sec to download the
compiled data in production.

Everything has to fit into the $149.95 sale price at the auto parts
place, with fat profit margins for everyone and their middlemen,
speakers, wires, neon-colored huge window sticker, a discount coupon for
installation, free coffee and free waffles

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Piotr Wyderski]

Joerg wrote:

> It's going to be a tough sell for a radio.

A car radio? Well, there's nothing to reconfigure, maybe
except of the station. It had to be a homebrew wideband
every-conceivable-modulation-capable scanner. It works to
some extent at the hardware level but I've kind of lost my
interest in SDR to finish the software side. Read: got married. ;-)

Best regards, Piotr

 

[Tauno Voipio]

On 12.9.13 8:24 , Piotr Wyderski wrote:

Joerg wrote:

It's going to be a tough sell for a radio.

A car radio? Well, there's nothing to reconfigure, maybe
except of the station. It had to be a homebrew wideband
every-conceivable-modulation-capable scanner. It works to
some extent at the hardware level but I've kind of lost my
interest in SDR to finish the software side. Read: got married. ;-)

Best regards, Piotr

That's the right attitude: Forget radio, you have better things to do.

--

-Tauno (married for 45 years)

 

[Joerg]

Piotr Wyderski wrote:

Joerg wrote:

It's going to be a tough sell for a radio.

A car radio? Well, there's nothing to reconfigure, maybe
except of the station.

But wait, there's more. Blue blinkenlights, yellow blinkenlights. When
we rented a Mustang I thought I'd stepped into a disco.

... It had to be a homebrew wideband
every-conceivable-modulation-capable scanner. It works to
some extent at the hardware level but I've kind of lost my
interest in SDR to finish the software side. Read: got married. ;-)

Oh. You, too?

My ham radio days are more or less over for the same reason but maybe
I'll pick it up again when I gradually retire. Some day. But first I
want to get back into beer brewing.

I never had much fun with SDR because it's expensive and generally
inferior to the classic circuits when it comes to performance. I do now
have one spectrum analyzer (the Signalhound) that is basically an SDR.
But that is because I need it for my job, not for fun.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Joerg]

Tauno Voipio wrote:

On 12.9.13 8:24 , Piotr Wyderski wrote:
Joerg wrote:

It's going to be a tough sell for a radio.

A car radio? Well, there's nothing to reconfigure, maybe
except of the station. It had to be a homebrew wideband
every-conceivable-modulation-capable scanner. It works to
some extent at the hardware level but I've kind of lost my
interest in SDR to finish the software side. Read: got married. ;-)

Best regards, Piotr


That's the right attitude: Forget radio, you have better things to do.

But those have serious financial consequences down the road. Diapers,
braces, tuition costs, driver license, higher car insurance premiums,
the family car wrapped around a power pole, car insurance going up some
more because of that, and so on.

--
Regards, Joerg

http://www.analogconsultants.com/

 

[Phil Hobbs]

On 09/12/2013 12:50 PM, Robert Wessel wrote:

On Mon, 09 Sep 2013 09:56:12 -0400, Phil Hobbs
pcdhSpamMeSenseless@electrooptical.net> wrote:

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.


IBM's POWER8 can be configured to un eight SMT threads per core.
Obviously not quite ten, but close. POWER7 can be configured to run
in SMT1/2/4 modes, with that number of SMT threads. While much of the
core is shared, the various modes also introduce different hard
partitions in various resources. POWER8 adds SMT8 mode.

In both cases the core is really overbuilt for a single thread, but
many workloads show significant throughput gains with multiple threads
running.

Sure, we're in violent agreement about that. (I've been writing
multithreaded and clusterized programs ever since OS/2 2.0 came out,
back in 1992.)

I was talking about trying to run multiple tasks by reconfiguring the
hardware on the fly, which is not possible with any sort of reasonable
task switching overhead.

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

 

[Tauno Voipio]

On 12.9.13 9:23 , Joerg wrote:

Tauno Voipio wrote:
On 12.9.13 8:24 , Piotr Wyderski wrote:
Joerg wrote:

It's going to be a tough sell for a radio.

A car radio? Well, there's nothing to reconfigure, maybe
except of the station. It had to be a homebrew wideband
every-conceivable-modulation-capable scanner. It works to
some extent at the hardware level but I've kind of lost my
interest in SDR to finish the software side. Read: got married. ;-)

Best regards, Piotr


That's the right attitude: Forget radio, you have better things to do.


But those have serious financial consequences down the road. Diapers,
braces, tuition costs, driver license, higher car insurance premiums,
the family car wrapped around a power pole, car insurance going up some
more because of that, and so on.

Yep - but that's a blunder everybody has to do self.

--

-T.

 

[Joerg]

Tauno Voipio wrote:

On 12.9.13 9:23 , Joerg wrote:
Tauno Voipio wrote:
On 12.9.13 8:24 , Piotr Wyderski wrote:
Joerg wrote:

It's going to be a tough sell for a radio.

A car radio? Well, there's nothing to reconfigure, maybe
except of the station. It had to be a homebrew wideband
every-conceivable-modulation-capable scanner. It works to
some extent at the hardware level but I've kind of lost my
interest in SDR to finish the software side. Read: got married. ;-)

Best regards, Piotr


That's the right attitude: Forget radio, you have better things to do.


But those have serious financial consequences down the road. Diapers,
braces, tuition costs, driver license, higher car insurance premiums,
the family car wrapped around a power pole, car insurance going up some
more because of that, and so on.


Yep - but that's a blunder everybody has to do self.

So according to that we'd both be results of blunders?

--
Regards, Joerg

http://www.analogconsultants.com/