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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-13 15:24 -0400 |
| Message-ID | <l0vope$uku$1@dont-email.me> |
| In reply to | #13545 |
On 9/13/2013 12:43 PM, Piotr Wyderski wrote: > rickman wrote: > >> I don't see how your personal memory has much to do with it. Most >> programmers use >> the tools, meaning HHL compilers. The main point of using an HLL is to >> *not* need to know anything about the instruction set. If you can't >> write HLL code for the specific CPU involved, then you have other issues. > > Rickman, professionally I am a low-level programmer. I mostly do > weird optimizations, often at the assembly level. Can read assembly > output generated by a compiler for several ISAs without any problem. > Everyone is smart when things go right. When something fails, without > that knowledge you are like a child in the fog. Please, do not teach > me my craft. :-) I won't teach you anything if you don't want to learn. >>> In my case it's PCB routing complexity. I am not going >>> to use 4+ layers of copper just to satisfy the monster's >>> signal integrity requirements. 2 layers is all I can have. >> >> Uh, what monster??? > > A great big FPGA chip which package imposes crazy > (for a hobbyist) PCB routing requirements. You mean like a 100 pin quad flat pack? Are you even trying to look at possibilities? This is the sort of bias about FPGAs that I keep running into. Here is a board I make with an FPGA, a CODEC, some buffering and analog drivers. http://arius.com/images/IRIGB_board_1-0.png The board is 0.85" x 4.5". An MCU could not provide the SPI "like" control interface from the motherboard and it would have been *very* hard to generate the clock timing for the CODEC which in one mode has to be slaved to the incoming data rate on an RS-422 interface. >> I'm not sure that is impossible on an MCU. Maybe it is impossible on an >> MCU you can buy, but a custom design might do nicely. > > Rickman, please... ;-) Please what? Is it possible that you aren't aware of all CPUs out there? >> But since you can have so many CPUs on even a smallish FPGA, I expect >> you could >> divide and conquer quite easily. > > But what for? A PWM generator is a no-brainer in VHDL. One can also > stream out the content of a BRAM in a loop directly to the IO pins, > which allows one to implement fancy spectrum spreading techniques, > equalize the amount of power consumed by shifting the relative > phases of the PWM channels, etc. One BRAM = 18 channels. Cheap. :-) > And a CPU to generate the actual waveforms off-line, even a tiny one. But something has to control the PWM. So if you have software controlling the PWM you have to decide how much is in software and how much is in hardware. I don't know your requirements so I can't speak as to where the optimal trade off point would be. >> You can wave the same hands for CPU cycles. The only difference is MCU >> I/Os are not as flexible, typically being constrained to one set of pins >> or a small selection of I/Os. I guess that was your point? > > More or less. I wanted to highlight that a CPU has e.g. a timer input > with input capture timestamping connected to a dedicated pin. When the > PCB is etched and you discover that connecting another pin to that input > capture allows you to do something smart, you have a problem. In case > of an FPGA you just provide an additional internal "wire" in the > routing section and presto, problem solved. > >> If your designs are so slow that isn't an issue, fine, but that >> is not very common. > > If it is necessary, I can use a dedicated pin. But I don't use > those multi-gigabit transceivers etc., so, except of the clock, > a generic IO pin is fine for most of my signals. You are thinking of SERDES which are specialized functions... because they are impossible to do in the FPGA fabric. But dedicated clock pins have been around almost since the beginning of FPGAs. >> Check out the GA144 from greenarrays.com. > > I've checked that years ago and it still is in the mental bin > labelled "bizarre". It is neither a CPU, nor an FPGA, gracefully > merging disadvantages of both. :-) It does have its limitations, I agree. But is has some great features. I would use it to redo the board in the image above but I don't have enough confidence in the survival of the company. The redo is because of one of the very few EOL notices on an FPGA that I just happen to be using. The GA144 could do the job pretty well I think. >>> The toolchain is mature. >> >> How mature do you need? > > The so-called industrial quality. As seen in case of > x86/ARM/PowerPC/SPARC and maybe MIPS. I don't know what "industrial quality" is. I think the tools for the microBlaze, the NIOS, NIOS2, etc are all widely used and well debugged. Have you heard any complaints? >> Then don't use a Cyclone/Spartan part... > > That's complicated. First of all, I (would) use an FPGA I can > easily buy in smal quantities. Secondly, I know the toolchain. > The experience with mediaeval-quality Lattice software ~10 years > ago has considerably chilled my enthusiasm about the "alternatives". The project I give the image for above uses a Lattice part and I had no trouble with the tools. We all have our biases. >> The packages may not make you happy though. They seem to think >> the Smart Fusion chips need a bazillion I/Os. > > TQFP is the only package I can handle. But will have a look, > just to learn something new. Then I think you are out of luck with the SmartFusion. The GA144 is available on a mounting board from Schmartboard. They sent me one of the boards without the chip. Interesting. They route the top layer of fiberglass down to an inner copper layer and drop a bead of solder in it. I think the idea is to work with leaded parts like the QFP, but they say it works with leadless parts too. Essentially the PCB forms a one or two mm high solder mask and the solder acts like a heat pipe to allow connection to QFN pins on the underside of the chip. http://blog.schmartboard.com/blogschmartboard/2013/09/greenarrays-month-at-schmartboardand-you-can-try-it-save-some-green.html -- Rick
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@removethis.hesbynett.no> |
|---|---|
| Date | 2013-09-13 20:22 +0200 |
| Message-ID | <BOednWKeTL1ryq7PnZ2dnUVZ7qmdnZ2d@lyse.net> |
| In reply to | #13536 |
On 13/09/13 14:08, Piotr Wyderski wrote: > As I said, I need ~40 PWM channels, 4 CANs and/or 6 RS485 + Ethernet. > Impossible on an MCU, so an FPGA (probably a Spartan 6 in TQFP144) > is the most promising candidate. But the rest is so much CPUish... > The Freescale MPC5675K has 54 channels of PWM, 4 CANs, 4 UARTs, and Ethernet - plus loads of other peripherals. That's only 2 UARTs short of your requirements there, but maybe there are other MPC devices that cover everything (I haven't looked at them all - just the one device I have used myself). Certainly it would not be hard to use a couple of timer channels connected to DMA to make the final two UARTs - or you could do it in pure software, as you have plenty of processor power (2 PPC cores at 180 MHz). An FPGA may be the best choice for your application - but it is certainly not the only choice.
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 09:32 -0700 |
| Message-ID | <b912ocF1iq9U1@mid.individual.net> |
| In reply to | #13342 |
rickman wrote: > On 9/7/2013 4:24 AM, John Devereux wrote: >> rickman<gnuarm@gmail.com> writes: >> >>> If your FPGA designs are expensive or power hungry, then you are doing >>> things you can't do in an MCU or you are not using FPGAs properly. >>> They don't need to use any more power than an MCU and in many cases >>> less. They certainly don't need to be significantly more expensive >>> unless you consider every dollar in your designs. At the very low end >>> MCUs can be under $1 and still have reasonable performance. For $1 >>> you can't get much in the way of programmable logic. For $3 however, >>> you can get a chip large enough for a CPU (with math) and room for >>> your special logic. >> >> I've never used an FPGA, microcontrollers have increased in speed faster >> than my needs so far. So I can usually bitbang everything or use a >> peripheral. I used PLDs for glue logic back in the day but that's it. Oh >> and I bought a small xilinx dev kit which I got to make a led flash then >> put in a drawer for 15 years. > > So your use of MCUs is based on inertia? > > >> But could you give an example of your $3 one? Or a favorite? > > A startup company called Silicon Blue came out with a line of FPGAs > targeted to the high volume, low power market that exists for portable > devices. They were preparing their second device family and were bought > by Lattice Semi. The first family was dropped and the second family is > the iCE40 (for 40 nm). They are very low power although smallish. The > largest one has 8 kLUTs, the smallest 384 LUTs. > > Last winter I was looking at designing a very low power radio controlled > clock to run in one of these. They were still playing a shell game with > the devices in the lineup and the 640 LUT part I wanted to use was > dropped... :( The only real problem I have with these devices is the > packaging. Because of the target market the packages are mostly fine > pitch BGAs. Great if you are making a cell phone, not so great if you > are designing other equipment. > > You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts. > It has been a while since I got a quote. The 1 kLUT part is big enough > for a soft core MCU plus some custom logic. > Got a mfg and part number? Or a Digikey link? > BTW, with MCUs Digikey will give you a realistic price quote. In the > FPGA world the distis never give you a good price unless you ask for a > quantity quote. I have gotten prices quoted to me that were half the > list price. FPGA companies play a different marketing game and have a > lot of room to negotiate in order to buy a socket. > Yeah, the old haggle game. Beats my why they still cling to such medieval sales tactics. The only other market where that is customary is with used car salesmen. They don't even know how much in business opportunity they are missing because of this. Guys like me need pricing info here, this minute, right now. If there is even as much as a label "Call" I usually move on. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 13:44 -0400 |
| Message-ID | <l0fold$cc4$1@dont-email.me> |
| In reply to | #13346 |
On 9/7/2013 12:32 PM, Joerg wrote: > rickman wrote: >> >> You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts. >> It has been a while since I got a quote. The 1 kLUT part is big enough >> for a soft core MCU plus some custom logic. >> > > > Got a mfg and part number? Or a Digikey link? At Digikey search on iCE40. That will give you a listing of all the parts. Looks like Digikey's prices are a little high, not just because they are Digikey. The $3 figure I gave is from quotes I got from Silicon Blue before they were traded through Digikey. Like I said, you need to get a quote on any FPGA to find the "real" price. >> BTW, with MCUs Digikey will give you a realistic price quote. In the >> FPGA world the distis never give you a good price unless you ask for a >> quantity quote. I have gotten prices quoted to me that were half the >> list price. FPGA companies play a different marketing game and have a >> lot of room to negotiate in order to buy a socket. >> > > Yeah, the old haggle game. Beats my why they still cling to such > medieval sales tactics. The only other market where that is customary is > with used car salesmen. > > They don't even know how much in business opportunity they are missing > because of this. Guys like me need pricing info here, this minute, right > now. If there is even as much as a label "Call" I usually move on. I don't think it is all about the "haggle". I think no small part is about doing what it takes to get the design in and deny the competition. When you get quotes from Digikey web site they never even know you are looking at their parts. Think of it as a live auction vs. sealed bids. They prefer to be in the live auction. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 12:46 -0700 |
| Message-ID | <b91e5pF3tu7U1@mid.individual.net> |
| In reply to | #13350 |
rickman wrote: > On 9/7/2013 12:32 PM, Joerg wrote: >> rickman wrote: >>> >>> You can get the 1 kLUT parts for under $3 and possibly the 4 kLUT parts. >>> It has been a while since I got a quote. The 1 kLUT part is big >>> enough >>> for a soft core MCU plus some custom logic. >>> >> >> >> Got a mfg and part number? Or a Digikey link? > > At Digikey search on iCE40. That will give you a listing of all the > parts. Looks like Digikey's prices are a little high, not just because > they are Digikey. The $3 figure I gave is from quotes I got from > Silicon Blue before they were traded through Digikey. ... Which part number? I don't see how the equivalent of a TMS320 or a big MSP430 could fit into one of these small Lattice devices. > ... Like I said, you > need to get a quote on any FPGA to find the "real" price. > I don't play those games. Or only once every 20-some years when buying a car, and then the car dealer may develop an ulcer when we are done. > >>> BTW, with MCUs Digikey will give you a realistic price quote. In the >>> FPGA world the distis never give you a good price unless you ask for a >>> quantity quote. I have gotten prices quoted to me that were half the >>> list price. FPGA companies play a different marketing game and have a >>> lot of room to negotiate in order to buy a socket. >>> >> >> Yeah, the old haggle game. Beats my why they still cling to such >> medieval sales tactics. The only other market where that is customary is >> with used car salesmen. >> >> They don't even know how much in business opportunity they are missing >> because of this. Guys like me need pricing info here, this minute, right >> now. If there is even as much as a label "Call" I usually move on. > > I don't think it is all about the "haggle". I think no small part is > about doing what it takes to get the design in and deny the competition. > When you get quotes from Digikey web site they never even know you are > looking at their parts. Think of it as a live auction vs. sealed bids. > They prefer to be in the live auction. > Well, most design engineers don't. tti lost a deal on capacitors last week because they wouldn't let me look at the details of a cap without entering some stupid captcha. Which as usual didn't work. I moved on and found it elsewhere. I simply do not have the time for such games. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-09-07 13:33 -0700 |
| Message-ID | <7xfvtggynf.fsf@ruckus.brouhaha.com> |
| In reply to | #13356 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 13:46 -0700 |
| Message-ID | <b91hlbF4kf2U1@mid.individual.net> |
| In reply to | #13358 |
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. It's like with Excel. There's better programs out there but one core reason why companies stick to it is the huge repository of VBA applications they have created over the years. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 17:05 -0400 |
| Message-ID | <l0g4fn$f4a$3@dont-email.me> |
| In reply to | #13360 |
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. But that is exactly the point of the FPGA in DSP apps. You code to the app, not to a processor. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 15:23 -0700 |
| Message-ID | <b91nbhF5n6iU1@mid.individual.net> |
| In reply to | #13362 |
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. > 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. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 19:02 -0400 |
| Message-ID | <l0gbbf$mr6$1@dont-email.me> |
| In reply to | #13366 |
On 9/7/2013 6:23 PM, Joerg 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. You can do it anyway you want. I'm just making the distinction between DSP knowledge and FPGA knowledge. They aren't very much the same. I also make a distinction between a DSP designer and a DSP coder. Again, not much in common. Coding doesn't really require a lot of DSP knowledge and DSP designers often aren't experts at coding the finicky chips. >> 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. Life span is typically *much* better than MCUs. First, there are *no* second sources so whatever chip family you select is the only one that will fit your layout. There *may* be more than one member of that family that will fit the same socket, that is common, but not guaranteed. So you often will get a choice of two, three or four sizes and you often get an upgrade path from your first selection. Just in case you are familiar with the compilation process, in an FPGA you *always* have to recompile for the target. Even if they are pin compatible you can't load a design for an whatever-02 chip into a whatever-03 part. Those are the limitations. As to the market life, that it typically well over 10 years. Spartan 3 was introduced some 10 years ago and it is not yet the oldest chip Xilinx has in current full production. I'm still considering using it for new designs. Similar situation for Altera. I was just burned by Lattice announcing EOL of their XP line. This was because they got a new guy in at the top with a new broom I suppose. I'm sure you can find various MCUs which have been in production for 10 years, but I know Atmel likes to replace products from time to time with similar "pin compatible" devices which are 99.9% compatible. I expect for the 8 bit parts life span is not such an issue. For the larger parts I expect life span is a bit more limited and for the top end chips, I'm pretty sure their life span is measured in double digit months. Can you still buy any of the Pentium 4s that were all over the place seven or eight years ago? I can't even find a Core 2 Duo. What lifespan have you seen for MCUs? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-07 16:45 -0700 |
| Message-ID | <b91s4lF6lupU1@mid.individual.net> |
| In reply to | #13369 |
rickman wrote: > On 9/7/2013 6:23 PM, Joerg 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. > > You can do it anyway you want. I'm just making the distinction between > DSP knowledge and FPGA knowledge. They aren't very much the same. I > also make a distinction between a DSP designer and a DSP coder. Again, > not much in common. Coding doesn't really require a lot of DSP > knowledge and DSP designers often aren't experts at coding the finicky > chips. > I have learned that with uC as well. There are lots of programmers but not too many who can lay down a realtime program architecture. So I do that a lot. And I am a guy who cannot really program uCs very easily, I don't speak much C. With DSP it's the same and I would expect that also from FPGA. I propose an architecture, what needs to be calculated, and when. Then a programmer takes over. But I can't justify more than one person for that. So if some or a lot of uC or DSP core have to be poured into an FPGA then I guess the FPGA guys has to take over both. > >>> 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. > > Life span is typically *much* better than MCUs. > > First, there are *no* second sources so whatever chip family you select > is the only one that will fit your layout. ... That is one of my concerns. With 8051 uCs you have multiple sources as long as you stick to customary packages such as a 44-pin flat-pack. > ... There *may* be more than one > member of that family that will fit the same socket, that is common, but > not guaranteed. So you often will get a choice of two, three or four > sizes and you often get an upgrade path from your first selection. Just > in case you are familiar with the compilation process, in an FPGA you > *always* have to recompile for the target. Even if they are pin > compatible you can't load a design for an whatever-02 chip into a > whatever-03 part. Those are the limitations. > Yeah, that I was aware of. And changing to a whatever-03 would be a major headache in many of my cases. Because it's medical, aerospace similar where that can trigger a complete re-cert. > As to the market life, that it typically well over 10 years. Spartan 3 > was introduced some 10 years ago and it is not yet the oldest chip > Xilinx has in current full production. I'm still considering using it > for new designs. Similar situation for Altera. ... Well over 10 years is good. But only if that means no change to any new versions that require a re-compile. Early on in my career that happened and one guy promptly got busy with three months of regression testing. Oh what fun. > ... I was just burned by > Lattice announcing EOL of their XP line. This was because they got a > new guy in at the top with a new broom I suppose. > Not so cool :-( > I'm sure you can find various MCUs which have been in production for 10 > years, but I know Atmel likes to replace products from time to time with > similar "pin compatible" devices which are 99.9% compatible. I expect > for the 8 bit parts life span is not such an issue. For the larger > parts I expect life span is a bit more limited and for the top end > chips, I'm pretty sure their life span is measured in double digit > months. Can you still buy any of the Pentium 4s that were all over the > place seven or eight years ago? Yup: http://components.arrow.com/part/detail/41596500S6440784N2936?region=na > ... I can't even find a Core 2 Duo. No problem either: http://components.arrow.com/part/detail/42952225S9497728N2936?region=na > > What lifespan have you seen for MCUs? > The 89C51 I designed in in the mid-90's is still living. Not sure how long it was in production when I designed it in. The nice thing is that these are made by several companies, even Asian ones such as Winbond. So it was no surprise when I took apart our pellet stove for maintenance and found one of those in there as well. 2nd source is important to me, and my clients. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-07 23:16 -0400 |
| Message-ID | <l0gq7v$ihv$1@dont-email.me> |
| In reply to | #13373 |
On 9/7/2013 7:45 PM, Joerg wrote: > rickman 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. >> >> First, there are *no* second sources so whatever chip family you select >> is the only one that will fit your layout. ... > > > That is one of my concerns. With 8051 uCs you have multiple sources as > long as you stick to customary packages such as a 44-pin flat-pack. Yes, but 8051s aren't DSPs either are they? You seem to be switching gears again. I can't keep up. I know you do different designs, but can the FPGA be wrong for *all* of them? You seem to have all requirements for all designs. >> ... There *may* be more than one >> member of that family that will fit the same socket, that is common, but >> not guaranteed. So you often will get a choice of two, three or four >> sizes and you often get an upgrade path from your first selection. Just >> in case you are familiar with the compilation process, in an FPGA you >> *always* have to recompile for the target. Even if they are pin >> compatible you can't load a design for an whatever-02 chip into a >> whatever-03 part. Those are the limitations. >> > > Yeah, that I was aware of. And changing to a whatever-03 would be a > major headache in many of my cases. Because it's medical, aerospace > similar where that can trigger a complete re-cert. Why would you need to change to the whatever-03. Once it is qualified you can stick with it. My point is that you have flexibility in the device, no one is making you switch. >> As to the market life, that it typically well over 10 years. Spartan 3 >> was introduced some 10 years ago and it is not yet the oldest chip >> Xilinx has in current full production. I'm still considering using it >> for new designs. Similar situation for Altera. ... > > > Well over 10 years is good. But only if that means no change to any new > versions that require a re-compile. Early on in my career that happened > and one guy promptly got busy with three months of regression testing. > Oh what fun. Why not talk to the vendors? >> ... I was just burned by >> Lattice announcing EOL of their XP line. This was because they got a >> new guy in at the top with a new broom I suppose. >> > > Not so cool :-( Yeah, I'm unhappy about it. I thought I could get more development funds for a redo but the division reselling this board in their product doesn't want to spend any cash on it. I've been asked to spend my dime and I likely will. I make good money on this product. >> I'm sure you can find various MCUs which have been in production for 10 >> years, but I know Atmel likes to replace products from time to time with >> similar "pin compatible" devices which are 99.9% compatible. I expect >> for the 8 bit parts life span is not such an issue. For the larger >> parts I expect life span is a bit more limited and for the top end >> chips, I'm pretty sure their life span is measured in double digit >> months. Can you still buy any of the Pentium 4s that were all over the >> place seven or eight years ago? > > > Yup: > > http://components.arrow.com/part/detail/41596500S6440784N2936?region=na > > >> ... I can't even find a Core 2 Duo. > > > No problem either: > > http://components.arrow.com/part/detail/42952225S9497728N2936?region=na How do you know these are the parts that were designed in the system of interest? They made a huge number of variants and I know I have seen EOL notices for Pentium 4s. >> What lifespan have you seen for MCUs? >> > > The 89C51 I designed in in the mid-90's is still living. Not sure how > long it was in production when I designed it in. The nice thing is that > these are made by several companies, even Asian ones such as Winbond. So > it was no surprise when I took apart our pellet stove for maintenance > and found one of those in there as well. > > 2nd source is important to me, and my clients. If you really need that level of consistency, then you will be using nothing but 8051s all your career. I don't know of any digital component that has lived as long as the 8051 other than perhaps LS-TTL. I also don't know of any other MCU that is second sourceds. If the 8051 does what you need, then go for it. But again you are mixing conversations. That's why it is so frustrating to have a conversation with you. You talk about not being able to use a part unless it has a product life as long as the 8051 and then you talk about using various DSP chips in the same context. I *know* you won't be able to buy those DSP chips 10 years from now. TI just doesn't provide that level of support unless they have a special program for long lived parts I'm not aware of. I've seen lightly selling DSPs drop from the marketplace after less than 5 years. The DSP market was just a tiny exploration by TI initially. Then they saw cell phones as a way to utilize that capability. They actually reorganized the entire company to take full advantage of it. As a result they ended up with four segments for DSPs. 1) Cell phone devices - small, low power and cheap in large quantities. Not much need for longevity at all... basically the C5xxx line. 2) Cell base stations - powerful devices that can handle multiple channels, power consumption not important and cost is secondary. This is the C6xxx line. Again, they focus on new, not longevity. 3) Scientific DSP - floating point. C67xx lines. Relatively low volumes compared to the other two, but they seem to think it is an important market. New designs are not as frequent. Longevity might be better than the other two, but no promises. 4) Motor control, white goods, etc - fixed point with price the major factor. These have appeared in a range of variations, some with flash, some with ADCs, etc. These are almost MCUs with simlar performance, slow compared to segment 1 and 2. Intended for high volume apps, but again, longevity is not important. So if you are going to consider DSPs for your apps, I expect you would be looking at the last category. I'm pretty sure I wouldn't be designing from this group if I wanted to be building this board 10 years from now though. Have you talked to TI about longevity? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 08:05 -0700 |
| Message-ID | <b93i2iFh16mU1@mid.individual.net> |
| In reply to | #13376 |
rickman wrote: > On 9/7/2013 7:45 PM, Joerg wrote: >> rickman 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. >>> >>> First, there are *no* second sources so whatever chip family you select >>> is the only one that will fit your layout. ... >> >> >> That is one of my concerns. With 8051 uCs you have multiple sources as >> long as you stick to customary packages such as a 44-pin flat-pack. > > Yes, but 8051s aren't DSPs either are they? You seem to be switching > gears again. I can't keep up. I know you do different designs, but can > the FPGA be wrong for *all* of them? You seem to have all requirements > for all designs. > I do various designs, sometimes simultaneously. For DSP we often just plop down a TMS320 bare-bones edition and be done with it. It's like buying a Ford F-150 for the ranch, it may be too big but it is not expensive and you almost can't go wrong with it. I had designs where the DSP workload ended up at 5% but at $3 pop nobody was concerned. And no, mostly I don't even have the requirements until after the project already started. Sometimes weeks down the road the sensor guys call in, "Houston, we have a problem". This is the kind of project companies like to use consultants for, since it can be utterly frustrating for engineers. Us guys are use to this stuff. > >>> ... There *may* be more than one >>> member of that family that will fit the same socket, that is common, but >>> not guaranteed. So you often will get a choice of two, three or four >>> sizes and you often get an upgrade path from your first selection. Just >>> in case you are familiar with the compilation process, in an FPGA you >>> *always* have to recompile for the target. Even if they are pin >>> compatible you can't load a design for an whatever-02 chip into a >>> whatever-03 part. Those are the limitations. >>> >> >> Yeah, that I was aware of. And changing to a whatever-03 would be a >> major headache in many of my cases. Because it's medical, aerospace >> similar where that can trigger a complete re-cert. > > Why would you need to change to the whatever-03. Once it is qualified > you can stick with it. My point is that you have flexibility in the > device, no one is making you switch. > I was thinking about the case where whatever-02 becomes unobtanium. > >>> As to the market life, that it typically well over 10 years. Spartan 3 >>> was introduced some 10 years ago and it is not yet the oldest chip >>> Xilinx has in current full production. I'm still considering using it >>> for new designs. Similar situation for Altera. ... >> >> >> Well over 10 years is good. But only if that means no change to any new >> versions that require a re-compile. Early on in my career that happened >> and one guy promptly got busy with three months of regression testing. >> Oh what fun. > > Why not talk to the vendors? > We did that and all we got was a "Sorry about that". The designed-in device was discontinued. > >>> ... I was just burned by >>> Lattice announcing EOL of their XP line. This was because they got a >>> new guy in at the top with a new broom I suppose. >>> >> >> Not so cool :-( > > Yeah, I'm unhappy about it. I thought I could get more development > funds for a redo but the division reselling this board in their product > doesn't want to spend any cash on it. I've been asked to spend my dime > and I likely will. I make good money on this product. > Looks like a good business opportunity for you :-) > >>> I'm sure you can find various MCUs which have been in production for 10 >>> years, but I know Atmel likes to replace products from time to time with >>> similar "pin compatible" devices which are 99.9% compatible. I expect >>> for the 8 bit parts life span is not such an issue. For the larger >>> parts I expect life span is a bit more limited and for the top end >>> chips, I'm pretty sure their life span is measured in double digit >>> months. Can you still buy any of the Pentium 4s that were all over the >>> place seven or eight years ago? >> >> >> Yup: >> >> http://components.arrow.com/part/detail/41596500S6440784N2936?region=na >> >> >>> ... I can't even find a Core 2 Duo. >> >> >> No problem either: >> >> http://components.arrow.com/part/detail/42952225S9497728N2936?region=na > > How do you know these are the parts that were designed in the system of > interest? They made a huge number of variants and I know I have seen > EOL notices for Pentium 4s. > Well, you do have to look in the schematics. You only asked whether one can still buy Pentium 4 and I said yes, and gave evidence. Are you changing the game now? :-) Legacy stuff in the PC world does not go away fast. To this day you can still easily buy brand-new ISA-bus PCs. Because scores of them are used in production facilities. I helped replace one a few years ago and it also had a processor from the days of Methusaleh. > >>> What lifespan have you seen for MCUs? >>> >> >> The 89C51 I designed in in the mid-90's is still living. Not sure how >> long it was in production when I designed it in. The nice thing is that >> these are made by several companies, even Asian ones such as Winbond. So >> it was no surprise when I took apart our pellet stove for maintenance >> and found one of those in there as well. >> >> 2nd source is important to me, and my clients. > > If you really need that level of consistency, then you will be using > nothing but 8051s all your career. I don't know of any digital > component that has lived as long as the 8051 other than perhaps LS-TTL. > I also don't know of any other MCU that is second sourceds. If the > 8051 does what you need, then go for it. But again you are mixing > conversations. That's why it is so frustrating to have a conversation > with you. ... I merely said it matter in some cases. Not in all cases. > ... You talk about not being able to use a part unless it has a > product life as long as the 8051 and then you talk about using various > DSP chips in the same context. I *know* you won't be able to buy those > DSP chips 10 years from now. TI just doesn't provide that level of > support unless they have a special program for long lived parts I'm not > aware of. I've seen lightly selling DSPs drop from the marketplace > after less than 5 years. > Well, let me show you a blast from the past ... http://www.rocelec.com/search/finished/TMS320C10NL/0/1/contains/?utm_source=supplyFrame&utm_medium=buyNow 20,286 in stock, ready to ship. > The DSP market was just a tiny exploration by TI initially. Then they > saw cell phones as a way to utilize that capability. They actually > reorganized the entire company to take full advantage of it. As a > result they ended up with four segments for DSPs. > Analog Devices had the market first, they really ruled in the eearly 90's. We had boards with about a dozen 16-bit FP DSPs on there. > 1) Cell phone devices - small, low power and cheap in large quantities. > Not much need for longevity at all... basically the C5xxx line. > > 2) Cell base stations - powerful devices that can handle multiple > channels, power consumption not important and cost is secondary. This > is the C6xxx line. Again, they focus on new, not longevity. > > 3) Scientific DSP - floating point. C67xx lines. Relatively low > volumes compared to the other two, but they seem to think it is an > important market. New designs are not as frequent. Longevity might be > better than the other two, but no promises. > > 4) Motor control, white goods, etc - fixed point with price the major > factor. These have appeared in a range of variations, some with flash, > some with ADCs, etc. These are almost MCUs with simlar performance, > slow compared to segment 1 and 2. Intended for high volume apps, but > again, longevity is not important. > > So if you are going to consider DSPs for your apps, I expect you would > be looking at the last category. I'm pretty sure I wouldn't be > designing from this group if I wanted to be building this board 10 years > from now though. Have you talked to TI about longevity? > Not yet. That comes if I decide to have a DSP in a project. But mostly my clients have those discussions because that's their turf, I am more the analog guys. On large projects stuff gets put in writing about guaranteed years of supply. On some chips it goes as far as putting the mask data in escrow, especially with smaller companies where there is a chance of them going belly-up down the road. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-08 14:27 -0400 |
| Message-ID | <l0ifin$hfe$1@dont-email.me> |
| In reply to | #13382 |
On 9/8/2013 11:05 AM, Joerg wrote: > rickman wrote: >> On 9/7/2013 7:45 PM, Joerg wrote: >>> rickman 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. >>>> >>>> First, there are *no* second sources so whatever chip family you select >>>> is the only one that will fit your layout. ... >>> >>> >>> That is one of my concerns. With 8051 uCs you have multiple sources as >>> long as you stick to customary packages such as a 44-pin flat-pack. >> >> Yes, but 8051s aren't DSPs either are they? You seem to be switching >> gears again. I can't keep up. I know you do different designs, but can >> the FPGA be wrong for *all* of them? You seem to have all requirements >> for all designs. >> > > I do various designs, sometimes simultaneously. For DSP we often just > plop down a TMS320 bare-bones edition and be done with it. It's like > buying a Ford F-150 for the ranch, it may be too big but it is not > expensive and you almost can't go wrong with it. I had designs where the > DSP workload ended up at 5% but at $3 pop nobody was concerned. > > And no, mostly I don't even have the requirements until after the > project already started. Sometimes weeks down the road the sensor guys > call in, "Houston, we have a problem". This is the kind of project > companies like to use consultants for, since it can be utterly > frustrating for engineers. Us guys are use to this stuff. > >> >>>> ... There *may* be more than one >>>> member of that family that will fit the same socket, that is common, but >>>> not guaranteed. So you often will get a choice of two, three or four >>>> sizes and you often get an upgrade path from your first selection. Just >>>> in case you are familiar with the compilation process, in an FPGA you >>>> *always* have to recompile for the target. Even if they are pin >>>> compatible you can't load a design for an whatever-02 chip into a >>>> whatever-03 part. Those are the limitations. >>>> >>> >>> Yeah, that I was aware of. And changing to a whatever-03 would be a >>> major headache in many of my cases. Because it's medical, aerospace >>> similar where that can trigger a complete re-cert. >> >> Why would you need to change to the whatever-03. Once it is qualified >> you can stick with it. My point is that you have flexibility in the >> device, no one is making you switch. >> > > I was thinking about the case where whatever-02 becomes unobtanium. In the FPGA world, they don't obsolete individual devices although they do *very seldom* obsolete a package. They obsolete a family. So if whatever-02 become obsolete, so does whatever-03. Fortunately this is usually after a *very* long life and even then they usually make the parts available through one of the extended life makers. >>>> As to the market life, that it typically well over 10 years. Spartan 3 >>>> was introduced some 10 years ago and it is not yet the oldest chip >>>> Xilinx has in current full production. I'm still considering using it >>>> for new designs. Similar situation for Altera. ... >>> >>> >>> Well over 10 years is good. But only if that means no change to any new >>> versions that require a re-compile. Early on in my career that happened >>> and one guy promptly got busy with three months of regression testing. >>> Oh what fun. >> >> Why not talk to the vendors? >> > > We did that and all we got was a "Sorry about that". The designed-in > device was discontinued. > >> >>>> ... I was just burned by >>>> Lattice announcing EOL of their XP line. This was because they got a >>>> new guy in at the top with a new broom I suppose. >>>> >>> >>> Not so cool :-( >> >> Yeah, I'm unhappy about it. I thought I could get more development >> funds for a redo but the division reselling this board in their product >> doesn't want to spend any cash on it. I've been asked to spend my dime >> and I likely will. I make good money on this product. >> > > Looks like a good business opportunity for you :-) It's a better opportunity if I don't have to redesign it. I am ready to retire and this was bringing cash in with minimal effort. Very sporadic cash, but cash nonetheless. >>>> I'm sure you can find various MCUs which have been in production for 10 >>>> years, but I know Atmel likes to replace products from time to time with >>>> similar "pin compatible" devices which are 99.9% compatible. I expect >>>> for the 8 bit parts life span is not such an issue. For the larger >>>> parts I expect life span is a bit more limited and for the top end >>>> chips, I'm pretty sure their life span is measured in double digit >>>> months. Can you still buy any of the Pentium 4s that were all over the >>>> place seven or eight years ago? >>> >>> >>> Yup: >>> >>> http://components.arrow.com/part/detail/41596500S6440784N2936?region=na >>> >>> >>>> ... I can't even find a Core 2 Duo. >>> >>> >>> No problem either: >>> >>> http://components.arrow.com/part/detail/42952225S9497728N2936?region=na >> >> How do you know these are the parts that were designed in the system of >> interest? They made a huge number of variants and I know I have seen >> EOL notices for Pentium 4s. >> > > Well, you do have to look in the schematics. You only asked whether one > can still buy Pentium 4 and I said yes, and gave evidence. Are you > changing the game now? :-) > > Legacy stuff in the PC world does not go away fast. To this day you can > still easily buy brand-new ISA-bus PCs. Because scores of them are used > in production facilities. I helped replace one a few years ago and it > also had a processor from the days of Methusaleh. I wasn't aware that conventional PCs were used in industry that much. >>>> What lifespan have you seen for MCUs? >>>> >>> >>> The 89C51 I designed in in the mid-90's is still living. Not sure how >>> long it was in production when I designed it in. The nice thing is that >>> these are made by several companies, even Asian ones such as Winbond. So >>> it was no surprise when I took apart our pellet stove for maintenance >>> and found one of those in there as well. >>> >>> 2nd source is important to me, and my clients. >> >> If you really need that level of consistency, then you will be using >> nothing but 8051s all your career. I don't know of any digital >> component that has lived as long as the 8051 other than perhaps LS-TTL. >> I also don't know of any other MCU that is second sourceds. If the >> 8051 does what you need, then go for it. But again you are mixing >> conversations. That's why it is so frustrating to have a conversation >> with you. ... > > > I merely said it matter in some cases. Not in all cases. > > >> ... You talk about not being able to use a part unless it has a >> product life as long as the 8051 and then you talk about using various >> DSP chips in the same context. I *know* you won't be able to buy those >> DSP chips 10 years from now. TI just doesn't provide that level of >> support unless they have a special program for long lived parts I'm not >> aware of. I've seen lightly selling DSPs drop from the marketplace >> after less than 5 years. >> > > Well, let me show you a blast from the past ... > > http://www.rocelec.com/search/finished/TMS320C10NL/0/1/contains/?utm_source=supplyFrame&utm_medium=buyNow > > 20,286 in stock, ready to ship. > > >> The DSP market was just a tiny exploration by TI initially. Then they >> saw cell phones as a way to utilize that capability. They actually >> reorganized the entire company to take full advantage of it. As a >> result they ended up with four segments for DSPs. >> > > Analog Devices had the market first, they really ruled in the eearly > 90's. We had boards with about a dozen 16-bit FP DSPs on there. 90's??? TI came out with their DSP in the early 80's by my memory. They then captured the cell market. The FP DSPs were not the bread and butter of DSP. Without the cell market DSPs would likely still be rather a niche. >> 1) Cell phone devices - small, low power and cheap in large quantities. >> Not much need for longevity at all... basically the C5xxx line. >> >> 2) Cell base stations - powerful devices that can handle multiple >> channels, power consumption not important and cost is secondary. This >> is the C6xxx line. Again, they focus on new, not longevity. >> >> 3) Scientific DSP - floating point. C67xx lines. Relatively low >> volumes compared to the other two, but they seem to think it is an >> important market. New designs are not as frequent. Longevity might be >> better than the other two, but no promises. >> >> 4) Motor control, white goods, etc - fixed point with price the major >> factor. These have appeared in a range of variations, some with flash, >> some with ADCs, etc. These are almost MCUs with simlar performance, >> slow compared to segment 1 and 2. Intended for high volume apps, but >> again, longevity is not important. >> >> So if you are going to consider DSPs for your apps, I expect you would >> be looking at the last category. I'm pretty sure I wouldn't be >> designing from this group if I wanted to be building this board 10 years >> from now though. Have you talked to TI about longevity? >> > > Not yet. That comes if I decide to have a DSP in a project. But mostly > my clients have those discussions because that's their turf, I am more > the analog guys. On large projects stuff gets put in writing about > guaranteed years of supply. On some chips it goes as far as putting the > mask data in escrow, especially with smaller companies where there is a > chance of them going belly-up down the road. I only wish I could do that, but making chips from masks can be an expensive proposition if the fab is being shut down. It would seem that is what is behind the end of the XP series from Lattice. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-08 12:56 -0700 |
| Message-ID | <b94331Fkm6gU1@mid.individual.net> |
| In reply to | #13393 |
rickman wrote: > On 9/8/2013 11:05 AM, Joerg wrote: >> rickman wrote: >>> On 9/7/2013 7:45 PM, Joerg wrote: >>>> rickman wrote: [...] >>>>> ... There *may* be more >>>>> than one >>>>> member of that family that will fit the same socket, that is >>>>> common, but >>>>> not guaranteed. So you often will get a choice of two, three or four >>>>> sizes and you often get an upgrade path from your first selection. >>>>> Just >>>>> in case you are familiar with the compilation process, in an FPGA you >>>>> *always* have to recompile for the target. Even if they are pin >>>>> compatible you can't load a design for an whatever-02 chip into a >>>>> whatever-03 part. Those are the limitations. >>>>> >>>> >>>> Yeah, that I was aware of. And changing to a whatever-03 would be a >>>> major headache in many of my cases. Because it's medical, aerospace >>>> similar where that can trigger a complete re-cert. >>> >>> Why would you need to change to the whatever-03. Once it is qualified >>> you can stick with it. My point is that you have flexibility in the >>> device, no one is making you switch. >>> >> >> I was thinking about the case where whatever-02 becomes unobtanium. > > In the FPGA world, they don't obsolete individual devices although they > do *very seldom* obsolete a package. They obsolete a family. So if > whatever-02 become obsolete, so does whatever-03. Fortunately this is > usually after a *very* long life and even then they usually make the > parts available through one of the extended life makers. > It would be good to know which manufacturers have the best reputation regarding longevity. I've seen a few cases where programmable logic was discontinued and that has caused a lot of grief. But I do not remember the brands because it wasn't really my turf. Often longevity is way more important than performance. [...] >> >> We did that and all we got was a "Sorry about that". The designed-in >> device was discontinued. >> >>> >>>>> ... I was just burned by >>>>> Lattice announcing EOL of their XP line. This was because they got a >>>>> new guy in at the top with a new broom I suppose. >>>>> >>>> >>>> Not so cool :-( >>> >>> Yeah, I'm unhappy about it. I thought I could get more development >>> funds for a redo but the division reselling this board in their product >>> doesn't want to spend any cash on it. I've been asked to spend my dime >>> and I likely will. I make good money on this product. >>> >> >> Looks like a good business opportunity for you :-) > > It's a better opportunity if I don't have to redesign it. I am ready to > retire ... Lucky you. It's still some time away for me and I'll probably never fully retire, electronics design is fun. But I already talked with a neighbor about making beer together once I slow down the EE design work a bit. He is retired and I used to brew when I was at the university. > ... and this was bringing cash in with minimal effort. Very sporadic > cash, but cash nonetheless. > If the grand total per year is worth it, why not? > >>>>> I'm sure you can find various MCUs which have been in production >>>>> for 10 >>>>> years, but I know Atmel likes to replace products from time to time >>>>> with >>>>> similar "pin compatible" devices which are 99.9% compatible. I expect >>>>> for the 8 bit parts life span is not such an issue. For the larger >>>>> parts I expect life span is a bit more limited and for the top end >>>>> chips, I'm pretty sure their life span is measured in double digit >>>>> months. Can you still buy any of the Pentium 4s that were all over >>>>> the >>>>> place seven or eight years ago? >>>> >>>> >>>> Yup: >>>> >>>> http://components.arrow.com/part/detail/41596500S6440784N2936?region=na >>>> >>>> >>>>> ... I can't even find a Core 2 Duo. >>>> >>>> >>>> No problem either: >>>> >>>> http://components.arrow.com/part/detail/42952225S9497728N2936?region=na >>> >>> How do you know these are the parts that were designed in the system of >>> interest? They made a huge number of variants and I know I have seen >>> EOL notices for Pentium 4s. >>> >> >> Well, you do have to look in the schematics. You only asked whether one >> can still buy Pentium 4 and I said yes, and gave evidence. Are you >> changing the game now? :-) >> >> Legacy stuff in the PC world does not go away fast. To this day you can >> still easily buy brand-new ISA-bus PCs. Because scores of them are used >> in production facilities. I helped replace one a few years ago and it >> also had a processor from the days of Methusaleh. > > I wasn't aware that conventional PCs were used in industry that much. > Oh yeah, it's all PCs there. Even the CNC stuff ultimately gets controlled by someone on a PC. Lots of legacy devices because production machines remain in service for decades. At church they just switched to Apple. <sigh> So today when I looked at the song projector software I couldn't make heads or tails of it. That'll take a learning curve. [...] >> >>> The DSP market was just a tiny exploration by TI initially. Then they >>> saw cell phones as a way to utilize that capability. They actually >>> reorganized the entire company to take full advantage of it. As a >>> result they ended up with four segments for DSPs. >>> >> >> Analog Devices had the market first, they really ruled in the eearly >> 90's. We had boards with about a dozen 16-bit FP DSPs on there. > > 90's??? TI came out with their DSP in the early 80's by my memory. They > then captured the cell market. The FP DSPs were not the bread and > butter of DSP. Without the cell market DSPs would likely still be > rather a niche. > It was actually 1990. Analog Devices had the medical devices market pretty much covered AFAICT and our product was medical. IIRC it was the ADSP-2105 and you can still buy them today. Except now they want over $20 a piece. Highway robbery :-) [...] >>> 4) Motor control, white goods, etc - fixed point with price the major >>> factor. These have appeared in a range of variations, some with flash, >>> some with ADCs, etc. These are almost MCUs with simlar performance, >>> slow compared to segment 1 and 2. Intended for high volume apps, but >>> again, longevity is not important. >>> >>> So if you are going to consider DSPs for your apps, I expect you would >>> be looking at the last category. I'm pretty sure I wouldn't be >>> designing from this group if I wanted to be building this board 10 years >>> from now though. Have you talked to TI about longevity? >>> >> >> Not yet. That comes if I decide to have a DSP in a project. But mostly >> my clients have those discussions because that's their turf, I am more >> the analog guys. On large projects stuff gets put in writing about >> guaranteed years of supply. On some chips it goes as far as putting the >> mask data in escrow, especially with smaller companies where there is a >> chance of them going belly-up down the road. > > I only wish I could do that, but making chips from masks can be an > expensive proposition if the fab is being shut down. It would seem that > is what is behind the end of the XP series from Lattice. > It is a hassle if the whole process is discontinued. But there are IC houses that cater to this market. They'll take the old design and migrate it onto a newer process. However, that only works if you have one of those escrow deals. The important thing is to make the original design not depend on the sluggishness of contemporary ICs because on a new process you might get the same IC functionality but on steroids. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-09-10 23:07 -0400 |
| Message-ID | <l0omlv$oik$1@dont-email.me> |
| In reply to | #13395 |
On 9/8/2013 3:56 PM, Joerg wrote: > > It would be good to know which manufacturers have the best reputation > regarding longevity. I've seen a few cases where programmable logic was > discontinued and that has caused a lot of grief. But I do not remember > the brands because it wasn't really my turf. > > Often longevity is way more important than performance. You can't measure longevity and past performance is no assurance of future success. Performance is actually binary, good enough or not. >> It's a better opportunity if I don't have to redesign it. I am ready to >> retire ... > > > Lucky you. It's still some time away for me and I'll probably never > fully retire, electronics design is fun. But I already talked with a > neighbor about making beer together once I slow down the EE design work > a bit. He is retired and I used to brew when I was at the university. I kayak. At least some. Dodgy hip is impacting me these days. Once the ACA is fully in force I'll be able to get insurance to pay for a new one. I had insurance through my company until my colleague left, then it was 1 employee and didn't qualify for the group plan anymore... just before I was going to get it done. >> ... and this was bringing cash in with minimal effort. Very sporadic >> cash, but cash nonetheless. >> > > If the grand total per year is worth it, why not? Marginal given the hassle of keeping a company going, tracking expenses, taxes, state registration BS. Then there is the "vacation" issue. If I get an order, I have to be on it. Hard to take a vacation if you don't know when orders are expected... or maybe that should be "order". But I shouldn't complain. I had enough surprise business this year to retire. I guess it is a comfort level issue of cutting off any future cash flow. >> 90's??? TI came out with their DSP in the early 80's by my memory. They >> then captured the cell market. The FP DSPs were not the bread and >> butter of DSP. Without the cell market DSPs would likely still be >> rather a niche. >> > > It was actually 1990. Analog Devices had the medical devices market > pretty much covered AFAICT and our product was medical. IIRC it was the > ADSP-2105 and you can still buy them today. Except now they want over > $20 a piece. Highway robbery :-) According to wikipedia, TI had DSPs out in the early 80's which jibes with what I recall. TI was the first with a successful product so they got the market share early on. Once they had an established code base in a given industry they continued to hold their lead. I can't say who is dominant in what industry, but I know TI was rather dominant in the cell industry which was the cash cow. > It is a hassle if the whole process is discontinued. But there are IC > houses that cater to this market. They'll take the old design and > migrate it onto a newer process. However, that only works if you have > one of those escrow deals. The important thing is to make the original > design not depend on the sluggishness of contemporary ICs because on a > new process you might get the same IC functionality but on steroids. Yes, but usually they do it in cooperation with the original vendor. I assume there is a lot more to making a chip than the mask sets. The fab process has many variables, plus there is the issue of testing and packaging. You would think packaging would be pretty routine, but the FPGA makers treat a chip in a different package almost as if it were a different chip. I guess for some uses the difference in parasitics have significant impact on noise immunity and SI issues. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-09-11 10:05 +0100 |
| Message-ID | <TnWXt.36057$2y.670@fx23.am4> |
| In reply to | #13449 |
On 11/09/13 04:07, rickman wrote: > I assume there is a lot more to making a chip > than the mask sets. The fab process has many > variables, plus there is the issue of testing and > packaging. You would think packaging would be > pretty routine, but the FPGA makers treat a chip > in a different package almost as if it were a > different chip. I guess for some uses the > difference in parasitics have significant impact > on noise immunity and SI issues. No need to guess. The "external" parasitic inductance and capacitance and drive levels are discussed in *many* app notes :) The have spawned industry standards for specification and modelling. See <http://en.wikipedia.org/wiki/Input/output_Buffer_Information_Specification> The "internal" parasitics are the reason you will never see open source implementations of the mapping, place and route and timing verification tools: the info is too proprietary and commercially sensitive.
[toc] | [prev] | [next] | [standalone]
| From | Joerg <invalid@invalid.invalid> |
|---|---|
| Date | 2013-09-11 07:49 -0700 |
| Message-ID | <b9be8tF6561U1@mid.individual.net> |
| In reply to | #13449 |
rickman wrote: > On 9/8/2013 3:56 PM, Joerg wrote: >> >> It would be good to know which manufacturers have the best reputation >> regarding longevity. I've seen a few cases where programmable logic was >> discontinued and that has caused a lot of grief. But I do not remember >> the brands because it wasn't really my turf. >> >> Often longevity is way more important than performance. > > You can't measure longevity and past performance is no assurance of > future success. > Nope. Longevity is measure by years in production without the need for re-design or ECOs. > Performance is actually binary, good enough or not. > Not really. With some parts you can do more things, with some less. Just like with cars, some will haul a 2-ton trailer and some can barely do it or not at all. > >>> It's a better opportunity if I don't have to redesign it. I am ready to >>> retire ... >> >> >> Lucky you. It's still some time away for me and I'll probably never >> fully retire, electronics design is fun. But I already talked with a >> neighbor about making beer together once I slow down the EE design work >> a bit. He is retired and I used to brew when I was at the university. > > I kayak. At least some. Dodgy hip is impacting me these days. Once > the ACA is fully in force I'll be able to get insurance to pay for a new > one. I had insurance through my company until my colleague left, then > it was 1 employee and didn't qualify for the group plan anymore... just > before I was going to get it done. > Hopefully Obamacare will not cause them to deny or put you on a waiting list because it's not "bad enough". For us, it looks like we'll be looking at a price increase in premiums north of 50%. Ouch, ouch. Age discrimination in those "plans" seems to be worse than what we have now. Some folks are mulling about semi-retirement so they drop under the magic $62k or whatever family limit. Above that, according to the exchange calculator subsidies almost digitally stop, meaning that earning $1k more can "earn" you $5k in penalty. What a stupid law. > >>> ... and this was bringing cash in with minimal effort. Very sporadic >>> cash, but cash nonetheless. >>> >> >> If the grand total per year is worth it, why not? > > Marginal given the hassle of keeping a company going, tracking expenses, > taxes, state registration BS. Then there is the "vacation" issue. If I > get an order, I have to be on it. Hard to take a vacation if you don't > know when orders are expected... or maybe that should be "order". But I > shouldn't complain. I had enough surprise business this year to retire. > I guess it is a comfort level issue of cutting off any future cash flow. > Well, we are in America, where one does not let a good deal slip :-) Just send a notice to your clients ahead of time, "Will be kayaking from San Francisco to Tokyo the 1st half of 2014. If you need help send a speedboat or call in July" :-) > >>> 90's??? TI came out with their DSP in the early 80's by my memory. They >>> then captured the cell market. The FP DSPs were not the bread and >>> butter of DSP. Without the cell market DSPs would likely still be >>> rather a niche. >>> >> >> It was actually 1990. Analog Devices had the medical devices market >> pretty much covered AFAICT and our product was medical. IIRC it was the >> ADSP-2105 and you can still buy them today. Except now they want over >> $20 a piece. Highway robbery :-) > > According to wikipedia, TI had DSPs out in the early 80's which jibes > with what I recall. TI was the first with a successful product so they > got the market share early on. Once they had an established code base > in a given industry they continued to hold their lead. I can't say who > is dominant in what industry, but I know TI was rather dominant in the > cell industry which was the cash cow. > Cell phones are short-lived products. One year, if that. Med/aero is a whole different set of metrics. We need to rely on parts still being there 10, 20 or more years doen the road. > >> It is a hassle if the whole process is discontinued. But there are IC >> houses that cater to this market. They'll take the old design and >> migrate it onto a newer process. However, that only works if you have >> one of those escrow deals. The important thing is to make the original >> design not depend on the sluggishness of contemporary ICs because on a >> new process you might get the same IC functionality but on steroids. > > Yes, but usually they do it in cooperation with the original vendor. ... Not if it has gone belly-up. That is usually the main reason for escrow. > ... I > assume there is a lot more to making a chip than the mask sets. The fab > process has many variables, plus there is the issue of testing and > packaging. You would think packaging would be pretty routine, but the > FPGA makers treat a chip in a different package almost as if it were a > different chip. I guess for some uses the difference in parasitics have > significant impact on noise immunity and SI issues. > Those are not really major factors. The process will cause differences but if you have a good IC engineer running the salvage project one can make it work. I have witnessed process migrations (old process was being discontinued) with our own chip design, it wasn't a major chore. Packaging was never an issue, but then again some of ours are bare die that then get flip-chip bonded. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2013-09-11 16:54 +0100 |
| Message-ID | <MPG.2c9aa28779fcf69b98977c@172.16.0.1> |
| In reply to | #13461 |
In article <b9be8tF6561U1@mid.individual.net>, invalid@invalid.invalid says... > > rickman wrote: > > On 9/8/2013 3:56 PM, Joerg wrote: > > According to wikipedia, TI had DSPs out in the early 80's which jibes > > with what I recall. TI was the first with a successful product so they > > got the market share early on. Once they had an established code base > > in a given industry they continued to hold their lead. I can't say who > > is dominant in what industry, but I know TI was rather dominant in the > > cell industry which was the cash cow. > > > > Cell phones are short-lived products. One year, if that. Med/aero is a > whole different set of metrics. We need to rely on parts still being > there 10, 20 or more years doen the road. Around 2002 to 2004 I had an enquiry to look at improving an NMR system at a hospital. When I asked them what the age of the machine was they said - "The earliest record we have is when it MOVED to the new building in 1968" -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
[toc] | [prev] | [next] | [standalone]
| From | "Tim Williams" <tmoranwms@charter.net> |
|---|---|
| Date | 2013-09-11 11:25 -0500 |
| Message-ID | <l0q5gj$us5$2@dont-email.me> |
| In reply to | #13463 |
"Paul" <paul@pcserviceselectronics.co.uk> wrote in message news:MPG.2c9aa28779fcf69b98977c@172.16.0.1... > Around 2002 to 2004 I had an enquiry to look at improving an NMR system > at a hospital. When I asked them what the age of the machine was they > said - > > "The earliest record we have is when it MOVED to the new building > in 1968" Geez, was it a frequency-sweep unit? LOL Tim -- Deep Friar: a very philosophical monk. Website: http://seventransistorlabs.com
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web