Maker Pro
Maker Pro

AREF bypass capacitance on ATMega2560?

S

Stef

Jan 1, 1970
0
In comp.arch.embedded,
Joerg said:
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.
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".
 
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.
 
J

Joerg

Jan 1, 1970
0
Stef said:
In comp.arch.embedded,


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.

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

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.

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.

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

Joerg

Jan 1, 1970
0
Joerg said:
[...]
... 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?
 
P

Paul

Jan 1, 1970
0
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.
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.
Yup. In medical they almost all are, even signal transformers.

And in aerospace..

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.



A boondoggle for test labs.



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



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 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 | [email protected]
<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
 
J

Joerg

Jan 1, 1970
0
Paul said:


Hey, I have a new code name :)

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

[...]

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.
 
Joerg said:
[email protected] 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. ;-)
 
J

Joerg

Jan 1, 1970
0
Joerg said:
[email protected] wrote:
[email protected] 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.
 
Joerg wrote:
[email protected] wrote:
[email protected] 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.
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? ;-)
 
R

rickman

Jan 1, 1970
0
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.
 
R

rickman

Jan 1, 1970
0
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.

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.

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.

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

rickman

Jan 1, 1970
0
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.
 
R

rickman

Jan 1, 1970
0
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*.

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

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.

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

rickman

Jan 1, 1970
0
Joerg wrote:
[email protected] wrote:
[email protected] 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...
 
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.
 
R

rickman

Jan 1, 1970
0
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.

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.
 
[email protected] wrote:
Joerg wrote:
[email protected] wrote:
[email protected] 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.
 
S

Stef

Jan 1, 1970
0
In comp.arch.embedded,
Joerg said:
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.

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

Joerg

Jan 1, 1970
0
Stef said:
In comp.arch.embedded,


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?

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

Joerg

Jan 1, 1970
0
rickman said:
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.
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.
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" :)
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.

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