Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #13136 > unrolled thread
| Started by | Joerg <invalid@invalid.invalid> |
|---|---|
| First post | 2013-08-19 13:14 -0700 |
| Last post | 2013-09-02 22:27 +0200 |
| Articles | 20 on this page of 146 — 17 participants |
Back to article view | Back to comp.arch.embedded
AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-08-19 13:14 -0700
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-08-20 20:16 +0100
Re: AREF bypass capacitance on ATMega2560? Vladimir Vassilevsky <nospam@nowhere.com> - 2013-08-21 14:47 -0500
Re: AREF bypass capacitance on ATMega2560? Jim Stewart <jstewart@jkmicro.com> - 2013-08-21 13:18 -0700
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-08-21 16:38 -0700
Re: AREF bypass capacitance on ATMega2560? "Tim Williams" <tmoranwms@charter.net> - 2013-08-21 21:30 -0500
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-08-22 10:51 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-06 16:26 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-06 13:33 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-06 17:12 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-06 16:10 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-06 23:59 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 08:10 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:03 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 10:59 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 14:54 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 12:39 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 16:44 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 14:48 -0700
Re: AREF bypass capacitance on ATMega2560? "Tim Williams" <tmoranwms@charter.net> - 2013-09-07 17:10 -0500
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 15:34 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-08 00:57 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 16:56 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-09 17:07 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 10:19 -0700
Re: AREF bypass capacitance on ATMega2560? Paul <paul@pcserviceselectronics.co.uk> - 2013-09-09 20:27 +0100
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 12:55 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-11 09:44 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 07:27 -0700
Re: AREF bypass capacitance on ATMega2560? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-09-13 12:42 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-14 11:56 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 19:38 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 17:39 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 23:20 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 07:41 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-07 11:17 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:23 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:19 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 14:03 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 19:42 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-08 17:18 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-09 13:13 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 20:21 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-10 23:42 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-07 09:24 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 10:00 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-07 11:32 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:35 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:30 -0400
Re: AREF bypass capacitance on ATMega2560? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2013-09-09 09:56 -0400
Re: AREF bypass capacitance on ATMega2560? Robert Wessel <robertwessel2@yahoo.com> - 2013-09-12 11:50 -0500
Re: AREF bypass capacitance on ATMega2560? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2013-09-12 15:06 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-12 14:57 +0200
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 00:21 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 14:08 +0200
Re: AREF bypass capacitance on ATMega2560? Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-13 15:15 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 11:46 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 18:43 +0200
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 19:14 +0200
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 15:26 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 15:24 -0400
Re: AREF bypass capacitance on ATMega2560? David Brown <david.brown@removethis.hesbynett.no> - 2013-09-13 20:22 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 09:32 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 13:44 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 12:46 -0700
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 13:33 -0700
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 13:46 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 17:05 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 15:23 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 19:02 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 16:45 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 23:16 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 08:05 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 14:27 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 12:56 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:07 -0400
Re: AREF bypass capacitance on ATMega2560? Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-09-11 10:05 +0100
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 07:49 -0700
Re: AREF bypass capacitance on ATMega2560? Paul <paul@pcserviceselectronics.co.uk> - 2013-09-11 16:54 +0100
Re: AREF bypass capacitance on ATMega2560? "Tim Williams" <tmoranwms@charter.net> - 2013-09-11 11:25 -0500
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 09:49 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:40 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:38 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 09:34 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 14:29 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 13:01 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 16:22 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:09 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 16:15 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 14:20 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 18:15 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 15:57 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 19:46 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-08 17:15 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 20:20 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 07:17 -0700
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 12:17 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-09 19:30 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-09 16:38 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-10 14:02 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:41 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-11 00:04 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-11 07:53 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-11 21:50 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 09:58 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-12 18:54 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-12 16:17 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 10:03 -0700
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-12 19:24 +0200
Re: AREF bypass capacitance on ATMega2560? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-12 20:38 +0300
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 11:23 -0700
Re: AREF bypass capacitance on ATMega2560? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-12 22:36 +0300
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 12:41 -0700
Re: AREF bypass capacitance on ATMega2560? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2013-09-12 23:08 +0300
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 11:19 -0700
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-12 18:59 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 13:00 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-14 12:05 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-12 16:03 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-12 14:42 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-13 00:24 -0400
Re: AREF bypass capacitance on ATMega2560? Piotr Wyderski <peter.pan@neverland.mil> - 2013-09-13 14:27 +0200
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-14 12:07 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-15 02:26 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-15 09:51 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-13 20:06 -0400
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 16:50 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 14:33 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 19:07 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-07 16:31 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 23:38 -0400
Re: AREF bypass capacitance on ATMega2560? Paul Rubin <no.email@nospam.invalid> - 2013-09-08 20:19 -0700
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:36 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:46 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 11:36 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-08 09:04 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 13:42 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-08 19:04 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-08 07:29 -0400
Re: AREF bypass capacitance on ATMega2560? John Devereux <john@devereux.me.uk> - 2013-09-09 08:56 +0100
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-10 23:54 -0400
Re: AREF bypass capacitance on ATMega2560? krw@attt.bizz - 2013-09-08 16:24 -0400
Re: AREF bypass capacitance on ATMega2560? Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> - 2013-09-07 20:11 +0200
Re: AREF bypass capacitance on ATMega2560? rickman <gnuarm@gmail.com> - 2013-09-07 15:06 -0400
Re: AREF bypass capacitance on ATMega2560? Joerg <invalid@invalid.invalid> - 2013-09-07 12:54 -0700
Re: AREF bypass capacitance on ATMega2560? Ulf Samuelsson <ulf_samuelsson@invalid.telia.com> - 2013-09-02 22:27 +0200
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 15:34 -0700 |
| Message-ID | <b91nv5F5t7nU1@mid.individual.net> |
| In reply to | #13365 |
Tim Williams wrote: > "Joerg" <invalid@invalid.invalid> wrote in message > news:b91lacF5bvnU1@mid.individual.net... >> One other challenge that needs to be met in most of my cases is >> longevity of the design. A FPGA would have to remain available for more >> than just a few years. For example, one of my uC-based designs from the >> mid 90's is still in production. Since I kind of had a hunch that this >> would happen I used an 8051 family uC. Is there something similar in the >> world of FPGA? > > Interjecting what little experience I have here; > > MAX7000s are still available, and they were introduced in 1995; > http://www.altera.com/devices/cpld/max-about/max-about.html > although I think they've finally gone out of stock (not that you'd want to > use them, they also guzzle power like they're NMOS). > > FLEX 10K FPGAs don't appear on their website, but they're still quite > available. Can't seem to find when they were introduced? I'm seeing > documents since at least 1996 referencing them. > Ok, sorry, forgot to say that I never use that manufacturer. > At least between the big two (Altera that I know of, and I would assume > Xilinx too), FPGAs look to have excellent support over time. > > And VHDL doesn't age. The library blocks might, but I'd be willing to > guess that those are synthesized as well, so as long as your toolchain > supports whatever code format, you can migrate chips easily when they do > finally die. > But the minute a footprint changes or you have to re-compile you are screwed in some heavily regulated markets. > And really, if you have to support something for over 20 years, it's > probably time it does die and gets a redesign. ... 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. You also need to support very old legacy equipment with type-certified spare parts and for those few sales you really don't want a re-cert. Just think about the DC-3 which is still in service. Some of those are over 60 years old. Can be worse with elevators. We have a company near here that sometimes has to support elevators that are over a century old. > ... Like that VAX or whatever > it was NASA's still supporting. > 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". -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> |
|---|---|
| Date | 2013-09-08 00:57 +0200 |
| Message-ID | <67c36$522baf5d$5f6173bc$18503@abuse.newsxs.nl> |
| In reply to | #13367 |
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. > > 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. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Antonym, n.: The opposite of the word you're trying to think of.
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 16:56 -0700 |
| Message-ID | <b91sp9F6pktU1@mid.individual.net> |
| In reply to | #13368 |
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. 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". 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. 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. >> 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. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> |
|---|---|
| Date | 2013-09-09 17:07 +0200 |
| Message-ID | <4e395$522de425$5f6173bc$2070@abuse.newsxs.nl> |
| In reply to | #13374 |
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
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-09 10:19 -0700 |
| Message-ID | <b96e9jF51t3U1@mid.individual.net> |
| In reply to | #13429 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2013-09-09 20:27 +0100 |
| Message-ID | <MPG.2c9831883b67841989778@172.16.0.1> |
| In reply to | #13433 |
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
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-09 12:55 -0700 |
| Message-ID | <b96ndtF70k7U1@mid.individual.net> |
| In reply to | #13438 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> |
|---|---|
| Date | 2013-09-11 09:44 +0200 |
| Message-ID | <8a176$52301f63$5f6173bc$26345@abuse.newsxs.nl> |
| In reply to | #13433 |
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
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-11 07:27 -0700 |
| Message-ID | <b9bcvcF5scqU1@mid.individual.net> |
| In reply to | #13458 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> |
|---|---|
| Date | 2013-09-13 12:42 +0200 |
| Message-ID | <d5e13$5232ebfe$5f6173bc$13970@abuse.newsxs.nl> |
| In reply to | #13460 |
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: >>>>> 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? There are cases where a hardware limiter is an option, there are cases where that's not an option. In your example above the biggest risk is however the nurse calculating and setting the dose, but that's another part of the risk analysis. ;-) >> <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. Yes, there are always chances and you have to weigh the risks. Making sure all units pass EMC testing can only be done by fully testing each unit under all cirumstances. Which is ofcourse impossible. Your barcode scanner example is unfortunate. But such a scanner could also change it's behaviour on scanning different codes and lighting conditions. Did you perform EMC testing with all available barcodes and forseeable lighting conditions? > 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. Yes , if the agency or customer demands re-testing, there's nothing you can do but re-test. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) She asked me, "What's your sign?" I blinked and answered "Neon," I thought I'd blow her mind...
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-14 11:56 -0700 |
| Message-ID | <b9jpr7FsgvdU1@mid.individual.net> |
| In reply to | #13534 |
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 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. > > Yes, there are always chances and you have to weigh the risks. Making > sure all units pass EMC testing can only be done by fully testing each > unit under all cirumstances. Which is ofcourse impossible. > Some companies EMC-test every machine that leaves production though. > Your barcode scanner example is unfortunate. But such a scanner could > also change it's behaviour on scanning different codes and lighting > conditions. Did you perform EMC testing with all available barcodes > and forseeable lighting conditions? > That usually isn't necessary. I told the client to get lots of different new readers, and fast. They did that and it turned out that many that were claimed as "class B" failed majorly. One didn't and it had so much margin that it wasn't needed to test it under lots of conditions. I took it apart to make sure that the designers had done a good job. [...] -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 19:38 -0400 |
| Message-ID | <l0gdf2$vgk$1@dont-email.me> |
| In reply to | #13364 |
On 9/7/2013 5:48 PM, Joerg wrote: > rickman wrote: >> On 9/7/2013 3:39 PM, Joerg wrote: >>> rickman wrote: >>>> On 9/7/2013 1:59 PM, Joerg wrote: >>>>> rickman wrote: >>>>>> On 9/7/2013 11:10 AM, Joerg wrote: >>>>>>> For example, this: >>>>>>> >>>>>>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf >>>>>> >>>>>> I don't see it for $3. Did you get a quote for your project? TI says >>>>>> it is $5 to $8 at qty 1k depending on the flavor. You still need >>>>>> to add >>>>>> Flash. >>>>>> >>>>> >>>>> 1k qty is $3.67 at Digikey: >>>>> >>>>> http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713 >>>>> >>>>> >>>> >>>> Not the same part pal. You're trying to pull a fast one on me? Are we >>>> talking about the TMS320C5535 with "tons" of memory or the TMS320C5532 >>>> with *much* less memory? >>>> >>> >>> It doesn't have the single access RAM but it does have 64k dual access >>> RAM. That's a lot of RAM in embedded. >> >> You do this often. Start talking about one thing and shift the context >> to another. ... > > > I didn't. I said it is a DSP with large memory, which it is. You first give a part, the C5535, as the chip with big memory, then it becomes the C5532 which is less memory and less expensive. I can't tell what you are talking about when the subject changes. >> ... Projects have design requirements. I often am able to meet >> my design requirements with an FPGA and no MCU. I often can't say the >> opposite, being able to use an MCU without the FPGA. >> >> >>>>> $3.02 with 12wks leadtime at Arrow: >>>>> >>>>> http://components.arrow.com/part/detail/51425505S8988412N7713?region=na >>>>> >>>>> ROM is included. >>>> >>>> ROM is not Flash.. is it? Are you thinking in terms of a mask ROM? >>>> >>> >>> You can use the bootloader or OTP your own bootloader if you don't want >>> to store your programming in ROM. In most situations this is part of a >>> larger computerized system from where it can download its programming. >> >> That's a different wrinkle. It is common to have a micro load an FPGA, >> many don't contain their own Flash. But I haven't seen this done with >> DSPs as often and almost never with MCUs. But if that works for your >> project, great. You certainly wouldn't have a problem loading an FPGA >> then. >> > > The fact that most FPGA don't have flash is fine ... but ... there must > be a decent bootloader inside. In one of the upcoming projects it must > be able to bootload via USB. So the device must wake up with a certain > minimum in brain functionality to handle the USB stuff. With FPGA that > can become a challenge unless you provide a serial memory device (which > adds cost). No, you won't find any FPGAs which can wake up talking over USB. But you will find FPGAs with internal Flash if you wish to design a USB bootloader. >>>>>>>> ... It has been a while since I looked >>>>>>>> hard at DSP chips, but I don't recall any I would call remotely >>>>>>>> "big" >>>>>>>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>>>>>>> start somewhere around $20 the last time I looked and that requires >>>>>>>> all >>>>>>>> memory and I/O to be separate. The smaller DSP chips that you >>>>>>>> can get >>>>>>>> for the $3 range are not "big" in any sense and only a very few of >>>>>>>> them >>>>>>>> include Flash memory. So you still need another chip. >>>>>>>> >>>>>>> >>>>>>> It has tons of memory on board. >>>>>> >>>>>> Yes, and many FPGAs have "tons" of memory on board although not for >>>>>> $3... but then this isn't a $3 part either... >>>>>> >>>>> >>>>> It is a $3 part. See above. >>>> >>>> No, you need to pick a part number and stick with it. >>>> >>> >>> I gave a part number. Still waiting for your $3 FPGA part number :-) >> >> Actually you gave me two part numbers, one for $5 and one for just over >> $3. What's your point? I gave you info to find the iCE40 line. Xilinx >> also makes FPGAs that are very affordable and does Altera and Lattice. >> > > Both of the ones I gave you are $3. The DSP costs $3.02 and the MSP430 > is $3.09. These are over-the-counter no-haggle prices. Can a $3 iCE40 > device emulate a TMS320 or a big MSP430? I can't tell because I don't > know this Lattice series and I am not an FPGA expert. But it sure looks > like they'd have a hard time. No, the C5535 part is not $3. That is what I mean by two part numbers. >> I have already explained that I would never do a design in an FPGA to >> wholly incorporate a DSP or MCU. That would be absurd. So why do you >> keep asking about that? >> > > Because you wrote yesterday, quote "For $3 however, you can get a chip > large enough for a CPU (with math) and room for your special logic". I said "a CPU" not "any CPU". I never said it would duplicate a commercial device. I'm talking about function. >> Depending on your design requirements there are any number of FPGAs that >> will do the job and some may be $3. What are your design requirements? >> > > As I said, I do not have any hammered out ones yet but it'll come. This > was just about you $3 claim. So I gave some examples of devices that > cost $3. Yes, and there are FPGAs in that price range which can be used to implement a CPU plus other logic. >> I understand the concept of work that can't be moved. You don't need to >> continue to explain that. I was asking why you said most of your word >> didn't have that requirement and yet you still were debating the point. >> Now I get it, you are talking about two different things, work that can >> be moved and work that can't be moved. >> > > Yup. Hence the need for availability of local programmer talent. Less > local availability means potential problems. That is because (where > possible) I like to use architectures I am familiar with. > > Programmer talent means longterm. For example, if a client has an issue > with an 8051 design long after the original programmer has moved on I > could find programmers within a 10-mile radius. Try that with an FPGA. > In San Jose it may be possible but not out here. I can't speak of your environment. I know my friend of many years stayed away from FPGAs in spite of the fact that he is a very capable designer. He finally paid me for a week of FPGA design work which I then turned over to him and helped him get started with HDL. It's not hard at all. You don't really need anyone special. That is the sort of thinking I am trying to dispel. Another example. A software designer came to a newsgroup looking for info on programming FPGAs. He used the mindset of a software guy and wanted to do a "hello world" program. We tried to explain to him that hardware isn't software and HDL isn't C. But he persisted and I gave him advice over a week or so. I tried to turn it into a consulting gig but his bosses didn't want to pay the bucks. He ended up doing just fine with his software mindset and convinced his boss to pay me $500 over my protests. I cashed the check when it came. The point is that FPGAs are not so hard that you need a unique talent to design them. That may have been true 10+ years ago, but they are very mainstream now and much easier to work with. I bet even *you* could do an FPGA design, lol. I don't care where you are located, if you can't find an FPGA designer, you aren't looking very hard. >>>> Not sure what the requirements are for your CODEC, but I have been using >>>> the AKM parts with good results. Minimal or *no* programming, >>>> configuration is done by a small number of select pins, very simple. I >>>> have yet to find another one as small, AK4552, AK4556. >>>> >>> >>> Plus their prices are quite good. >> >> Which, AKM or the other? I'd like to think I can get a CD quality CODEC >> for $3 from nearly anyone. I mainly picked AKM because of the size, 6x6 >> mm without going to a microBGA. >> > > AKM has good prices. Ok. I have no complaints on prices. Their lead time can be a problem. I had a conversation, disti, manufacturers guy and me. I was complaining about a 14 week lead time and he bragged that a 14 week lead time was *good*. I give my customers a 10 week lead time... see the problem? Digikey sell them now so it is not such an issue. I even ended up speaking with a buyer or planner who was coordinating the shipment of an order last spring. Once you reach them they are very nice. >> High 10's or low 10's. Up to say, 20 or 30 ksps is easy to do in an >> FPGA with decent resolution, 12 bits. Getting 16 bits is harder, I've >> not tried it, but should be possible. >> > > Mostly I need 40-50ksps. But 20 is often ok. I haven't done 12 bits at 50 ksps, but I expect it is doable. Just cross the t's and dot the i's. >> I was looking at using a LVDS input for a comparator and Xilinx did it >> in a demo of a SDR. They are very short on details, but they talk about >> 1 mV on the input. I know that's not anything special, I'm hoping to do >> better, much better. >> > > If you can keep substrate noise in check it could work. Try to remain > fully differential as much as you can. Not sure if FPGA design suites > still let you hand-place blocks so you can avoid making a big racket > right next to the ADC area. *Everything* in an FPGA makes noise, it's all digital. Yes you can hand place logic if you want. That is the sort of thing best done at the end if possible when you are ready to finalize the chip. But what would you have in an FPGA design that makes more noise than anything else? Each logic block is very small and has a pretty low power consumption. It would be the I/O that has significant power spikes and you have total control over that. >>> I wasn't referring to a specific project, just your claim that FPGA can >>> do the same job as processors at the same price. >> >> Yes, that is my claim. The obvious exception is when some feature is >> needed that just isn't available in an FPGA. I'm not saying *every* >> project can be done better in an FPGA. I'm saying that designers tend >> to just not consider FPGAs when they are often viable solutions. >> > > In most of my apps I need much of the functionality that a decent uC > affords, like the $3 device from the MSP430 series I mentioned. If you need 256 kB of memory then you won't reach a $3 price tag. If you need something more like the low end processor you mentioned that might be doable in the low end FPGAs. They have block RAM, but it scales with the size of the chip. When you have a specific requirement we can look and see what matches. >>> One project will probably require something of the caliber of a >>> MSP430F6733. Whether this kind or a DSP, what is key is that we are able >>> to use pre-coooked library routines. In my case for complex (I/Q) signal >>> processing, FFT, non-linear filtering and so on. Sometimes legacy >>> routines must be kept and in an FPGA that would require an IP block that >>> can emulate the respective processor well enough. >> >> Ok, that is likely a no-go. If you really want to emulate a DSP chip >> then an FPGA is not likely to be a useful way to proceed. Wanting to >> run DSP precompiled library code is a bit of an extreme requirement. If >> the customer wants a DSP, then by all means give them a DSP. But don't >> automatically exclude an FPGA from the task. >> > > Sometimes it would also be ok if there were similar pre-cooked FPGA > routines (I/Q signal processing, non-linear filters et cetera). There are design tools that will generate function blocks, filters, etc. I have not had to deal with them. The DSP stuff I have done I just coded up in HDL. >>> But what I see most is this: The respective client has in-house talent >>> for writing code. They are familiar with a particular architecture, have >>> a vast arsenal of re-usable code built up, and naturally they do not >>> wish to give this up. If it's a dsPIC like last year, then that goes in >>> there. If it's Atmel and MSP430 like this year, then that is used. Has >>> to be, the customer is king. >> >> Yeah, well that is a deal killer for *any* other alternative. That is >> not related to what I was saying. My point is that if you don't have >> any specific requirement that dictates the use of a given chip, an FPGA >> has as good a chance at meeting the requirements as an MCU or DSP. In >> fact, FPGAs are what get used when DSPs aren't fast enough. My point is >> you don't have to limit them to the high end. They also do very well at >> the low end. >> > > No disagreement there, programables have come a long way since the days > of GALs. Which I never used because they were expensive power guzzlers. > > One other challenge that needs to be met in most of my cases is > longevity of the design. A FPGA would have to remain available for more > than just a few years. For example, one of my uC-based designs from the > mid 90's is still in production. Since I kind of had a hunch that this > would happen I used an 8051 family uC. Is there something similar in the > world of FPGA? That is typically not a problem, but pick a device that is relatively new to start with. The vendors are *all* about their latest and greatest products. I guess they need a critical mass of design wins up front which they get revenue from over the life of the part. So they push the newest stuff and let you ask about the older parts. I don't think there is anything like the 8051 other than the 22V10 perhaps. The 8051 is an anomaly in the MCU world. You won't see a DSP equivalent for example. So far users typically want more, more, more from FPGAs. So a stationary design would not have a market. Even though there are ever larger markets for low end parts, they keep redesigning them to make them cheaper. When they do that they add incompatibility because it doesn't affect the bulk of the users, recompile and you are good to go. But pin compatibility, no, that just doesn't exist other than within a single family. Fortunately product life is typically not an issue. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-07 17:39 -0700 |
| Message-ID | <7xli38tacu.fsf@ruckus.brouhaha.com> |
| In reply to | #13372 |
rickman <gnuarm@gmail.com> writes: > The point is that FPGAs are not so hard that you need a unique talent > to design them. That may have been true 10+ years ago, but they are > very mainstream now and much easier to work with. There still appears to be a complete absence of FOSS toolchains, at least for any current interesting parts. >> like the $3 device from the MSP430 series I mentioned. > If you need 256 kB of memory then you won't reach a $3 price tag. That part (MSP430F6733) has 64k of flash and 4k of ram, not out of reach. It does have some nice other features that may be hard to duplicate with an fpga, like quite low power consumption: http://www.ti.com/product/msp430f6733
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 23:20 -0400 |
| Message-ID | <l0gqem$jbq$1@dont-email.me> |
| In reply to | #13375 |
On 9/7/2013 8:39 PM, Paul Rubin wrote: > rickman<gnuarm@gmail.com> writes: >> The point is that FPGAs are not so hard that you need a unique talent >> to design them. That may have been true 10+ years ago, but they are >> very mainstream now and much easier to work with. > > There still appears to be a complete absence of FOSS toolchains, at > least for any current interesting parts. There are no FOSS bit stream generators and there never will be. If that is a no-go for you, then you will never use FPGAs from any of the existing companies. >>> like the $3 device from the MSP430 series I mentioned. >> If you need 256 kB of memory then you won't reach a $3 price tag. > > That part (MSP430F6733) has 64k of flash and 4k of ram, not out of > reach. It does have some nice other features that may be hard to > duplicate with an fpga, like quite low power consumption: > http://www.ti.com/product/msp430f6733 You have been reading old books. All FPGAs aren't power hungry. Check the Lattice site for iCE40 line. Very low power. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 07:41 -0700 |
| Message-ID | <b93gkkFgo0sU1@mid.individual.net> |
| In reply to | #13372 |
rickman wrote: > On 9/7/2013 5:48 PM, Joerg wrote: >> rickman wrote: >>> On 9/7/2013 3:39 PM, Joerg wrote: >>>> rickman wrote: >>>>> On 9/7/2013 1:59 PM, Joerg wrote: >>>>>> rickman wrote: >>>>>>> On 9/7/2013 11:10 AM, Joerg wrote: >>>>>>>> For example, this: >>>>>>>> >>>>>>>> http://www.ti.com/lit/ds/symlink/tms320c5535.pdf >>>>>>> >>>>>>> I don't see it for $3. Did you get a quote for your project? TI >>>>>>> says >>>>>>> it is $5 to $8 at qty 1k depending on the flavor. You still need >>>>>>> to add >>>>>>> Flash. >>>>>>> >>>>>> >>>>>> 1k qty is $3.67 at Digikey: >>>>>> >>>>>> http://www.digikey.com/product-detail/en/TMS320C5532AZHH10/296-32741-ND/2749713 >>>>>> >>>>>> >>>>>> >>>>> >>>>> Not the same part pal. You're trying to pull a fast one on me? >>>>> Are we >>>>> talking about the TMS320C5535 with "tons" of memory or the TMS320C5532 >>>>> with *much* less memory? >>>>> >>>> >>>> It doesn't have the single access RAM but it does have 64k dual access >>>> RAM. That's a lot of RAM in embedded. >>> >>> You do this often. Start talking about one thing and shift the context >>> to another. ... >> >> >> I didn't. I said it is a DSP with large memory, which it is. > > You first give a part, the C5535, as the chip with big memory, then it > becomes the C5532 which is less memory and less expensive. I can't tell > what you are talking about when the subject changes. > There are no subject changes. Did you even click on the link? The datasheet is for the _whole_ series, _including_ the 5532. It clearly says so in the first line on the first page. [...] > >> The fact that most FPGA don't have flash is fine ... but ... there must >> be a decent bootloader inside. In one of the upcoming projects it must >> be able to bootload via USB. So the device must wake up with a certain >> minimum in brain functionality to handle the USB stuff. With FPGA that >> can become a challenge unless you provide a serial memory device (which >> adds cost). > > No, you won't find any FPGAs which can wake up talking over USB. But > you will find FPGAs with internal Flash if you wish to design a USB > bootloader. > Then one of those would be required I guess. USB connectivity is important these days. > >>>>>>>>> ... It has been a while since I >>>>>>>>> looked >>>>>>>>> hard at DSP chips, but I don't recall any I would call remotely >>>>>>>>> "big" >>>>>>>>> for $3. The TI chips that would be "big" are the TMS6xxx line >>>>>>>>> which >>>>>>>>> start somewhere around $20 the last time I looked and that >>>>>>>>> requires >>>>>>>>> all >>>>>>>>> memory and I/O to be separate. The smaller DSP chips that you >>>>>>>>> can get >>>>>>>>> for the $3 range are not "big" in any sense and only a very few of >>>>>>>>> them >>>>>>>>> include Flash memory. So you still need another chip. >>>>>>>>> >>>>>>>> >>>>>>>> It has tons of memory on board. >>>>>>> >>>>>>> Yes, and many FPGAs have "tons" of memory on board although not for >>>>>>> $3... but then this isn't a $3 part either... >>>>>>> >>>>>> >>>>>> It is a $3 part. See above. >>>>> >>>>> No, you need to pick a part number and stick with it. >>>>> >>>> >>>> I gave a part number. Still waiting for your $3 FPGA part number :-) >>> >>> Actually you gave me two part numbers, one for $5 and one for just over >>> $3. What's your point? I gave you info to find the iCE40 line. Xilinx >>> also makes FPGAs that are very affordable and does Altera and Lattice. >>> >> >> Both of the ones I gave you are $3. The DSP costs $3.02 and the MSP430 >> is $3.09. These are over-the-counter no-haggle prices. Can a $3 iCE40 >> device emulate a TMS320 or a big MSP430? I can't tell because I don't >> know this Lattice series and I am not an FPGA expert. But it sure looks >> like they'd have a hard time. > > No, the C5535 part is not $3. That is what I mean by two part numbers. > The C5532 is $3. That is the part in the Digikey link I gave. Datasheets are often for a whole series, economy to deluxe. I thought that became clear when you looked at the datasheet. [...] >>> Depending on your design requirements there are any number of FPGAs that >>> will do the job and some may be $3. What are your design requirements? >>> >> >> As I said, I do not have any hammered out ones yet but it'll come. This >> was just about you $3 claim. So I gave some examples of devices that >> cost $3. > > Yes, and there are FPGAs in that price range which can be used to > implement a CPU plus other logic. > Well, yeah, but we were talking about an appropriate and similarly classed CPU, not a 30c 8-bitter from China. > >>> I understand the concept of work that can't be moved. You don't need to >>> continue to explain that. I was asking why you said most of your word >>> didn't have that requirement and yet you still were debating the point. >>> Now I get it, you are talking about two different things, work that >>> can >>> be moved and work that can't be moved. >>> >> >> Yup. Hence the need for availability of local programmer talent. Less >> local availability means potential problems. That is because (where >> possible) I like to use architectures I am familiar with. >> >> Programmer talent means longterm. For example, if a client has an issue >> with an 8051 design long after the original programmer has moved on I >> could find programmers within a 10-mile radius. Try that with an FPGA. >> In San Jose it may be possible but not out here. > > I can't speak of your environment. I know my friend of many years > stayed away from FPGAs in spite of the fact that he is a very capable > designer. He finally paid me for a week of FPGA design work which I > then turned over to him and helped him get started with HDL. It's not > hard at all. You don't really need anyone special. That is the sort of > thinking I am trying to dispel. > For you it may be easy. I am somehow not the kind of guy that easily learns programming languages. Human languages, yes. Really weird analog or RF tricks, yes. C, C++ or HDL, not really. I can read through code to some extent but it is like having to plow through a document in Portuguese (which I had to do). > Another example. A software designer came to a newsgroup looking for > info on programming FPGAs. He used the mindset of a software guy and > wanted to do a "hello world" program. We tried to explain to him that > hardware isn't software and HDL isn't C. But he persisted and I gave > him advice over a week or so. I tried to turn it into a consulting gig > but his bosses didn't want to pay the bucks. He ended up doing just > fine with his software mindset and convinced his boss to pay me $500 > over my protests. I cashed the check when it came. > > The point is that FPGAs are not so hard that you need a unique talent to > design them. That may have been true 10+ years ago, but they are very > mainstream now and much easier to work with. I bet even *you* could do > an FPGA design, lol. > Maybe, but it'll take a while. I did some uC programming though so maybe that helps. > I don't care where you are located, if you can't find an FPGA designer, > you aren't looking very hard. > In Cameron Park? Most if not all FPGA guys out here work for Intel, they won't have time for consulting gigs and may not even be allowed to do it. > >>>>> Not sure what the requirements are for your CODEC, but I have been >>>>> using >>>>> the AKM parts with good results. Minimal or *no* programming, >>>>> configuration is done by a small number of select pins, very >>>>> simple. I >>>>> have yet to find another one as small, AK4552, AK4556. >>>>> >>>> >>>> Plus their prices are quite good. >>> >>> Which, AKM or the other? I'd like to think I can get a CD quality CODEC >>> for $3 from nearly anyone. I mainly picked AKM because of the size, 6x6 >>> mm without going to a microBGA. >>> >> >> AKM has good prices. > > Ok. I have no complaints on prices. Their lead time can be a problem. > I had a conversation, disti, manufacturers guy and me. I was > complaining about a 14 week lead time and he bragged that a 14 week lead > time was *good*. I give my customers a 10 week lead time... see the > problem? Digikey sell them now so it is not such an issue. I even > ended up speaking with a buyer or planner who was coordinating the > shipment of an order last spring. Once you reach them they are very nice. > Yes, Digikey has them. My rule is that if Digikey doesn't have something I try to avoid the part. Except for Coilcraft. > >>> High 10's or low 10's. Up to say, 20 or 30 ksps is easy to do in an >>> FPGA with decent resolution, 12 bits. Getting 16 bits is harder, I've >>> not tried it, but should be possible. >>> >> >> Mostly I need 40-50ksps. But 20 is often ok. > > I haven't done 12 bits at 50 ksps, but I expect it is doable. Just > cross the t's and dot the i's. > It's not just getting it done in principle but also to yield at least 10.5bits ENOB or so at that speed. Even with uC that can be a challenge. > >>> I was looking at using a LVDS input for a comparator and Xilinx did it >>> in a demo of a SDR. They are very short on details, but they talk about >>> 1 mV on the input. I know that's not anything special, I'm hoping to do >>> better, much better. >>> >> >> If you can keep substrate noise in check it could work. Try to remain >> fully differential as much as you can. Not sure if FPGA design suites >> still let you hand-place blocks so you can avoid making a big racket >> right next to the ADC area. > > *Everything* in an FPGA makes noise, it's all digital. Yes you can hand > place logic if you want. That is the sort of thing best done at the end > if possible when you are ready to finalize the chip. But what would you > have in an FPGA design that makes more noise than anything else? Each > logic block is very small and has a pretty low power consumption. It > would be the I/O that has significant power spikes and you have total > control over that. > What sometimes causes issues are FLL or PLL in there to create the master clock. But I only know that from uC. With FPGA we had EMI problems and sometimes they required unorthodox measures. Had the same thing with a discrete RAM bank: We had to run other parts in the FPGA as dummy loads, ping-pong style, to reduce the noise energy. Their FPGA guy almost threw me out of his cubicle when I suggested that but then it worked. He bought me a coffee at the cantina :-) > >>>> I wasn't referring to a specific project, just your claim that FPGA can >>>> do the same job as processors at the same price. >>> >>> Yes, that is my claim. The obvious exception is when some feature is >>> needed that just isn't available in an FPGA. I'm not saying *every* >>> project can be done better in an FPGA. I'm saying that designers tend >>> to just not consider FPGAs when they are often viable solutions. >>> >> >> In most of my apps I need much of the functionality that a decent uC >> affords, like the $3 device from the MSP430 series I mentioned. > > If you need 256 kB of memory then you won't reach a $3 price tag. If > you need something more like the low end processor you mentioned that > might be doable in the low end FPGAs. They have block RAM, but it > scales with the size of the chip. When you have a specific requirement > we can look and see what matches. > It'll be a while until I know for sure. Because whether or not I need some massive compensator routine depends on the performance of a complicated mechanical part that we won't have before spring next year. [...] >>>> But what I see most is this: The respective client has in-house talent >>>> for writing code. They are familiar with a particular architecture, >>>> have >>>> a vast arsenal of re-usable code built up, and naturally they do not >>>> wish to give this up. If it's a dsPIC like last year, then that goes in >>>> there. If it's Atmel and MSP430 like this year, then that is used. Has >>>> to be, the customer is king. >>> >>> Yeah, well that is a deal killer for *any* other alternative. That is >>> not related to what I was saying. My point is that if you don't have >>> any specific requirement that dictates the use of a given chip, an FPGA >>> has as good a chance at meeting the requirements as an MCU or DSP. In >>> fact, FPGAs are what get used when DSPs aren't fast enough. My point is >>> you don't have to limit them to the high end. They also do very well at >>> the low end. >>> >> >> No disagreement there, programables have come a long way since the days >> of GALs. Which I never used because they were expensive power guzzlers. >> >> One other challenge that needs to be met in most of my cases is >> longevity of the design. A FPGA would have to remain available for more >> than just a few years. For example, one of my uC-based designs from the >> mid 90's is still in production. Since I kind of had a hunch that this >> would happen I used an 8051 family uC. Is there something similar in the >> world of FPGA? > > That is typically not a problem, but pick a device that is relatively > new to start with. The vendors are *all* about their latest and > greatest products. I guess they need a critical mass of design wins up > front which they get revenue from over the life of the part. So they > push the newest stuff and let you ask about the older parts. > As long as they do not require a formal RFQ from the (not yet existing) purchasing department of the company. Then I'd walk. No kidding, this happened on a programmable device in the 90's. > I don't think there is anything like the 8051 other than the 22V10 > perhaps. The 8051 is an anomaly in the MCU world. ... Not an anomaly, it was bound to happen. There are many areas where 2nd source is a must. The usual paranoia by manufacturers that this puts downward pressure on the price was debunked by this very uC. It is the only gripe I have with it, that it is expensive compared to more modern ones. But you have no choice if there must be a 2nd source and they know it. So it was also not very surprising that "Hayabusa editions" came out, screaming along around 100MHz. > ... You won't see a DSP > equivalent for example. So far users typically want more, more, more > from FPGAs. So a stationary design would not have a market. Even > though there are ever larger markets for low end parts, they keep > redesigning them to make them cheaper. When they do that they add > incompatibility because it doesn't affect the bulk of the users, > recompile and you are good to go. But pin compatibility, no, that just > doesn't exist other than within a single family. Fortunately product > life is typically not an issue. > It is for me. In the old days we preferred Analog Devices DSP (2110? Forgot the part number) because they were the staple. We just used lots of them per board. Cheap, too. Come to think of it, most of my designs where there was a DSP it cost around $5-10, nowadays they are down to around $3. It's not very expensive anymore but finding a programmer to work locally can be tough. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-07 11:17 -0400 |
| Message-ID | <3bfm29ldsoe1n36flb09hclcgj5tv1gebl@4ax.com> |
| In reply to | #13339 |
On Fri, 06 Sep 2013 23:59:59 -0400, rickman <gnuarm@gmail.com> wrote: >On 9/6/2013 7:10 PM, Joerg wrote: >> rickman wrote: >>> On 9/6/2013 4:33 PM, Joerg wrote: >>>> rickman wrote: >>>>> On 8/22/2013 1:51 PM, Joerg wrote: >>>>>> Tim Williams wrote: >>>>>>> "Joerg"<invalid@invalid.invalid> wrote in message >>>>>>> news:b7l1blFlu93U2@mid.individual.net... >>>>>>>>>> I saw people >>>>>>>>>> using 0.1uF and 0.47uF. The datasheet is silent about stuff like >>>>>>>>>> that, >>>>>>>>>> as usual. >>>>>>>>> It doesn't really matter. >>>>>>>>> >>>>>>>> However, not everyone knows that because they don't say much about >>>>>>>> the >>>>>>>> innards of the chip. It's my first ATMega case, or maybe the 2nd. >>>>>>> >>>>>>> Finally gave up and bit the uC bullet? ;-) >>>>>>> >>>>>> >>>>>> Sometimes you need it. A while ago I even had a switcher design that >>>>>> would have been totally impossible to do without a uC. But it does >>>>>> raise >>>>>> eyebrows if I request timers and port pins and MIPS, probably >>>>>> because of >>>>>> my analog background. "YOU want some of the uC resources? What for?" >>>>> >>>>> Sounds to me like you need FPGA resources moreso than an MCU. Are you >>>>> using the ADC or DAC, guess so or are you using the reference for the >>>>> brownout or something else? DACs are easy in FPGAs, ADCs not as easy. >>>>> Otherwise FPGAs do everything an MCU does plus... >>>>> >>>> >>>> I nearly always need ADC capability. Not for the brownout, I never trust >>>> anything on those chips for that, the POR/BOR/WDT goes external. FPGA >>>> have some downsides, they tend to become large, expensive and sometimes >>>> power-hungry when you need math capability or an MCU core. >>> >>> If your FPGA designs are expensive or power hungry, then you are doing >>> things you can't do in an MCU or you are not using FPGAs properly. They >>> don't need to use any more power than an MCU and in many cases less. >>> They certainly don't need to be significantly more expensive unless you >>> consider every dollar in your designs. At the very low end MCUs can be >>> under $1 and still have reasonable performance. For $1 you can't get >>> much in the way of programmable logic. ... >> >> >> That is often the problem. Sometimes a buck fifty is the pain threshold. >> Not in this ATMega case, the 2560 is very expensive but comes with lots >> of ADC and analog muxes and all that. Things that will cost extra with a >> FPGA solution and eat real estate. >> >> >> For $3 however, you can get a >>> chip large enough for a CPU (with math) and room for your special logic. >>> >> >> For $3 I can get a big DSP. > >What "big" DSP can you get for $3? It has been a while since I looked >hard at DSP chips, but I don't recall any I would call remotely "big" >for $3. The TI chips that would be "big" are the TMS6xxx line which >start somewhere around $20 the last time I looked and that requires all >memory and I/O to be separate. The smaller DSP chips that you can get >for the $3 range are not "big" in any sense and only a very few of them >include Flash memory. So you still need another chip. We pay less than that for the largest of the ADI sigma DSPs. I just received a quote for the smallest CPLD for around $.75. I have use for CPLDs and FPGAs but they're simply too expensive for most of my applications. >Even a "small" FPGA can run rings around a DSP when it comes to >performance. Usually "big" in DSPs means fast and when you want really >fast DSP you use an FPGA with all the parallelism you can handle. DSPs >can't touch FPGAs for speed, even with low power. Comparing the two is silly. Each has its place. <snip> >> What I often find is people only doing Altera or only Xilinx. With uC >> it's a bit easier, a PIC guy can be cajoled into programming an AVR, >> usually. > >I'm totally device agnostic. I have worked with all brands other than >MicroSemi (formerly Actel). I even worked with Lucent which was bought >by Lattice and I believe is still sold and supported (but not the GD XP >line which I had designed into a cash cow product and will have to >redesign now). Ever hear of Concurrent? They were bought by Atmel. >Their devices were followed by the AT40K. I worked with the Concurrent >devices. lol So you can see I go way back. The difference anymore is very small. The only reason I prefer one over the other is software and that takes a back seat to most other variables (in rough order of importance, 1. cost, 2. cost, 3. cost). The one feature that isn't universal is programming modes. This can make a big difference in indirect costs (field upgrade, SKU personalization, etc.) that may not show up directly on the raw BOM. >I've used schematic based tools and both VHDL and Verilog. I've worked >with the vendor's tools and third party tools including the NeoCAD tools >which became Xilinx tools when Xilinx bought them. > >If anyone tells you they only know one brand of FPGA you are talking to >an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >terms of usage. MCUs need all sorts of start up code and peripheral >drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly >have the same features and most of that can be inferred from the HDL so >you never need to look too hard under the hood. Sure, the feature set and peripherals of micros varies widely. We use a variety of SoCs from just about everyone. Since most are settling on ARM, switching from one to the other is pretty simple. Our last port from one manufacturer to the other took a couple of weeks. >In short, there is a lot of FUD about FPGAs. Talk to someone who >doesn't buy into the FUD. The FUD is on both sides. The support costs aren't as low as you pretend. >>>> Of course the beauty of FPGA is that the availability of very fast glue >>>> logic. Most uC are sorely lacking in that domain. >>> >>> Yes, the ideal chip would add a section of FPGA fabric to a conventional >>> MCU and vary the size just as they do the RAM and Flash. I think at >>> this point the problem is cultural. Most FPGA companies are all about >>> the big iron selling for $100 a chip min and the MCU makers don't >>> understand programmable logic. Xilinx and Cypress is good examples. >>> Zync is a very high end solution, great if it matches your problem. PSOC >>> is not a bad idea, but their idea of programmable logic isn't worth much. >>> >>> Give me a good $10 MCU/FPGA combo and I'll design the world! In the >>> meantime I'll be using soft cores. They are a lot easier to program >>> than an MCU anyway. >>> >> >> Things quickly unravel when you start relying on real hardware that is >> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. > >If you really need it all on a single chip, then yes, you won't find >that on so many FPGAs although Microsemi has their Fusion line with >analog. My cash cow uses a single FPGA and a stereo CODEC. That was >smaller than any MCU design because the MCU would still require the >CODEC (CD quality) and some of the control logic and interface could not >be done with any conventional MCU. I had to vary the speed of the CODEC >clock via an ADPLL to synchronize it with an incoming data stream. I >don't know how to do that with an MCU and no logic. But I can do it all >with FPGA logic and no MCU. Nonsense. DSPs are also available with CODECs, as are UCs. >> Last week I reviewed a design with some larger FPGA on there. What I >> found fairly disgusting was how much they had to be babied with the >> power sequencing. uCs don't have that problem. > >If you want to work with the wrong device, then you will find it hard to >work with. There are still single voltage devices on the market. If >this was an old design, most likely it was a Spartan 3 or similar era >device when they (for still unknown reasons) used three, yes, count >them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >solely for the configuration interface which was normally to a 3.3 volt >device! Only from Xilinx... > >If this was a new device, then I guess they picked one based on >something other than ease of use, eh? Don't assume all FPGAs are the same. I thought you just said that there weren't many differences between FPGA manufacturers? >You are aware that there are Flash based FPGAs that don't require the >external Flash chip, right?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 13:23 -0400 |
| Message-ID | <l0fnfe$5sl$1@dont-email.me> |
| In reply to | #13344 |
On 9/7/2013 11:17 AM, krw@attt.bizz wrote: > On Fri, 06 Sep 2013 23:59:59 -0400, rickman<gnuarm@gmail.com> wrote: > >> On 9/6/2013 7:10 PM, Joerg wrote: >>> That is often the problem. Sometimes a buck fifty is the pain threshold. >>> Not in this ATMega case, the 2560 is very expensive but comes with lots >>> of ADC and analog muxes and all that. Things that will cost extra with a >>> FPGA solution and eat real estate. >>> >>> >>> For $3 however, you can get a >>>> chip large enough for a CPU (with math) and room for your special logic. >>>> >>> >>> For $3 I can get a big DSP. >> >> What "big" DSP can you get for $3? It has been a while since I looked >> hard at DSP chips, but I don't recall any I would call remotely "big" >> for $3. The TI chips that would be "big" are the TMS6xxx line which >> start somewhere around $20 the last time I looked and that requires all >> memory and I/O to be separate. The smaller DSP chips that you can get >> for the $3 range are not "big" in any sense and only a very few of them >> include Flash memory. So you still need another chip. > > We pay less than that for the largest of the ADI sigma DSPs. I just > received a quote for the smallest CPLD for around $.75. I have use > for CPLDs and FPGAs but they're simply too expensive for most of my > applications. It seems the prices have come down in recent years, but still, the parts I have seen have no Flash. So you need to add in that cost. But the Sigma parts aren't really general purpose. They are good if you can make you app fit the DSP design, otherwise they aren't much use. I pursued them hard a few years ago until an FAE just threw in the towel and said I couldn't do my app on their part. >> Even a "small" FPGA can run rings around a DSP when it comes to >> performance. Usually "big" in DSPs means fast and when you want really >> fast DSP you use an FPGA with all the parallelism you can handle. DSPs >> can't touch FPGAs for speed, even with low power. > > Comparing the two is silly. Each has its place. That makes no sense. There will always be some designs that a given part is a perfect fit for, but that doesn't mean different devices can't be compared. The question is what is the best fit for a given job. I am hearing some say that FPGAs aren't the best fit and I find they often are a better fit than an MCU. Much of it has to do with mis-information about what FPGAs can and can't do and what is required to make them run. Just read Joerge's post. Much of the stuff he objects to is specific to the individual devices he has worked with. >>> What I often find is people only doing Altera or only Xilinx. With uC >>> it's a bit easier, a PIC guy can be cajoled into programming an AVR, >>> usually. >> >> I'm totally device agnostic. I have worked with all brands other than >> MicroSemi (formerly Actel). I even worked with Lucent which was bought >> by Lattice and I believe is still sold and supported (but not the GD XP >> line which I had designed into a cash cow product and will have to >> redesign now). Ever hear of Concurrent? They were bought by Atmel. >> Their devices were followed by the AT40K. I worked with the Concurrent >> devices. lol So you can see I go way back. > > The difference anymore is very small. The only reason I prefer one > over the other is software and that takes a back seat to most other > variables (in rough order of importance, 1. cost, 2. cost, 3. cost). I have not found a big difference in software. The software is different, but those differences are not important. It all compiles my HDL fine (mostly because they often use the same third party tool vendors) and simulation just works anymore. > The one feature that isn't universal is programming modes. This can > make a big difference in indirect costs (field upgrade, SKU > personalization, etc.) that may not show up directly on the raw BOM. I don't know what devices you work with, but the ones I use are easy to program. >> I've used schematic based tools and both VHDL and Verilog. I've worked >> with the vendor's tools and third party tools including the NeoCAD tools >> which became Xilinx tools when Xilinx bought them. >> >> If anyone tells you they only know one brand of FPGA you are talking to >> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >> terms of usage. MCUs need all sorts of start up code and peripheral >> drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly >> have the same features and most of that can be inferred from the HDL so >> you never need to look too hard under the hood. > > Sure, the feature set and peripherals of micros varies widely. We use > a variety of SoCs from just about everyone. Since most are settling > on ARM, switching from one to the other is pretty simple. Our last > port from one manufacturer to the other took a couple of weeks. The CPU is the easy part to port, the compiler handles that for you. It is the drivers for the I/O that is harder. Their libraries have to have compatible interfaces and every port is a port. With FPGAs, all you need to do to switch between brands is normally a new pin list and timing constraints. The HDL just compiles to suit the new device. It has been a while since I ported between brands but it would make sense if they provide tools to port the timing constraints. That is the only part that might be any work at all. >> In short, there is a lot of FUD about FPGAs. Talk to someone who >> doesn't buy into the FUD. > > The FUD is on both sides. The support costs aren't as low as you > pretend. Care to elaborate? >>> Things quickly unravel when you start relying on real hardware that is >>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. >> >> If you really need it all on a single chip, then yes, you won't find >> that on so many FPGAs although Microsemi has their Fusion line with >> analog. My cash cow uses a single FPGA and a stereo CODEC. That was >> smaller than any MCU design because the MCU would still require the >> CODEC (CD quality) and some of the control logic and interface could not >> be done with any conventional MCU. I had to vary the speed of the CODEC >> clock via an ADPLL to synchronize it with an incoming data stream. I >> don't know how to do that with an MCU and no logic. But I can do it all >> with FPGA logic and no MCU. > > Nonsense. DSPs are also available with CODECs, as are UCs. You can find a small number of DSPs with CD qualitity CODECs and the same for MCUs. I know, I did this search recently. I didn't find much and none that suited my other critera. So the redo of my board will likely have another FPGA on it. I would appreciate a list of the MCUs/DSPs which have stereo CD quality CODECs on chip. The Sigma parts from ADI don't count because their DSPs can *only* be used for certain coding like filters, not general purpose use. >>> Last week I reviewed a design with some larger FPGA on there. What I >>> found fairly disgusting was how much they had to be babied with the >>> power sequencing. uCs don't have that problem. >> >> If you want to work with the wrong device, then you will find it hard to >> work with. There are still single voltage devices on the market. If >> this was an old design, most likely it was a Spartan 3 or similar era >> device when they (for still unknown reasons) used three, yes, count >> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >> solely for the configuration interface which was normally to a 3.3 volt >> device! Only from Xilinx... >> >> If this was a new device, then I guess they picked one based on >> something other than ease of use, eh? Don't assume all FPGAs are the same. > > I thought you just said that there weren't many differences between > FPGA manufacturers? You are mixing apples and oranges. One manufacturer has many different families of FPGAs, no? Some are huge power hungry devices that burn a hole in your board. Others are much lower power and don't burn a hole in your pocketbook either. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 11:19 -0400 |
| Message-ID | <pa4p29dkdi54spblpb5k9ehv7lv31e3v7q@4ax.com> |
| In reply to | #13348 |
On Sat, 07 Sep 2013 13:23:48 -0400, rickman <gnuarm@gmail.com> wrote: >On 9/7/2013 11:17 AM, krw@attt.bizz wrote: >> On Fri, 06 Sep 2013 23:59:59 -0400, rickman<gnuarm@gmail.com> wrote: >> >>> On 9/6/2013 7:10 PM, Joerg wrote: >>>> That is often the problem. Sometimes a buck fifty is the pain threshold. >>>> Not in this ATMega case, the 2560 is very expensive but comes with lots >>>> of ADC and analog muxes and all that. Things that will cost extra with a >>>> FPGA solution and eat real estate. >>>> >>>> >>>> For $3 however, you can get a >>>>> chip large enough for a CPU (with math) and room for your special logic. >>>>> >>>> >>>> For $3 I can get a big DSP. >>> >>> What "big" DSP can you get for $3? It has been a while since I looked >>> hard at DSP chips, but I don't recall any I would call remotely "big" >>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>> start somewhere around $20 the last time I looked and that requires all >>> memory and I/O to be separate. The smaller DSP chips that you can get >>> for the $3 range are not "big" in any sense and only a very few of them >>> include Flash memory. So you still need another chip. >> >> We pay less than that for the largest of the ADI sigma DSPs. I just >> received a quote for the smallest CPLD for around $.75. I have use >> for CPLDs and FPGAs but they're simply too expensive for most of my >> applications. > >It seems the prices have come down in recent years, but still, the parts >I have seen have no Flash. So you need to add in that cost. But the >Sigma parts aren't really general purpose. They are good if you can >make you app fit the DSP design, otherwise they aren't much use. I >pursued them hard a few years ago until an FAE just threw in the towel >and said I couldn't do my app on their part. Good grief. The issue wasn't to show YOU that YOUR application was better in a DSP. Like many FGPA weenies, you're trying to sell a part that has a niche market as the universal hammer. >>> Even a "small" FPGA can run rings around a DSP when it comes to >>> performance. Usually "big" in DSPs means fast and when you want really >>> fast DSP you use an FPGA with all the parallelism you can handle. DSPs >>> can't touch FPGAs for speed, even with low power. >> >> Comparing the two is silly. Each has its place. > >That makes no sense. Hammer, meet nail. >There will always be some designs that a given >part is a perfect fit for, but that doesn't mean different devices can't >be compared. The question is what is the best fit for a given job. That is *NOT* what you're arguing. You're making the general case that FPGA >> DSP >> uC, which is just silly. >I am hearing some say that FPGAs aren't the best fit and I find they often >are a better fit than an MCU. Hammer, meet nail. >Much of it has to do with mis-information >about what FPGAs can and can't do and what is required to make them run. Nonsense. >Just read Joerge's post. I have. >Much of the stuff he objects to is specific >to the individual devices he has worked with. Like DSPs. I agree with him. FPGAs aren't in his future. You keep sugar-coating FPGAs and (erroneously) tear down DSPs. Note that I'm more of an FPGA kind of guy than a DSP sort but in this case Joerg is absolutely right. FPGAs only compete in small niche markets and those where money is no object. >>>> What I often find is people only doing Altera or only Xilinx. With uC >>>> it's a bit easier, a PIC guy can be cajoled into programming an AVR, >>>> usually. >>> >>> I'm totally device agnostic. I have worked with all brands other than >>> MicroSemi (formerly Actel). I even worked with Lucent which was bought >>> by Lattice and I believe is still sold and supported (but not the GD XP >>> line which I had designed into a cash cow product and will have to >>> redesign now). Ever hear of Concurrent? They were bought by Atmel. >>> Their devices were followed by the AT40K. I worked with the Concurrent >>> devices. lol So you can see I go way back. >> >> The difference anymore is very small. The only reason I prefer one >> over the other is software and that takes a back seat to most other >> variables (in rough order of importance, 1. cost, 2. cost, 3. cost). > >I have not found a big difference in software. The software is >different, but those differences are not important. It all compiles my >HDL fine (mostly because they often use the same third party tool >vendors) and simulation just works anymore. The software is different in how it works, not what it does. That difference makes *NO* difference to the end result or the cost of the product. IOW, it's completely irrelevant. At one time it may have been important but only in so much as that much of it didn't work (making the hardware useless). >> The one feature that isn't universal is programming modes. This can >> make a big difference in indirect costs (field upgrade, SKU >> personalization, etc.) that may not show up directly on the raw BOM. > >I don't know what devices you work with, but the ones I use are easy to >program. Pile on more sugar. You clearly don't work where time is money. >>> I've used schematic based tools and both VHDL and Verilog. I've worked >>> with the vendor's tools and third party tools including the NeoCAD tools >>> which became Xilinx tools when Xilinx bought them. >>> >>> If anyone tells you they only know one brand of FPGA you are talking to >>> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >>> terms of usage. MCUs need all sorts of start up code and peripheral >>> drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly >>> have the same features and most of that can be inferred from the HDL so >>> you never need to look too hard under the hood. >> >> Sure, the feature set and peripherals of micros varies widely. We use >> a variety of SoCs from just about everyone. Since most are settling >> on ARM, switching from one to the other is pretty simple. Our last >> port from one manufacturer to the other took a couple of weeks. > >The CPU is the easy part to port, the compiler handles that for you. It >is the drivers for the I/O that is harder. That's all included in the port. I'm talking from working hardware to working hardware (the target system not qualified, of course). There is only about 10% of the code that even has to be looked at. >Their libraries have to have >compatible interfaces and every port is a port. Wrong. That's all included. >With FPGAs, all you >need to do to switch between brands is normally a new pin list and >timing constraints. Bullshit! More sugar! >The HDL just compiles to suit the new device. Oh, you never use libraries? Yet you (erroneously) add that cost into the DSP/uC bucket. >It has been a while since I ported between brands but it would make sense >if they provide tools to port the timing constraints. That is the only >part that might be any work at all. > >>> In short, there is a lot of FUD about FPGAs. Talk to someone who >>> doesn't buy into the FUD. >> >> The FUD is on both sides. The support costs aren't as low as you >> pretend. > >Care to elaborate? You've TOTALLY forgotten about simulation, for instance. That's a huge effort that you simply sweep under the rug. > >>>> Things quickly unravel when you start relying on real hardware that is >>>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. >>> >>> If you really need it all on a single chip, then yes, you won't find >>> that on so many FPGAs although Microsemi has their Fusion line with >>> analog. My cash cow uses a single FPGA and a stereo CODEC. That was >>> smaller than any MCU design because the MCU would still require the >>> CODEC (CD quality) and some of the control logic and interface could not >>> be done with any conventional MCU. I had to vary the speed of the CODEC >>> clock via an ADPLL to synchronize it with an incoming data stream. I >>> don't know how to do that with an MCU and no logic. But I can do it all >>> with FPGA logic and no MCU. >> >> Nonsense. DSPs are also available with CODECs, as are UCs. > >You can find a small number of DSPs with CD qualitity CODECs and the >same for MCUs. I know, I did this search recently. I didn't find much >and none that suited my other critera. So the redo of my board will >likely have another FPGA on it. Goal post shift added to the hammer. >I would appreciate a list of the MCUs/DSPs which have stereo CD quality >CODECs on chip. The Sigma parts from ADI don't count because their DSPs >can *only* be used for certain coding like filters, not general purpose >use. Sigmas have them. I haven't looked for others. >>>> Last week I reviewed a design with some larger FPGA on there. What I >>>> found fairly disgusting was how much they had to be babied with the >>>> power sequencing. uCs don't have that problem. >>> >>> If you want to work with the wrong device, then you will find it hard to >>> work with. There are still single voltage devices on the market. If >>> this was an old design, most likely it was a Spartan 3 or similar era >>> device when they (for still unknown reasons) used three, yes, count >>> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >>> solely for the configuration interface which was normally to a 3.3 volt >>> device! Only from Xilinx... >>> >>> If this was a new device, then I guess they picked one based on >>> something other than ease of use, eh? Don't assume all FPGAs are the same. >> >> I thought you just said that there weren't many differences between >> FPGA manufacturers? > >You are mixing apples and oranges. One manufacturer has many different >families of FPGAs, no? Some are huge power hungry devices that burn a >hole in your board. Others are much lower power and don't burn a hole >in your pocketbook either. The families all look the same and vary only in density and mix of memory, speed, MCU, DSP(hmm), and other features. Good grief, you're arguing both sides.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-08 14:03 -0400 |
| Message-ID | <l0ie6c$a40$1@dont-email.me> |
| In reply to | #13383 |
On 9/8/2013 11:19 AM, krw@attt.bizz wrote: > On Sat, 07 Sep 2013 13:23:48 -0400, rickman<gnuarm@gmail.com> wrote: > >> On 9/7/2013 11:17 AM, krw@attt.bizz wrote: >>> On Fri, 06 Sep 2013 23:59:59 -0400, rickman<gnuarm@gmail.com> wrote: >>> >>>> On 9/6/2013 7:10 PM, Joerg wrote: >>>>> That is often the problem. Sometimes a buck fifty is the pain threshold. >>>>> Not in this ATMega case, the 2560 is very expensive but comes with lots >>>>> of ADC and analog muxes and all that. Things that will cost extra with a >>>>> FPGA solution and eat real estate. >>>>> >>>>> >>>>> For $3 however, you can get a >>>>>> chip large enough for a CPU (with math) and room for your special logic. >>>>>> >>>>> >>>>> For $3 I can get a big DSP. >>>> >>>> What "big" DSP can you get for $3? It has been a while since I looked >>>> hard at DSP chips, but I don't recall any I would call remotely "big" >>>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>>> start somewhere around $20 the last time I looked and that requires all >>>> memory and I/O to be separate. The smaller DSP chips that you can get >>>> for the $3 range are not "big" in any sense and only a very few of them >>>> include Flash memory. So you still need another chip. >>> >>> We pay less than that for the largest of the ADI sigma DSPs. I just >>> received a quote for the smallest CPLD for around $.75. I have use >>> for CPLDs and FPGAs but they're simply too expensive for most of my >>> applications. >> >> It seems the prices have come down in recent years, but still, the parts >> I have seen have no Flash. So you need to add in that cost. But the >> Sigma parts aren't really general purpose. They are good if you can >> make you app fit the DSP design, otherwise they aren't much use. I >> pursued them hard a few years ago until an FAE just threw in the towel >> and said I couldn't do my app on their part. > > Good grief. The issue wasn't to show YOU that YOUR application was > better in a DSP. Like many FGPA weenies, you're trying to sell a part > that has a niche market as the universal hammer. Good grief is right. You don't need to be rude. It isn't just my application, the Sigma parts are designed for a very limited set of DSP apps and even the development software limits how you design with them. They won't do the job of *most* DSP apps. >>>> Even a "small" FPGA can run rings around a DSP when it comes to >>>> performance. Usually "big" in DSPs means fast and when you want really >>>> fast DSP you use an FPGA with all the parallelism you can handle. DSPs >>>> can't touch FPGAs for speed, even with low power. >>> >>> Comparing the two is silly. Each has its place. >> >> That makes no sense. > > Hammer, meet nail. If you don't want to discuss engineering, then please spare me. >> There will always be some designs that a given >> part is a perfect fit for, but that doesn't mean different devices can't >> be compared. The question is what is the best fit for a given job. > > That is *NOT* what you're arguing. You're making the general case > that FPGA>> DSP>> uC, which is just silly. > >> I am hearing some say that FPGAs aren't the best fit and I find they often >> are a better fit than an MCU. > > Hammer, meet nail. You are repeating yourself. >> Much of it has to do with mis-information >> about what FPGAs can and can't do and what is required to make them run. > > Nonsense. > >> Just read Joerge's post. > > I have. > >> Much of the stuff he objects to is specific >> to the individual devices he has worked with. > > Like DSPs. I agree with him. FPGAs aren't in his future. You keep > sugar-coating FPGAs and (erroneously) tear down DSPs. Note that I'm > more of an FPGA kind of guy than a DSP sort but in this case Joerg is > absolutely right. FPGAs only compete in small niche markets and those > where money is no object. No one is tearing down DSPs. Can you just stick to the engineering and skip the drama? Your statement is exactly the sort of "mis-information" I am talking about. At $3 I think you can use an FPGA in a low cost app. So your "money is no object" claim is just BS. >>>>> What I often find is people only doing Altera or only Xilinx. With uC >>>>> it's a bit easier, a PIC guy can be cajoled into programming an AVR, >>>>> usually. >>>> >>>> I'm totally device agnostic. I have worked with all brands other than >>>> MicroSemi (formerly Actel). I even worked with Lucent which was bought >>>> by Lattice and I believe is still sold and supported (but not the GD XP >>>> line which I had designed into a cash cow product and will have to >>>> redesign now). Ever hear of Concurrent? They were bought by Atmel. >>>> Their devices were followed by the AT40K. I worked with the Concurrent >>>> devices. lol So you can see I go way back. >>> >>> The difference anymore is very small. The only reason I prefer one >>> over the other is software and that takes a back seat to most other >>> variables (in rough order of importance, 1. cost, 2. cost, 3. cost). >> >> I have not found a big difference in software. The software is >> different, but those differences are not important. It all compiles my >> HDL fine (mostly because they often use the same third party tool >> vendors) and simulation just works anymore. > > The software is different in how it works, not what it does. That > difference makes *NO* difference to the end result or the cost of the > product. IOW, it's completely irrelevant. At one time it may have > been important but only in so much as that much of it didn't work > (making the hardware useless). That is what I am saying. I find little difference in how the tools work. You write your HDL in your editor or their built in editor, you simulate it using the free tool they provide and you compile to a bit stream that gets downloaded into the FPGA, Flash or RAM. No, the tools aren't going to look exactly the same, but they do the same job and work the same way. Most of the tool is actually third party anyway, except for the Xilinx HDL in house compiler. But them most FPGA professionals (read as working for a company that has a few bucks) pay for the third party tools anyway. >>> The one feature that isn't universal is programming modes. This can >>> make a big difference in indirect costs (field upgrade, SKU >>> personalization, etc.) that may not show up directly on the raw BOM. >> >> I don't know what devices you work with, but the ones I use are easy to >> program. > > Pile on more sugar. You clearly don't work where time is money. Ok, very convincing argument. I have no idea what you are talking about. Downloading an FPGA is no different than an MCU. You either attach a cable for JTAG or your use the resources you designed into your target. >>>> I've used schematic based tools and both VHDL and Verilog. I've worked >>>> with the vendor's tools and third party tools including the NeoCAD tools >>>> which became Xilinx tools when Xilinx bought them. >>>> >>>> If anyone tells you they only know one brand of FPGA you are talking to >>>> an FPGA weenie. I find MCUs to vary a *great* deal more than FPGAs in >>>> terms of usage. MCUs need all sorts of start up code and peripheral >>>> drivers, clock control, etc, etc, etc. FPGAs not so much. They mostly >>>> have the same features and most of that can be inferred from the HDL so >>>> you never need to look too hard under the hood. >>> >>> Sure, the feature set and peripherals of micros varies widely. We use >>> a variety of SoCs from just about everyone. Since most are settling >>> on ARM, switching from one to the other is pretty simple. Our last >>> port from one manufacturer to the other took a couple of weeks. >> >> The CPU is the easy part to port, the compiler handles that for you. It >> is the drivers for the I/O that is harder. > > That's all included in the port. I'm talking from working hardware to > working hardware (the target system not qualified, of course). There > is only about 10% of the code that even has to be looked at. With FPGAs *none* of the code has to be looked at. >> Their libraries have to have >> compatible interfaces and every port is a port. > > Wrong. That's all included. You have identical peripheral interface libraries for different brands of MCUs? Every timer function works the same, every SPI port sets up the same, every power controller is operated the same? >> With FPGAs, all you >> need to do to switch between brands is normally a new pin list and >> timing constraints. > > Bullshit! More sugar! You are the consummate debater... >> The HDL just compiles to suit the new device. > > Oh, you never use libraries? Yet you (erroneously) add that cost into > the DSP/uC bucket. The only libraries I use are the HDL libraries which are standardized, like using stdio. I don't add the libraries into the MCU column, I'm not the one using the MCU. >> It has been a while since I ported between brands but it would make sense >> if they provide tools to port the timing constraints. That is the only >> part that might be any work at all. >> >>>> In short, there is a lot of FUD about FPGAs. Talk to someone who >>>> doesn't buy into the FUD. >>> >>> The FUD is on both sides. The support costs aren't as low as you >>> pretend. >> >> Care to elaborate? > > You've TOTALLY forgotten about simulation, for instance. That's a > huge effort that you simply sweep under the rug. What about it? I paid for a set of tools from Lattice. I had used the Modelsim simulator at work and was used to it. The Lattice tools said they came with the Modelsim simulator. But by the time I got the package it had the Active HDL simulator. I complained about this thinking I would have to learn a new simulator... but it was a no-op to switch. Even my Modelsim scripts ran under the AHDL simulator. So what is your concern? >>>>> Things quickly unravel when you start relying on real hardware that is >>>>> on uC but not on FPGA. Comparators, ADCs, analog muxes, for example. >>>> >>>> If you really need it all on a single chip, then yes, you won't find >>>> that on so many FPGAs although Microsemi has their Fusion line with >>>> analog. My cash cow uses a single FPGA and a stereo CODEC. That was >>>> smaller than any MCU design because the MCU would still require the >>>> CODEC (CD quality) and some of the control logic and interface could not >>>> be done with any conventional MCU. I had to vary the speed of the CODEC >>>> clock via an ADPLL to synchronize it with an incoming data stream. I >>>> don't know how to do that with an MCU and no logic. But I can do it all >>>> with FPGA logic and no MCU. >>> >>> Nonsense. DSPs are also available with CODECs, as are UCs. >> >> You can find a small number of DSPs with CD qualitity CODECs and the >> same for MCUs. I know, I did this search recently. I didn't find much >> and none that suited my other critera. So the redo of my board will >> likely have another FPGA on it. > > Goal post shift added to the hammer. > >> I would appreciate a list of the MCUs/DSPs which have stereo CD quality >> CODECs on chip. The Sigma parts from ADI don't count because their DSPs >> can *only* be used for certain coding like filters, not general purpose >> use. > > Sigmas have them. I haven't looked for others. But Sigmas aren't general purpose DSPs and can't do most DSP jobs. They are designed to be filters, like in hearing aids. >>>>> Last week I reviewed a design with some larger FPGA on there. What I >>>>> found fairly disgusting was how much they had to be babied with the >>>>> power sequencing. uCs don't have that problem. >>>> >>>> If you want to work with the wrong device, then you will find it hard to >>>> work with. There are still single voltage devices on the market. If >>>> this was an old design, most likely it was a Spartan 3 or similar era >>>> device when they (for still unknown reasons) used three, yes, count >>>> them, *three* voltages on the FPGA. The 2.5 volt aux supply was there >>>> solely for the configuration interface which was normally to a 3.3 volt >>>> device! Only from Xilinx... >>>> >>>> If this was a new device, then I guess they picked one based on >>>> something other than ease of use, eh? Don't assume all FPGAs are the same. >>> >>> I thought you just said that there weren't many differences between >>> FPGA manufacturers? >> >> You are mixing apples and oranges. One manufacturer has many different >> families of FPGAs, no? Some are huge power hungry devices that burn a >> hole in your board. Others are much lower power and don't burn a hole >> in your pocketbook either. > > The families all look the same and vary only in density and mix of > memory, speed, MCU, DSP(hmm), and other features. > > Good grief, you're arguing both sides. We've been down the road before. You are not enjoyable to discuss things with. You get obnoxious and don't explain what you are talking about. Do you really want to have this discussion? I don't think I do. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 19:42 -0400 |
| Message-ID | <4b1q29h2t2eqn7olkntcbq36iqsob4523k@4ax.com> |
| In reply to | #13391 |
On Sun, 08 Sep 2013 14:03:47 -0400, rickman <gnuarm@gmail.com> wrote: >On 9/8/2013 11:19 AM, krw@attt.bizz wrote: >> On Sat, 07 Sep 2013 13:23:48 -0400, rickman<gnuarm@gmail.com> wrote: >> >>> On 9/7/2013 11:17 AM, krw@attt.bizz wrote: >>>> On Fri, 06 Sep 2013 23:59:59 -0400, rickman<gnuarm@gmail.com> wrote: >>>> >>>>> On 9/6/2013 7:10 PM, Joerg wrote: >>>>>> That is often the problem. Sometimes a buck fifty is the pain threshold. >>>>>> Not in this ATMega case, the 2560 is very expensive but comes with lots >>>>>> of ADC and analog muxes and all that. Things that will cost extra with a >>>>>> FPGA solution and eat real estate. >>>>>> >>>>>> >>>>>> For $3 however, you can get a >>>>>>> chip large enough for a CPU (with math) and room for your special logic. >>>>>>> >>>>>> >>>>>> For $3 I can get a big DSP. >>>>> >>>>> What "big" DSP can you get for $3? It has been a while since I looked >>>>> hard at DSP chips, but I don't recall any I would call remotely "big" >>>>> for $3. The TI chips that would be "big" are the TMS6xxx line which >>>>> start somewhere around $20 the last time I looked and that requires all >>>>> memory and I/O to be separate. The smaller DSP chips that you can get >>>>> for the $3 range are not "big" in any sense and only a very few of them >>>>> include Flash memory. So you still need another chip. >>>> >>>> We pay less than that for the largest of the ADI sigma DSPs. I just >>>> received a quote for the smallest CPLD for around $.75. I have use >>>> for CPLDs and FPGAs but they're simply too expensive for most of my >>>> applications. >>> >>> It seems the prices have come down in recent years, but still, the parts >>> I have seen have no Flash. So you need to add in that cost. But the >>> Sigma parts aren't really general purpose. They are good if you can >>> make you app fit the DSP design, otherwise they aren't much use. I >>> pursued them hard a few years ago until an FAE just threw in the towel >>> and said I couldn't do my app on their part. >> >> Good grief. The issue wasn't to show YOU that YOUR application was >> better in a DSP. Like many FGPA weenies, you're trying to sell a part >> that has a niche market as the universal hammer. > >Good grief is right. You don't need to be rude. It isn't just my >application, the Sigma parts are designed for a very limited set of DSP >apps and even the development software limits how you design with them. > They won't do the job of *most* DSP apps. That doesn't alter the fact that you're constantly moving the goal posts. You *are* defending the FPGA as the general solution when it is quite decidedly only applicable in the niches. You wanted to know what DSP had a CODEC. I told you but now you whine that it won't solve YOUR problem. It's not my job to do your work. >>>>> Even a "small" FPGA can run rings around a DSP when it comes to >>>>> performance. Usually "big" in DSPs means fast and when you want really >>>>> fast DSP you use an FPGA with all the parallelism you can handle. DSPs >>>>> can't touch FPGAs for speed, even with low power. >>>> >>>> Comparing the two is silly. Each has its place. >>> >>> That makes no sense. >> >> Hammer, meet nail. > >If you don't want to discuss engineering, then please spare me. If you refuse to understand, why do you bother coming here? > >>> There will always be some designs that a given >>> part is a perfect fit for, but that doesn't mean different devices can't >>> be compared. The question is what is the best fit for a given job. >> >> That is *NOT* what you're arguing. You're making the general case >> that FPGA>> DSP>> uC, which is just silly. >> >>> I am hearing some say that FPGAs aren't the best fit and I find they often >>> are a better fit than an MCU. >> >> Hammer, meet nail. > >You are repeating yourself. Only because you are repeating your silly FPGA uber alles, nonsense. >>> Much of it has to do with mis-information >>> about what FPGAs can and can't do and what is required to make them run. >> >> Nonsense. >> >>> Just read Joerge's post. >> >> I have. >> >>> Much of the stuff he objects to is specific >>> to the individual devices he has worked with. >> >> Like DSPs. I agree with him. FPGAs aren't in his future. You keep >> sugar-coating FPGAs and (erroneously) tear down DSPs. Note that I'm >> more of an FPGA kind of guy than a DSP sort but in this case Joerg is >> absolutely right. FPGAs only compete in small niche markets and those >> where money is no object. > >No one is tearing down DSPs. Can you just stick to the engineering and >skip the drama? WFT are you talking about? You *are* saying that FPGAs are the cat's ass for all applications when nothing could be further from the truth. they're a niche and the solution of last resort. Well, and ASSC is the solution of last resort, but... >Your statement is exactly the sort of "mis-information" I am talking >about. At $3 I think you can use an FPGA in a low cost app. So your >"money is no object" claim is just BS. Absolutely wrong. FPGAs are *only* useful when there is no other choice. For anything else, they will always be the most expensive solution. Your position is exactly a nail looking at every tool as a hammer. <snip> >>> I have not found a big difference in software. The software is >>> different, but those differences are not important. It all compiles my >>> HDL fine (mostly because they often use the same third party tool >>> vendors) and simulation just works anymore. >> >> The software is different in how it works, not what it does. That >> difference makes *NO* difference to the end result or the cost of the >> product. IOW, it's completely irrelevant. At one time it may have >> been important but only in so much as that much of it didn't work >> (making the hardware useless). > >That is what I am saying. I find little difference in how the tools >work. You write your HDL in your editor or their built in editor, you >simulate it using the free tool they provide and you compile to a bit >stream that gets downloaded into the FPGA, Flash or RAM. No, the tools >aren't going to look exactly the same, but they do the same job and work >the same way. Most of the tool is actually third party anyway, except >for the Xilinx HDL in house compiler. But them most FPGA professionals >(read as working for a company that has a few bucks) pay for the third >party tools anyway. > > >>>> The one feature that isn't universal is programming modes. This can >>>> make a big difference in indirect costs (field upgrade, SKU >>>> personalization, etc.) that may not show up directly on the raw BOM. >>> >>> I don't know what devices you work with, but the ones I use are easy to >>> program. >> >> Pile on more sugar. You clearly don't work where time is money. > >Ok, very convincing argument. I have no idea what you are talking >about. Downloading an FPGA is no different than an MCU. You either >attach a cable for JTAG or your use the resources you designed into your >target. You clearly don't simulate. You've completely ignored the issue here. Like the elephant in the phone booth, FPGA zealots want to ignore it. Simulation is much more work than design, yet it is always forgotten in these discussions. <snip> >>> The CPU is the easy part to port, the compiler handles that for you. It >>> is the drivers for the I/O that is harder. >> >> That's all included in the port. I'm talking from working hardware to >> working hardware (the target system not qualified, of course). There >> is only about 10% of the code that even has to be looked at. > >With FPGAs *none* of the code has to be looked at. Oh, good grief! You never have to rework libraries? Roll your own, for what was free in the other vendor's? All of the peripherals function the same, for each vendors'? Come on, get real! >>> Their libraries have to have >>> compatible interfaces and every port is a port. >> >> Wrong. That's all included. > >You have identical peripheral interface libraries for different brands >of MCUs? Every timer function works the same, every SPI port sets up >the same, every power controller is operated the same? That's all in the two weeks. From working code to working code. We just did it from a TI to Freescale SoC. ...yet you claim that you can do that all between X and A without even looking at the code. Unbelievable! >>> With FPGAs, all you >>> need to do to switch between brands is normally a new pin list and >>> timing constraints. >> >> Bullshit! More sugar! > >You are the consummate debater... I call bullshit when I see bullshit and that is *BULLSHIT*. > >>> The HDL just compiles to suit the new device. >> >> Oh, you never use libraries? Yet you (erroneously) add that cost into >> the DSP/uC bucket. > >The only libraries I use are the HDL libraries which are standardized, >like using stdio. I don't add the libraries into the MCU column, I'm >not the one using the MCU. What bullshit. There are no PCIe libraries? USB? uC? GMAFB! >>> It has been a while since I ported between brands but it would make sense >>> if they provide tools to port the timing constraints. That is the only >>> part that might be any work at all. >>> >>>>> In short, there is a lot of FUD about FPGAs. Talk to someone who >>>>> doesn't buy into the FUD. >>>> >>>> The FUD is on both sides. The support costs aren't as low as you >>>> pretend. >>> >>> Care to elaborate? >> >> You've TOTALLY forgotten about simulation, for instance. That's a >> huge effort that you simply sweep under the rug. > >What about it? I paid for a set of tools from Lattice. Tools? TOOLS?! What do they do all by themselves? >I had used the >Modelsim simulator at work and was used to it. The Lattice tools said >they came with the Modelsim simulator. But by the time I got the >package it had the Active HDL simulator. I complained about this >thinking I would have to learn a new simulator... but it was a no-op to >switch. Even my Modelsim scripts ran under the AHDL simulator. > >So what is your concern? Simulation takes TIME and SKILL that most don't have. That's in addition to the skills and time needed to do a uC or DSP solution. If there is *any* way to do a project with either, the FPGA loses. That's the whole point here; FPGAs are a solution to niches - always will be. <snip> >>> I would appreciate a list of the MCUs/DSPs which have stereo CD quality >>> CODECs on chip. The Sigma parts from ADI don't count because their DSPs >>> can *only* be used for certain coding like filters, not general purpose >>> use. >> >> Sigmas have them. I haven't looked for others. > >But Sigmas aren't general purpose DSPs and can't do most DSP jobs. They >are designed to be filters, like in hearing aids. They do a lot and some better than other DSPs. It was an example, to counter your point. BTW, I'm not trying to say that DSPs are the end-all solution, like you are trying to, with FPGAs. ...and like I said, I've done way more FPGA design than DSP (I only do hardware). >> The families all look the same and vary only in density and mix of >> memory, speed, MCU, DSP(hmm), and other features. >> >> Good grief, you're arguing both sides. > >We've been down the road before. You are not enjoyable to discuss >things with. You get obnoxious and don't explain what you are talking >about. Do you really want to have this discussion? I don't think I do. I can't help it if you don't like being called on your bullshit. If you don't like being called on it, don't bullshit.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web