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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-11 09:49 -0700 |
| Message-ID | <b9bl7tF7kikU1@mid.individual.net> |
| In reply to | #13463 |
Paul wrote: > In article <b9be8tF6561U1@mid.individual.net>, invalid@invalid.invalid > says... >> rickman wrote: >>> On 9/8/2013 3:56 PM, Joerg wrote: >>> According to wikipedia, TI had DSPs out in the early 80's which > jibes >>> with what I recall. TI was the first with a successful product so they >>> got the market share early on. Once they had an established code base >>> in a given industry they continued to hold their lead. I can't say who >>> is dominant in what industry, but I know TI was rather dominant in the >>> cell industry which was the cash cow. >>> >> Cell phones are short-lived products. One year, if that. Med/aero is a >> whole different set of metrics. We need to rely on parts still being >> there 10, 20 or more years doen the road. > > Around 2002 to 2004 I had an enquiry to look at improving an NMR system > at a hospital. When I asked them what the age of the machine was they > said - > > "The earliest record we have is when it MOVED to the new building > in 1968" > Some stuff lasts a long time. Here is Betsy, we used her to split firewood: http://www.analogconsultants.com/ng/images/splitter.JPG 1942 surplus army motor, all mounted on the front axle of a 1939 DeSoto. You can still get the tires. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 11:40 -0400 |
| Message-ID | <eh6p29hp3667vmof5q27s54pmjgv9lojlq@4ax.com> |
| In reply to | #13369 |
On Sat, 07 Sep 2013 19:02:53 -0400, rickman <gnuarm@gmail.com> wrote: >On 9/7/2013 6:23 PM, Joerg wrote: >> How long do the usual FPGA stay in the market? Meaning plop-in >> replaceable, same footprint, same code, no changes. > >Life span is typically *much* better than MCUs. Like that new kid on the block, the 8051?
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 11:38 -0400 |
| Message-ID | <4e6p29h94rt39naaue6p0k1gqra33h7vf0@4ax.com> |
| In reply to | #13366 |
On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> wrote: >rickman wrote: >> On 9/7/2013 4:46 PM, Joerg wrote: >>> Paul Rubin wrote: >>>> Joerg<invalid@invalid.invalid> writes: >>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>> into one of these small Lattice devices. >>>> >>>> I had thought the parts of those processors that would bloat up badly >>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>> bloat is ok in the scheme of things. The parts doing the most work >>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>> >>>> I do think softcores seem like a silly idea a lot of the time, and am >>>> looking forward to more low end FPGA's with MCU blocks. >>> >>> >>> Much of it has to do with legacy code. Yes, some things could even be >>> done more efficiently in the FPGA because you can actually streamline >>> the HW to the task, something neither uC nor DSP allow. For example, why >>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>> But legacy code won't run anymore and you need FPGA specialists to make >>> it all work. >> >> No, you would need a DSP specialist. The FPGA designer only needs to >> know how to code the FPGA. >> > >So for this kind of solution in an FPGA you need a DSP specialist and an >FPGA specialist? That would be a problem. Pick ones that are in the automotive market. Support for fifteen years is required. >> But that is exactly the point of the FPGA in DSP apps. You code to the >> app, not to a processor. >> > >How long do the usual FPGA stay in the market? Meaning plop-in >replaceable, same footprint, same code, no changes. The usual? About 30 minutes. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 09:34 -0700 |
| Message-ID | <b93n95Fi3l4U2@mid.individual.net> |
| In reply to | #13386 |
krw@attt.bizz wrote: > On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> rickman wrote: >>> On 9/7/2013 4:46 PM, Joerg wrote: >>>> Paul Rubin wrote: >>>>> Joerg<invalid@invalid.invalid> writes: >>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>> into one of these small Lattice devices. >>>>> I had thought the parts of those processors that would bloat up badly >>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>> >>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>> looking forward to more low end FPGA's with MCU blocks. >>>> >>>> Much of it has to do with legacy code. Yes, some things could even be >>>> done more efficiently in the FPGA because you can actually streamline >>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>> But legacy code won't run anymore and you need FPGA specialists to make >>>> it all work. >>> No, you would need a DSP specialist. The FPGA designer only needs to >>> know how to code the FPGA. >>> >> So for this kind of solution in an FPGA you need a DSP specialist and an >> FPGA specialist? That would be a problem. > > Pick ones that are in the automotive market. Support for fifteen > years is required. > That's a good point. How does one find out which ones those are? Mil stuff is even better, that needs to remain available for decades. That is the reason why the LM331 is still around and why I used it in a long-life design many years ago. >>> But that is exactly the point of the FPGA in DSP apps. You code to the >>> app, not to a processor. >>> >> How long do the usual FPGA stay in the market? Meaning plop-in >> replaceable, same footprint, same code, no changes. > > The usual? About 30 minutes. ;-) :-) -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-08 14:29 -0400 |
| Message-ID | <l0ifmu$hfe$2@dont-email.me> |
| In reply to | #13389 |
On 9/8/2013 12:34 PM, Joerg wrote: > krw@attt.bizz wrote: >> >> Pick ones that are in the automotive market. Support for fifteen >> years is required. >> > > That's a good point. How does one find out which ones those are? All FPGA makers offer automotive lines. They advertise them as such. > Mil stuff is even better, that needs to remain available for decades. > That is the reason why the LM331 is still around and why I used it in a > long-life design many years ago. You won't find many $3 parts in a MIL line... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 13:01 -0700 |
| Message-ID | <b943c7Fko6tU1@mid.individual.net> |
| In reply to | #13394 |
rickman wrote: > On 9/8/2013 12:34 PM, Joerg wrote: >> krw@attt.bizz wrote: >>> >>> Pick ones that are in the automotive market. Support for fifteen >>> years is required. >>> >> >> That's a good point. How does one find out which ones those are? > > All FPGA makers offer automotive lines. They advertise them as such. > Ok then, next time I'll ask them. When I selected 125C devices Atmel dropped out of the list at Digikey. Could it be that they don't do automotive? > >> Mil stuff is even better, that needs to remain available for decades. >> That is the reason why the LM331 is still around and why I used it in a >> long-life design many years ago. > > You won't find many $3 parts in a MIL line... > The LM331 costs slightly above $1 in bulk. But it only comes in through-hole packages. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 16:22 -0400 |
| Message-ID | <ppmp299h5f0keo1oprq38c66iurui1nug4@4ax.com> |
| In reply to | #13396 |
On Sun, 08 Sep 2013 13:01:02 -0700, Joerg <invalid@invalid.invalid> wrote: >rickman wrote: >> On 9/8/2013 12:34 PM, Joerg wrote: >>> krw@attt.bizz wrote: >>>> >>>> Pick ones that are in the automotive market. Support for fifteen >>>> years is required. >>>> >>> >>> That's a good point. How does one find out which ones those are? >> >> All FPGA makers offer automotive lines. They advertise them as such. >> > >Ok then, next time I'll ask them. When I selected 125C devices Atmel >dropped out of the list at Digikey. Could it be that they don't do >automotive? http://www.altera.com/end-markets/auto/aut-index.html http://www.latticesemi.com/automotive http://www.xilinx.com/applications/automotive/index.htm Atmel makes a lot of automotive stuff but apparently they see no reason to go there with FPGAs. Don't blame them.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-10 23:09 -0400 |
| Message-ID | <l0omqb$oik$2@dont-email.me> |
| In reply to | #13396 |
On 9/8/2013 4:01 PM, Joerg wrote: > rickman wrote: >> On 9/8/2013 12:34 PM, Joerg wrote: >>> krw@attt.bizz wrote: >>>> >>>> Pick ones that are in the automotive market. Support for fifteen >>>> years is required. >>>> >>> >>> That's a good point. How does one find out which ones those are? >> >> All FPGA makers offer automotive lines. They advertise them as such. >> > > Ok then, next time I'll ask them. When I selected 125C devices Atmel > dropped out of the list at Digikey. Could it be that they don't do > automotive? Atmel doesn't really do FPGAs. They have PLDs, but I'm not even sure they have any CPLDs. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 16:15 -0400 |
| Message-ID | <6imp291k8t3li7pa63ddj94dh3l21gqeqp@4ax.com> |
| In reply to | #13389 |
On Sun, 08 Sep 2013 09:34:38 -0700, Joerg <invalid@invalid.invalid> wrote: >krw@attt.bizz wrote: >> On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> >> wrote: >> >>> rickman wrote: >>>> On 9/7/2013 4:46 PM, Joerg wrote: >>>>> Paul Rubin wrote: >>>>>> Joerg<invalid@invalid.invalid> writes: >>>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>>> into one of these small Lattice devices. >>>>>> I had thought the parts of those processors that would bloat up badly >>>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>>> >>>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>>> looking forward to more low end FPGA's with MCU blocks. >>>>> >>>>> Much of it has to do with legacy code. Yes, some things could even be >>>>> done more efficiently in the FPGA because you can actually streamline >>>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>>> But legacy code won't run anymore and you need FPGA specialists to make >>>>> it all work. >>>> No, you would need a DSP specialist. The FPGA designer only needs to >>>> know how to code the FPGA. >>>> >>> So for this kind of solution in an FPGA you need a DSP specialist and an >>> FPGA specialist? That would be a problem. >> >> Pick ones that are in the automotive market. Support for fifteen >> years is required. >> > >That's a good point. How does one find out which ones those are? Click on the "Automotive" tab on the applications page in their web site? Look for the ACQ- compliance designations? >Mil stuff is even better, that needs to remain available for decades. >That is the reason why the LM331 is still around and why I used it in a >long-life design many years ago. The difference is that while Mil stuff may be available until the end of times, that doesn't mean that it'll be priced within the range of mere mortals for that time. >>>> But that is exactly the point of the FPGA in DSP apps. You code to the >>>> app, not to a processor. >>>> >>> How long do the usual FPGA stay in the market? Meaning plop-in >>> replaceable, same footprint, same code, no changes. >> >> The usual? About 30 minutes. ;-) > >:-)
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 14:20 -0700 |
| Message-ID | <b9481nFlnlnU1@mid.individual.net> |
| In reply to | #13397 |
krw@attt.bizz wrote: > On Sun, 08 Sep 2013 09:34:38 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> krw@attt.bizz wrote: >>> On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> >>> wrote: >>> >>>> rickman wrote: >>>>> On 9/7/2013 4:46 PM, Joerg wrote: >>>>>> Paul Rubin wrote: >>>>>>> Joerg<invalid@invalid.invalid> writes: >>>>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>>>> into one of these small Lattice devices. >>>>>>> I had thought the parts of those processors that would bloat up badly >>>>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>>>> >>>>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>>>> looking forward to more low end FPGA's with MCU blocks. >>>>>> Much of it has to do with legacy code. Yes, some things could even be >>>>>> done more efficiently in the FPGA because you can actually streamline >>>>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>>>> But legacy code won't run anymore and you need FPGA specialists to make >>>>>> it all work. >>>>> No, you would need a DSP specialist. The FPGA designer only needs to >>>>> know how to code the FPGA. >>>>> >>>> So for this kind of solution in an FPGA you need a DSP specialist and an >>>> FPGA specialist? That would be a problem. >>> Pick ones that are in the automotive market. Support for fifteen >>> years is required. >>> >> That's a good point. How does one find out which ones those are? > > Click on the "Automotive" tab on the applications page in their web > site? Look for the ACQ- compliance designations? > I usually go in via Digikey. No automotive tab in that segment but the temperature range gives it away. >> Mil stuff is even better, that needs to remain available for decades. >> That is the reason why the LM331 is still around and why I used it in a >> long-life design many years ago. > > The difference is that while Mil stuff may be available until the end > of times, that doesn't mean that it'll be priced within the range of > mere mortals for that time. > Not the certified parts or rad-hard. But with other semiconductors it usually means that the consumer-grade stuff remains available. Like the LM331 which they even brought out in lead-free which the military folks wouldn't even touch. At $4 not exactly a bargain but in situations where you need true analog V/F conversion that is a great help. [...] -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 18:15 -0400 |
| Message-ID | <ohtp29lr1nmsunqinddvspqn7ab4l04kq7@4ax.com> |
| In reply to | #13400 |
On Sun, 08 Sep 2013 14:20:46 -0700, Joerg <invalid@invalid.invalid> wrote: >krw@attt.bizz wrote: >> On Sun, 08 Sep 2013 09:34:38 -0700, Joerg <invalid@invalid.invalid> >> wrote: >> >>> krw@attt.bizz wrote: >>>> On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> >>>> wrote: >>>> >>>>> rickman wrote: >>>>>> On 9/7/2013 4:46 PM, Joerg wrote: >>>>>>> Paul Rubin wrote: >>>>>>>> Joerg<invalid@invalid.invalid> writes: >>>>>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>>>>> into one of these small Lattice devices. >>>>>>>> I had thought the parts of those processors that would bloat up badly >>>>>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>>>>> >>>>>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>>>>> looking forward to more low end FPGA's with MCU blocks. >>>>>>> Much of it has to do with legacy code. Yes, some things could even be >>>>>>> done more efficiently in the FPGA because you can actually streamline >>>>>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>>>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>>>>> But legacy code won't run anymore and you need FPGA specialists to make >>>>>>> it all work. >>>>>> No, you would need a DSP specialist. The FPGA designer only needs to >>>>>> know how to code the FPGA. >>>>>> >>>>> So for this kind of solution in an FPGA you need a DSP specialist and an >>>>> FPGA specialist? That would be a problem. >>>> Pick ones that are in the automotive market. Support for fifteen >>>> years is required. >>>> >>> That's a good point. How does one find out which ones those are? >> >> Click on the "Automotive" tab on the applications page in their web >> site? Look for the ACQ- compliance designations? >> > >I usually go in via Digikey. No automotive tab in that segment but the >temperature range gives it away. Not at all. Automotive and industrial temperatures are quite alike but the qualifications certainly are not. Automotive needs 85C ambient. What that does to Tj varies by component. > >>> Mil stuff is even better, that needs to remain available for decades. >>> That is the reason why the LM331 is still around and why I used it in a >>> long-life design many years ago. >> >> The difference is that while Mil stuff may be available until the end >> of times, that doesn't mean that it'll be priced within the range of >> mere mortals for that time. >> > >Not the certified parts or rad-hard. But with other semiconductors it >usually means that the consumer-grade stuff remains available. Like the >LM331 which they even brought out in lead-free which the military folks >wouldn't even touch. At $4 not exactly a bargain but in situations where >you need true analog V/F conversion that is a great help. No, it sometimes means that they've squirreled away enough parts to satisfy (infinite pockets) Uncle Sam. Yes, Mil stuff has that evil lead, in it but again, the price bathtubs are quite different (and not symmetrical)
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 15:57 -0700 |
| Message-ID | <b94dn0Fmrd0U1@mid.individual.net> |
| In reply to | #13402 |
krw@attt.bizz wrote: > On Sun, 08 Sep 2013 14:20:46 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> krw@attt.bizz wrote: >>> On Sun, 08 Sep 2013 09:34:38 -0700, Joerg <invalid@invalid.invalid> >>> wrote: >>> >>>> krw@attt.bizz wrote: >>>>> On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> >>>>> wrote: >>>>> >>>>>> rickman wrote: >>>>>>> On 9/7/2013 4:46 PM, Joerg wrote: >>>>>>>> Paul Rubin wrote: >>>>>>>>> Joerg<invalid@invalid.invalid> writes: >>>>>>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>>>>>> into one of these small Lattice devices. >>>>>>>>> I had thought the parts of those processors that would bloat up badly >>>>>>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>>>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>>>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>>>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>>>>>> >>>>>>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>>>>>> looking forward to more low end FPGA's with MCU blocks. >>>>>>>> Much of it has to do with legacy code. Yes, some things could even be >>>>>>>> done more efficiently in the FPGA because you can actually streamline >>>>>>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>>>>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>>>>>> But legacy code won't run anymore and you need FPGA specialists to make >>>>>>>> it all work. >>>>>>> No, you would need a DSP specialist. The FPGA designer only needs to >>>>>>> know how to code the FPGA. >>>>>>> >>>>>> So for this kind of solution in an FPGA you need a DSP specialist and an >>>>>> FPGA specialist? That would be a problem. >>>>> Pick ones that are in the automotive market. Support for fifteen >>>>> years is required. >>>>> >>>> That's a good point. How does one find out which ones those are? >>> Click on the "Automotive" tab on the applications page in their web >>> site? Look for the ACQ- compliance designations? >>> >> I usually go in via Digikey. No automotive tab in that segment but the >> temperature range gives it away. > > Not at all. Automotive and industrial temperatures are quite alike > but the qualifications certainly are not. Automotive needs 85C > ambient. What that does to Tj varies by component. 85C in a vehicle? Yikes. I would not dare to design that in. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 19:46 -0400 |
| Message-ID | <ps2q29dp9sig33keugfqh2aed0ahe78gci@4ax.com> |
| In reply to | #13403 |
On Sun, 08 Sep 2013 15:57:29 -0700, Joerg <invalid@invalid.invalid> wrote: >krw@attt.bizz wrote: >> On Sun, 08 Sep 2013 14:20:46 -0700, Joerg <invalid@invalid.invalid> >> wrote: >> >>> krw@attt.bizz wrote: >>>> On Sun, 08 Sep 2013 09:34:38 -0700, Joerg <invalid@invalid.invalid> >>>> wrote: >>>> >>>>> krw@attt.bizz wrote: >>>>>> On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> >>>>>> wrote: >>>>>> >>>>>>> rickman wrote: >>>>>>>> On 9/7/2013 4:46 PM, Joerg wrote: >>>>>>>>> Paul Rubin wrote: >>>>>>>>>> Joerg<invalid@invalid.invalid> writes: >>>>>>>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>>>>>>> into one of these small Lattice devices. >>>>>>>>>> I had thought the parts of those processors that would bloat up badly >>>>>>>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>>>>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>>>>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>>>>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>>>>>>> >>>>>>>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>>>>>>> looking forward to more low end FPGA's with MCU blocks. >>>>>>>>> Much of it has to do with legacy code. Yes, some things could even be >>>>>>>>> done more efficiently in the FPGA because you can actually streamline >>>>>>>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>>>>>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>>>>>>> But legacy code won't run anymore and you need FPGA specialists to make >>>>>>>>> it all work. >>>>>>>> No, you would need a DSP specialist. The FPGA designer only needs to >>>>>>>> know how to code the FPGA. >>>>>>>> >>>>>>> So for this kind of solution in an FPGA you need a DSP specialist and an >>>>>>> FPGA specialist? That would be a problem. >>>>>> Pick ones that are in the automotive market. Support for fifteen >>>>>> years is required. >>>>>> >>>>> That's a good point. How does one find out which ones those are? >>>> Click on the "Automotive" tab on the applications page in their web >>>> site? Look for the ACQ- compliance designations? >>>> >>> I usually go in via Digikey. No automotive tab in that segment but the >>> temperature range gives it away. >> >> Not at all. Automotive and industrial temperatures are quite alike >> but the qualifications certainly are not. Automotive needs 85C >> ambient. What that does to Tj varies by component. > > >85C in a vehicle? Yikes. I would not dare to design that in. It's a fact of life. Think JimT's car interior, parked in the driveway in August. Design to 85C isn't just a good idea, it's the spec (-40C to 85C).
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 17:15 -0700 |
| Message-ID | <b94i8vFnlh8U1@mid.individual.net> |
| In reply to | #13407 |
krw@attt.bizz wrote: > On Sun, 08 Sep 2013 15:57:29 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> krw@attt.bizz wrote: >>> On Sun, 08 Sep 2013 14:20:46 -0700, Joerg <invalid@invalid.invalid> >>> wrote: >>> >>>> krw@attt.bizz wrote: >>>>> On Sun, 08 Sep 2013 09:34:38 -0700, Joerg <invalid@invalid.invalid> >>>>> wrote: >>>>> >>>>>> krw@attt.bizz wrote: >>>>>>> On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> >>>>>>> wrote: >>>>>>> >>>>>>>> rickman wrote: >>>>>>>>> On 9/7/2013 4:46 PM, Joerg wrote: >>>>>>>>>> Paul Rubin wrote: >>>>>>>>>>> Joerg<invalid@invalid.invalid> writes: >>>>>>>>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>>>>>>>> into one of these small Lattice devices. >>>>>>>>>>> I had thought the parts of those processors that would bloat up badly >>>>>>>>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>>>>>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>>>>>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>>>>>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>>>>>>>> >>>>>>>>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>>>>>>>> looking forward to more low end FPGA's with MCU blocks. >>>>>>>>>> Much of it has to do with legacy code. Yes, some things could even be >>>>>>>>>> done more efficiently in the FPGA because you can actually streamline >>>>>>>>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>>>>>>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>>>>>>>> But legacy code won't run anymore and you need FPGA specialists to make >>>>>>>>>> it all work. >>>>>>>>> No, you would need a DSP specialist. The FPGA designer only needs to >>>>>>>>> know how to code the FPGA. >>>>>>>>> >>>>>>>> So for this kind of solution in an FPGA you need a DSP specialist and an >>>>>>>> FPGA specialist? That would be a problem. >>>>>>> Pick ones that are in the automotive market. Support for fifteen >>>>>>> years is required. >>>>>>> >>>>>> That's a good point. How does one find out which ones those are? >>>>> Click on the "Automotive" tab on the applications page in their web >>>>> site? Look for the ACQ- compliance designations? >>>>> >>>> I usually go in via Digikey. No automotive tab in that segment but the >>>> temperature range gives it away. >>> Not at all. Automotive and industrial temperatures are quite alike >>> but the qualifications certainly are not. Automotive needs 85C >>> ambient. What that does to Tj varies by component. >> >> 85C in a vehicle? Yikes. I would not dare to design that in. > > It's a fact of life. Think JimT's car interior, parked in the > driveway in August. The last measurement I remember for under the dash where electronics often live was 190F on a 98F day, with sun exposure and windows up. Meaning the classic situation in the airport economy lot where the car bakes 8-10h per day. That is over 87C, and this assumes the electronics do not run and thus do not generate heat in addition. Now imagine a 115F day which is not unusual in places like AZ or NM. > ... Design to 85C isn't just a good idea, it's the > spec (-40C to 85C). It is a bad spec. The result of such flawed design evidences itself over and over. For example, the minivan of friends of ours would not start when parked at a mall on a hot day after more than 15mins of driving. It would (sometimes) come back to life if you let it sit for half an hour so the radiated engine heat became less. In the winter it was mostly ok. That design is IMHO junk. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-08 20:20 -0400 |
| Message-ID | <5v4q29pr73g0gqgeeld2fr0lc0ppegval2@4ax.com> |
| In reply to | #13409 |
On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid> wrote: >krw@attt.bizz wrote: >> On Sun, 08 Sep 2013 15:57:29 -0700, Joerg <invalid@invalid.invalid> >> wrote: >> >>> krw@attt.bizz wrote: >>>> On Sun, 08 Sep 2013 14:20:46 -0700, Joerg <invalid@invalid.invalid> >>>> wrote: >>>> >>>>> krw@attt.bizz wrote: >>>>>> On Sun, 08 Sep 2013 09:34:38 -0700, Joerg <invalid@invalid.invalid> >>>>>> wrote: >>>>>> >>>>>>> krw@attt.bizz wrote: >>>>>>>> On Sat, 07 Sep 2013 15:23:39 -0700, Joerg <invalid@invalid.invalid> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> rickman wrote: >>>>>>>>>> On 9/7/2013 4:46 PM, Joerg wrote: >>>>>>>>>>> Paul Rubin wrote: >>>>>>>>>>>> Joerg<invalid@invalid.invalid> writes: >>>>>>>>>>>>> I don't see how the equivalent of a TMS320 or a big MSP430 could fit >>>>>>>>>>>>> into one of these small Lattice devices. >>>>>>>>>>>> I had thought the parts of those processors that would bloat up badly >>>>>>>>>>>> (instruction decode etc.) are pretty simple so the overall effect of the >>>>>>>>>>>> bloat is ok in the scheme of things. The parts doing the most work >>>>>>>>>>>> (memory, arithmetic) are done in the FPGA hardware (RAM and DSP blocks, >>>>>>>>>>>> adders connected to the LUT's somehow) as efficiently as on the MCU's. >>>>>>>>>>>> >>>>>>>>>>>> I do think softcores seem like a silly idea a lot of the time, and am >>>>>>>>>>>> looking forward to more low end FPGA's with MCU blocks. >>>>>>>>>>> Much of it has to do with legacy code. Yes, some things could even be >>>>>>>>>>> done more efficiently in the FPGA because you can actually streamline >>>>>>>>>>> the HW to the task, something neither uC nor DSP allow. For example, why >>>>>>>>>>> have a 32-bit HW multiplier when you know you'll never exceed 23 bits? >>>>>>>>>>> But legacy code won't run anymore and you need FPGA specialists to make >>>>>>>>>>> it all work. >>>>>>>>>> No, you would need a DSP specialist. The FPGA designer only needs to >>>>>>>>>> know how to code the FPGA. >>>>>>>>>> >>>>>>>>> So for this kind of solution in an FPGA you need a DSP specialist and an >>>>>>>>> FPGA specialist? That would be a problem. >>>>>>>> Pick ones that are in the automotive market. Support for fifteen >>>>>>>> years is required. >>>>>>>> >>>>>>> That's a good point. How does one find out which ones those are? >>>>>> Click on the "Automotive" tab on the applications page in their web >>>>>> site? Look for the ACQ- compliance designations? >>>>>> >>>>> I usually go in via Digikey. No automotive tab in that segment but the >>>>> temperature range gives it away. >>>> Not at all. Automotive and industrial temperatures are quite alike >>>> but the qualifications certainly are not. Automotive needs 85C >>>> ambient. What that does to Tj varies by component. >>> >>> 85C in a vehicle? Yikes. I would not dare to design that in. >> >> It's a fact of life. Think JimT's car interior, parked in the >> driveway in August. > > >The last measurement I remember for under the dash where electronics >often live was 190F on a 98F day, with sun exposure and windows up. >Meaning the classic situation in the airport economy lot where the car >bakes 8-10h per day. That is over 87C, and this assumes the electronics >do not run and thus do not generate heat in addition. Now imagine a 115F >day which is not unusual in places like AZ or NM. > > >> ... Design to 85C isn't just a good idea, it's the >> spec (-40C to 85C). > > >It is a bad spec. The result of such flawed design evidences itself over >and over. For example, the minivan of friends of ours would not start >when parked at a mall on a hot day after more than 15mins of driving. It >would (sometimes) come back to life if you let it sit for half an hour >so the radiated engine heat became less. In the winter it was mostly ok. >That design is IMHO junk. Oh, the spec I mentioned above isn't for the engine compartment or any of the ignition or safety gadgets. It's for the noise makers. ;-) yes, that's the unpowered temperature. Temp rise has to be added to that.
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-09 07:17 -0700 |
| Message-ID | <b963k2F2mrkU1@mid.individual.net> |
| In reply to | #13410 |
krw@attt.bizz wrote: > On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> krw@attt.bizz wrote: [...] >>> ... Design to 85C isn't just a good idea, it's the >>> spec (-40C to 85C). >> >> It is a bad spec. The result of such flawed design evidences itself over >> and over. For example, the minivan of friends of ours would not start >> when parked at a mall on a hot day after more than 15mins of driving. It >> would (sometimes) come back to life if you let it sit for half an hour >> so the radiated engine heat became less. In the winter it was mostly ok. >> That design is IMHO junk. > > Oh, the spec I mentioned above isn't for the engine compartment or any > of the ignition or safety gadgets. It's for the noise makers. ;-) > yes, that's the unpowered temperature. Temp rise has to be added to > that. > Ok, if the radio quits on a hot day that isn't going to cause much grief. Happened to me but luckily within the warranty period. It's annoying though, leaves kind of a cheap feeling about the whole car even though the car doesn't deserve that. Radios are usually in the dash and that can exceed 80C on hot days. Then the driver hops into the car, turns on the stereo, pops in the Eric Clapton CD, listens to "Cocaine" with the volume on 10 and ... *PHUT* ... :-) -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-09 12:17 -0700 |
| Message-ID | <b96l6nF6h2lU2@mid.individual.net> |
| In reply to | #13423 |
Joerg wrote: > krw@attt.bizz wrote: >> On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid> >> wrote: >> >>> krw@attt.bizz wrote: > > [...] > >>>> ... Design to 85C isn't just a good idea, it's the >>>> spec (-40C to 85C). >>> It is a bad spec. The result of such flawed design evidences itself over >>> and over. For example, the minivan of friends of ours would not start >>> when parked at a mall on a hot day after more than 15mins of driving. It >>> would (sometimes) come back to life if you let it sit for half an hour >>> so the radiated engine heat became less. In the winter it was mostly ok. >>> That design is IMHO junk. >> Oh, the spec I mentioned above isn't for the engine compartment or any >> of the ignition or safety gadgets. It's for the noise makers. ;-) >> yes, that's the unpowered temperature. Temp rise has to be added to >> that. >> > > Ok, if the radio quits on a hot day that isn't going to cause much > grief. Happened to me but luckily within the warranty period. It's > annoying though, leaves kind of a cheap feeling about the whole car even > though the car doesn't deserve that. Radios are usually in the dash and > that can exceed 80C on hot days. Then the driver hops into the car, > turns on the stereo, pops in the Eric Clapton CD, listens to "Cocaine" > with the volume on 10 and ... *PHUT* ... :-) > Question: What do you do with an FPGA in a radio? -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-09 19:30 -0400 |
| Message-ID | <nams29529059lnj172shr1p97ni0r9phte@4ax.com> |
| In reply to | #13437 |
On Mon, 09 Sep 2013 12:17:34 -0700, Joerg <invalid@invalid.invalid> wrote: >Joerg wrote: >> krw@attt.bizz wrote: >>> On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid> >>> wrote: >>> >>>> krw@attt.bizz wrote: >> >> [...] >> >>>>> ... Design to 85C isn't just a good idea, it's the >>>>> spec (-40C to 85C). >>>> It is a bad spec. The result of such flawed design evidences itself over >>>> and over. For example, the minivan of friends of ours would not start >>>> when parked at a mall on a hot day after more than 15mins of driving. It >>>> would (sometimes) come back to life if you let it sit for half an hour >>>> so the radiated engine heat became less. In the winter it was mostly ok. >>>> That design is IMHO junk. >>> Oh, the spec I mentioned above isn't for the engine compartment or any >>> of the ignition or safety gadgets. It's for the noise makers. ;-) >>> yes, that's the unpowered temperature. Temp rise has to be added to >>> that. >>> >> >> Ok, if the radio quits on a hot day that isn't going to cause much >> grief. Happened to me but luckily within the warranty period. It's >> annoying though, leaves kind of a cheap feeling about the whole car even >> though the car doesn't deserve that. Radios are usually in the dash and >> that can exceed 80C on hot days. Then the driver hops into the car, >> turns on the stereo, pops in the Eric Clapton CD, listens to "Cocaine" >> with the volume on 10 and ... *PHUT* ... :-) >> > >Question: What do you do with an FPGA in a radio? Lotsa possibilities. So far very few real applications; too expensive. These are not your father's Blaupunkts. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-09 16:38 -0700 |
| Message-ID | <b974g2F9jjoU1@mid.individual.net> |
| In reply to | #13442 |
krw@attt.bizz wrote: > On Mon, 09 Sep 2013 12:17:34 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> Joerg wrote: >>> krw@attt.bizz wrote: >>>> On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid> >>>> wrote: >>>> >>>>> krw@attt.bizz wrote: >>> [...] >>> >>>>>> ... Design to 85C isn't just a good idea, it's the >>>>>> spec (-40C to 85C). >>>>> It is a bad spec. The result of such flawed design evidences itself over >>>>> and over. For example, the minivan of friends of ours would not start >>>>> when parked at a mall on a hot day after more than 15mins of driving. It >>>>> would (sometimes) come back to life if you let it sit for half an hour >>>>> so the radiated engine heat became less. In the winter it was mostly ok. >>>>> That design is IMHO junk. >>>> Oh, the spec I mentioned above isn't for the engine compartment or any >>>> of the ignition or safety gadgets. It's for the noise makers. ;-) >>>> yes, that's the unpowered temperature. Temp rise has to be added to >>>> that. >>>> >>> Ok, if the radio quits on a hot day that isn't going to cause much >>> grief. Happened to me but luckily within the warranty period. It's >>> annoying though, leaves kind of a cheap feeling about the whole car even >>> though the car doesn't deserve that. Radios are usually in the dash and >>> that can exceed 80C on hot days. Then the driver hops into the car, >>> turns on the stereo, pops in the Eric Clapton CD, listens to "Cocaine" >>> with the volume on 10 and ... *PHUT* ... :-) >>> >> Question: What do you do with an FPGA in a radio? > > Lotsa possibilities. So far very few real applications; too > expensive. ... I look at radio and other consumer gear a lot, mainly to spot interesting ICs and other parts that I might be able to use on my designs. Never seen an FPGA in there, ever. > ... These are not your father's Blaupunkts. ;-) I know, dad's Blaupunkts were better :-( Still got one in the garage. In terms of large signal handling and intermodulation it runs circles around just about anything made today. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | krw@attt.bizz |
|---|---|
| Date | 2013-09-10 14:02 -0400 |
| Message-ID | <oenu291o9uugc0scqpdbvbu8vedbvg8d9u@4ax.com> |
| In reply to | #13443 |
On Mon, 09 Sep 2013 16:38:32 -0700, Joerg <invalid@invalid.invalid> wrote: >krw@attt.bizz wrote: >> On Mon, 09 Sep 2013 12:17:34 -0700, Joerg <invalid@invalid.invalid> >> wrote: >> >>> Joerg wrote: >>>> krw@attt.bizz wrote: >>>>> On Sun, 08 Sep 2013 17:15:18 -0700, Joerg <invalid@invalid.invalid> >>>>> wrote: >>>>> >>>>>> krw@attt.bizz wrote: >>>> [...] >>>> >>>>>>> ... Design to 85C isn't just a good idea, it's the >>>>>>> spec (-40C to 85C). >>>>>> It is a bad spec. The result of such flawed design evidences itself over >>>>>> and over. For example, the minivan of friends of ours would not start >>>>>> when parked at a mall on a hot day after more than 15mins of driving. It >>>>>> would (sometimes) come back to life if you let it sit for half an hour >>>>>> so the radiated engine heat became less. In the winter it was mostly ok. >>>>>> That design is IMHO junk. >>>>> Oh, the spec I mentioned above isn't for the engine compartment or any >>>>> of the ignition or safety gadgets. It's for the noise makers. ;-) >>>>> yes, that's the unpowered temperature. Temp rise has to be added to >>>>> that. >>>>> >>>> Ok, if the radio quits on a hot day that isn't going to cause much >>>> grief. Happened to me but luckily within the warranty period. It's >>>> annoying though, leaves kind of a cheap feeling about the whole car even >>>> though the car doesn't deserve that. Radios are usually in the dash and >>>> that can exceed 80C on hot days. Then the driver hops into the car, >>>> turns on the stereo, pops in the Eric Clapton CD, listens to "Cocaine" >>>> with the volume on 10 and ... *PHUT* ... :-) >>>> >>> Question: What do you do with an FPGA in a radio? >> >> Lotsa possibilities. So far very few real applications; too >> expensive. ... > > >I look at radio and other consumer gear a lot, mainly to spot >interesting ICs and other parts that I might be able to use on my >designs. Never seen an FPGA in there, ever. They're not common yet but they will find their way in. Again, cost is the biggest barrier. OTOH, function will eventually demand them. >> ... These are not your father's Blaupunkts. ;-) > > >I know, dad's Blaupunkts were better :-( Hardly. Dad never had a 17" LCD display on his and the XM reception sucked. ;-) >Still got one in the garage. In terms of large signal handling and >intermodulation it runs circles around just about anything made today. You want to listen to AM/FM radio stations? What kind of nut are you, anyway? ;-)
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web