Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #447672 > unrolled thread
| Started by | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| First post | 2017-02-14 14:47 -0800 |
| Last post | 2017-02-17 11:06 -0800 |
| Articles | 20 on this page of 89 — 21 participants |
Back to article view | Back to sci.electronics.design
analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-14 14:47 -0800
Re: analog failures Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-14 15:05 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-15 10:52 +0800
Re: analog failures bill.sloman@ieee.org - 2017-02-14 19:00 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-15 11:55 +0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-15 07:53 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-15 08:30 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-15 10:19 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-15 10:53 -0800
Re: analog failures Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-15 10:58 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-15 21:25 -0600
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-15 20:18 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 15:44 -0500
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 15:30 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 14:05 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 17:16 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 14:38 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 17:58 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 15:37 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 18:51 -0500
Re: analog failures krw@notreal.com - 2017-02-17 20:27 -0500
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-17 17:56 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-17 21:03 -0600
Re: analog failures krw@notreal.com - 2017-02-17 22:36 -0500
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-19 00:45 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-19 08:32 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-21 12:31 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-23 14:57 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-23 12:02 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-17 17:27 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 20:39 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 07:41 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-18 08:04 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 08:16 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-16 06:49 +0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-16 07:14 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-16 07:24 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-16 07:41 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-17 13:22 +0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 06:58 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-17 12:26 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 14:03 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-17 21:05 -0600
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-18 08:07 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 08:20 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-18 09:20 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-19 00:48 -0500
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-21 12:39 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-21 22:54 -0600
Re: analog failures krw@notreal.com - 2017-02-17 20:33 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 07:37 -0800
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-22 15:45 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-23 10:43 -0800
Re: analog failures krw@notreal.com - 2017-02-23 20:42 -0500
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-24 03:31 -0600
Re: analog failures grahamholloway@graham65.plus.com - 2017-02-24 06:39 -0800
Re: analog failures Don Kuenz <g@crcomp.net> - 2017-02-24 14:58 +0000
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-25 12:48 -0800
Re: analog failures pcdhobbs@gmail.com - 2017-02-26 04:39 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-26 07:52 -0800
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-24 09:02 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-25 12:44 -0800
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-26 08:29 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-26 09:46 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-26 10:11 -0800
Re: analog failures krw@notreal.com - 2017-02-26 17:55 -0500
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-26 15:09 -0800
Re: analog failures krw@notreal.com - 2017-02-26 19:30 -0500
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-27 10:37 -0800
Re: analog failures Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-24 09:14 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-25 12:46 -0800
Re: analog failures Klaus Kragelund <klauskvik@hotmail.com> - 2017-02-26 17:44 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-27 07:51 -0800
Re: analog failures Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-02-23 21:36 +0200
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-24 08:38 -0800
Re: analog failures krw@notreal.com - 2017-02-24 20:20 -0500
Re: analog failures kevin93 <kevin@whitedigs.com> - 2017-02-24 17:36 -0800
Re: analog failures Ralph Barone <ralph@invalid.com> - 2017-02-15 03:25 +0000
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-14 19:20 -0800
Re: analog failures Tim Wescott <seemywebsite@myfooter.really> - 2017-02-14 17:46 -0600
Re: analog failures Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> - 2017-02-14 17:50 -0700
Re: analog failures Tim Wescott <tim@seemywebsite.com> - 2017-02-14 23:49 -0600
Re: analog failures Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> - 2017-02-15 07:03 -0700
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-15 10:18 -0800
Re: analog failures Tim Wescott <seemywebsite@myfooter.really> - 2017-02-15 15:06 -0600
Re: analog failures legg <legg@nospam.magma.ca> - 2017-02-16 23:06 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 07:00 -0800
Re: analog failures legg <legg@nospam.magma.ca> - 2017-02-17 13:22 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 11:06 -0800
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| Date | 2017-02-14 14:47 -0800 |
| Subject | analog failures |
| Message-ID | <l427ac10g0imragijl13gmrvjr6jcslo6v@4ax.com> |
http://semiengineering.com/devices-threatened-by-analog-content/ My experience is that we find a lot of bugs and documentation problems with the digital parts of mixed-signal chips. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
[toc] | [next] | [standalone]
| From | Lasse Langwadt Christensen <langwadt@fonz.dk> |
|---|---|
| Date | 2017-02-14 15:05 -0800 |
| Message-ID | <26ca0bd7-436a-408b-8084-792032accf3a@googlegroups.com> |
| In reply to | #447672 |
Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: > http://semiengineering.com/devices-threatened-by-analog-content/ > > My experience is that we find a lot of bugs and documentation problems > with the digital parts of mixed-signal chips. It does seem like when analog designers get to design the digital parts of a chip it often ends up with a hairball of hazards and weird quirks
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-02-15 10:52 +0800 |
| Message-ID | <o80flk$of4$1@dont-email.me> |
| In reply to | #447675 |
AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: > Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >> http://semiengineering.com/devices-threatened-by-analog-content/ >> >> My experience is that we find a lot of bugs and documentation problems >> with the digital parts of mixed-signal chips. > > It does seem like when analog designers get to design the digital parts > of a chip it often ends up with a hairball of hazards and weird quirks That was always my experience with part from NatSemi. Pure analog was good, pure digital was good, mixed mostly was a mess. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | bill.sloman@ieee.org |
|---|---|
| Date | 2017-02-14 19:00 -0800 |
| Message-ID | <3b85856b-fb02-4edb-9223-878c9efbf7ac@googlegroups.com> |
| In reply to | #447694 |
On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm wrote: > AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: > > > Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: > >> http://semiengineering.com/devices-threatened-by-analog-content/ > >> > >> My experience is that we find a lot of bugs and documentation problems > >> with the digital parts of mixed-signal chips. > > > > It does seem like when analog designers get to design the digital parts > > of a chip it often ends up with a hairball of hazards and weird quirks > > That was always my experience with part from NatSemi. Pure analog was good, > pure digital was good, mixed mostly was a mess. Mixed signal design is difficult, and doing it on a chip, where it is harder to keep the noisy digital bits away from the sensitive analog bits, wouldn't have made it any easier. Sadly, mixed signal design can do a lot more than pure analog or pure digital, so if you have got something complicated to do, that tends to be what you end up doing. -- Bill Sloman, Sydney
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-02-15 11:55 +0800 |
| Message-ID | <o80jd1$set$1@dont-email.me> |
| In reply to | #447695 |
AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: > On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm > wrote: >> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >> >> > Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >> >> http://semiengineering.com/devices-threatened-by-analog-content/ >> >> >> >> My experience is that we find a lot of bugs and documentation problems >> >> with the digital parts of mixed-signal chips. >> > >> > It does seem like when analog designers get to design the digital parts >> > of a chip it often ends up with a hairball of hazards and weird quirks >> >> That was always my experience with part from NatSemi. Pure analog was >> good, pure digital was good, mixed mostly was a mess. > > Mixed signal design is difficult, and doing it on a chip, where it is > harder to keep the noisy digital bits away from the sensitive analog bits, > wouldn't have made it any easier. > > Sadly, mixed signal design can do a lot more than pure analog or pure > digital, so if you have got something complicated to do, that tends to be > what you end up doing. It was never the problem of digital noise coupling into the analog portions but the digital totally mixed up, like the LM75 going into a state where only a power cycle helps to get it working again. This can be caused by noise on the I2C signals. I had the same with a part from Microchip. It has a config bit to automatically reset its I2C interface after a timeout period without any activity on the bus. This bit is reset after power on. So if the interface goes gaga because of a poor POR you never get it working. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-15 07:53 -0800 |
| Message-ID | <egjbr9F7dhiU1@mid.individual.net> |
| In reply to | #447707 |
On 2017-02-14 19:55, Reinhardt Behm wrote: > AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: > >> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >> wrote: >>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>> >>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>> IME most analog failures are caused by ESD and that is often squarely in the court of the board level designer. Upsets without subsequent chip damage are also considered a fault where the function is mission-critical. That is very often due to EMI. >>>>> My experience is that we find a lot of bugs and documentation problems >>>>> with the digital parts of mixed-signal chips. >>>> >>>> It does seem like when analog designers get to design the digital parts >>>> of a chip it often ends up with a hairball of hazards and weird quirks >>> >>> That was always my experience with part from NatSemi. Pure analog was >>> good, pure digital was good, mixed mostly was a mess. >> >> Mixed signal design is difficult, and doing it on a chip, where it is >> harder to keep the noisy digital bits away from the sensitive analog bits, >> wouldn't have made it any easier. >> >> Sadly, mixed signal design can do a lot more than pure analog or pure >> digital, so if you have got something complicated to do, that tends to be >> what you end up doing. > > It was never the problem of digital noise coupling into the analog portions > but the digital totally mixed up, like the LM75 going into a state where > only a power cycle helps to get it working again. This can be caused by > noise on the I2C signals. I2C is a bus I try not to use if it can be avoided because of various hang-ups. SPI is much more robust IME and, therefore, that is what I prefer. > I had the same with a part from Microchip. It has a config bit to > automatically reset its I2C interface after a timeout period without any > activity on the bus. This bit is reset after power on. So if the interface > goes gaga because of a poor POR you never get it working. > Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. However, a poor POR is something the circuit designer should take care of. Never trust any on-chip POR/BOR. Ever. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-02-15 08:30 -0800 |
| Message-ID | <s609acdk8jegfeslhbhnl9dmpf11u6se21@4ax.com> |
| In reply to | #447744 |
On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> wrote: >On 2017-02-14 19:55, Reinhardt Behm wrote: >> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >> >>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>> wrote: >>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>>> >>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>> > >IME most analog failures are caused by ESD and that is often squarely in >the court of the board level designer. > >Upsets without subsequent chip damage are also considered a fault where >the function is mission-critical. That is very often due to EMI. > > >>>>>> My experience is that we find a lot of bugs and documentation problems >>>>>> with the digital parts of mixed-signal chips. >>>>> >>>>> It does seem like when analog designers get to design the digital parts >>>>> of a chip it often ends up with a hairball of hazards and weird quirks >>>> >>>> That was always my experience with part from NatSemi. Pure analog was >>>> good, pure digital was good, mixed mostly was a mess. >>> >>> Mixed signal design is difficult, and doing it on a chip, where it is >>> harder to keep the noisy digital bits away from the sensitive analog bits, >>> wouldn't have made it any easier. >>> >>> Sadly, mixed signal design can do a lot more than pure analog or pure >>> digital, so if you have got something complicated to do, that tends to be >>> what you end up doing. >> >> It was never the problem of digital noise coupling into the analog portions >> but the digital totally mixed up, like the LM75 going into a state where >> only a power cycle helps to get it working again. This can be caused by >> noise on the I2C signals. > > >I2C is a bus I try not to use if it can be avoided because of various >hang-ups. SPI is much more robust IME and, therefore, that is what I prefer. I prefer SPI too, and it's faster, but lots of people design terrible SPI interfaces, bad logic design and bad clock/data circuits. Every SPI should have schmitt inputs and safe timing margins. Maybe cooking a digital design into an analog process causes compromises, but I suspect it's just sloppy engineering. > > >> I had the same with a part from Microchip. It has a config bit to >> automatically reset its I2C interface after a timeout period without any >> activity on the bus. This bit is reset after power on. So if the interface >> goes gaga because of a poor POR you never get it working. >> > >Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >However, a poor POR is something the circuit designer should take care >of. Never trust any on-chip POR/BOR. Ever. The little NXP ARM chips, LPC1768 and such, seem to do POR right. All the FPGAs that we have used lately, ditto. You can connect one of those ARMs, or an FPGA, to a serial flash chip and have the whole thing boot up reliably. -- John Larkin Highland Technology, Inc lunatic fringe electronics
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-15 10:19 -0800 |
| Message-ID | <egjkdaF96lpU1@mid.individual.net> |
| In reply to | #447746 |
On 2017-02-15 08:30, John Larkin wrote: > On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> > wrote: > >> On 2017-02-14 19:55, Reinhardt Behm wrote: >>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>> >>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>> wrote: >>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>>>> >>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>> >> >> IME most analog failures are caused by ESD and that is often squarely in >> the court of the board level designer. >> >> Upsets without subsequent chip damage are also considered a fault where >> the function is mission-critical. That is very often due to EMI. >> >> >>>>>>> My experience is that we find a lot of bugs and documentation problems >>>>>>> with the digital parts of mixed-signal chips. >>>>>> >>>>>> It does seem like when analog designers get to design the digital parts >>>>>> of a chip it often ends up with a hairball of hazards and weird quirks >>>>> >>>>> That was always my experience with part from NatSemi. Pure analog was >>>>> good, pure digital was good, mixed mostly was a mess. >>>> >>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>> harder to keep the noisy digital bits away from the sensitive analog bits, >>>> wouldn't have made it any easier. >>>> >>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>> digital, so if you have got something complicated to do, that tends to be >>>> what you end up doing. >>> >>> It was never the problem of digital noise coupling into the analog portions >>> but the digital totally mixed up, like the LM75 going into a state where >>> only a power cycle helps to get it working again. This can be caused by >>> noise on the I2C signals. >> >> >> I2C is a bus I try not to use if it can be avoided because of various >> hang-ups. SPI is much more robust IME and, therefore, that is what I prefer. > > I prefer SPI too, and it's faster, but lots of people design terrible > SPI interfaces, bad logic design and bad clock/data circuits. Every > SPI should have schmitt inputs and safe timing margins. Maybe cooking > a digital design into an analog process causes compromises, but I > suspect it's just sloppy engineering. > >> >> >>> I had the same with a part from Microchip. It has a config bit to >>> automatically reset its I2C interface after a timeout period without any >>> activity on the bus. This bit is reset after power on. So if the interface >>> goes gaga because of a poor POR you never get it working. >>> >> >> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >> However, a poor POR is something the circuit designer should take care >> of. Never trust any on-chip POR/BOR. Ever. > > The little NXP ARM chips, LPC1768 and such, seem to do POR right. > Even they seem to have their oops moments. http://www.nxp.com/documents/user_manual/UM10430.pdf Quote page 9: "POR reset value of the event router STATUS register corrected" http://www.nxp.com/documents/errata_sheet/ES_LPC176X.pdf Quote page 18: "Problem: The USB host controller will hang indefinitely if it sees a dribble bit on the USB bus. It will hang the first time a dribble bit is seen. Once it is in this state there is no recovery other than a hard chip reset. This problem has no effect on the USB device controller. Work-around: None." End quote > All the FPGAs that we have used lately, ditto. > > You can connect one of those ARMs, or an FPGA, to a serial flash chip > and have the whole thing boot up reliably. > If you use certain FPGA you'd first have to call the people at your energy provider that you are about to turn it on :-) -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| Date | 2017-02-15 10:53 -0800 |
| Message-ID | <ti89ac5vffhmu7jmrulvq4vq5091baefa9@4ax.com> |
| In reply to | #447765 |
On Wed, 15 Feb 2017 10:19:27 -0800, Joerg <news@analogconsultants.com> wrote: >On 2017-02-15 08:30, John Larkin wrote: >> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >> wrote: >> >>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>> >>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>> wrote: >>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>>>>> >>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>> >>> >>> IME most analog failures are caused by ESD and that is often squarely in >>> the court of the board level designer. >>> >>> Upsets without subsequent chip damage are also considered a fault where >>> the function is mission-critical. That is very often due to EMI. >>> >>> >>>>>>>> My experience is that we find a lot of bugs and documentation problems >>>>>>>> with the digital parts of mixed-signal chips. >>>>>>> >>>>>>> It does seem like when analog designers get to design the digital parts >>>>>>> of a chip it often ends up with a hairball of hazards and weird quirks >>>>>> >>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>> good, pure digital was good, mixed mostly was a mess. >>>>> >>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>> harder to keep the noisy digital bits away from the sensitive analog bits, >>>>> wouldn't have made it any easier. >>>>> >>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>> digital, so if you have got something complicated to do, that tends to be >>>>> what you end up doing. >>>> >>>> It was never the problem of digital noise coupling into the analog portions >>>> but the digital totally mixed up, like the LM75 going into a state where >>>> only a power cycle helps to get it working again. This can be caused by >>>> noise on the I2C signals. >>> >>> >>> I2C is a bus I try not to use if it can be avoided because of various >>> hang-ups. SPI is much more robust IME and, therefore, that is what I prefer. >> >> I prefer SPI too, and it's faster, but lots of people design terrible >> SPI interfaces, bad logic design and bad clock/data circuits. Every >> SPI should have schmitt inputs and safe timing margins. Maybe cooking >> a digital design into an analog process causes compromises, but I >> suspect it's just sloppy engineering. >> >>> >>> >>>> I had the same with a part from Microchip. It has a config bit to >>>> automatically reset its I2C interface after a timeout period without any >>>> activity on the bus. This bit is reset after power on. So if the interface >>>> goes gaga because of a poor POR you never get it working. >>>> >>> >>> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >>> However, a poor POR is something the circuit designer should take care >>> of. Never trust any on-chip POR/BOR. Ever. >> >> The little NXP ARM chips, LPC1768 and such, seem to do POR right. >> > >Even they seem to have their oops moments. > >http://www.nxp.com/documents/user_manual/UM10430.pdf > >Quote page 9: "POR reset value of the event router STATUS register >corrected" > >http://www.nxp.com/documents/errata_sheet/ES_LPC176X.pdf > >Quote page 18: > >"Problem: > >The USB host controller will hang indefinitely if it sees a dribble bit >on the USB bus. It will hang the first time a dribble bit is seen. Once >it is in this state there is no recovery other than a hard chip reset. >This problem has no effect on the USB device controller. > >Work-around: > >None." > >End quote > > >> All the FPGAs that we have used lately, ditto. >> >> You can connect one of those ARMs, or an FPGA, to a serial flash chip >> and have the whole thing boot up reliably. >> > >If you use certain FPGA you'd first have to call the people at your >energy provider that you are about to turn it on :-) Nah, 0.9 volts at 15 amps isn't a lot of power. It's your bank that you have to call before you design in a big FPGA. Some of the chips cost over $10K. Digikey offers one Virtex for $54,976.08000. Why steal diamonds when a reel of FPGAs is worth millions? -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
[toc] | [prev] | [next] | [standalone]
| From | Lasse Langwadt Christensen <langwadt@fonz.dk> |
|---|---|
| Date | 2017-02-15 10:58 -0800 |
| Message-ID | <00d0137c-b220-467b-89d2-e7e1427d7bbd@googlegroups.com> |
| In reply to | #447773 |
Den onsdag den 15. februar 2017 kl. 19.53.11 UTC+1 skrev John Larkin: > On Wed, 15 Feb 2017 10:19:27 -0800, Joerg <news@analogconsultants.com> > wrote: > > >On 2017-02-15 08:30, John Larkin wrote: > >> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> > >> wrote: > >> > >>> On 2017-02-14 19:55, Reinhardt Behm wrote: > >>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: > >>>> > >>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm > >>>>> wrote: > >>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: > >>>>>> > >>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: > >>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ > >>>>>>>> > >>> > >>> IME most analog failures are caused by ESD and that is often squarely in > >>> the court of the board level designer. > >>> > >>> Upsets without subsequent chip damage are also considered a fault where > >>> the function is mission-critical. That is very often due to EMI. > >>> > >>> > >>>>>>>> My experience is that we find a lot of bugs and documentation problems > >>>>>>>> with the digital parts of mixed-signal chips. > >>>>>>> > >>>>>>> It does seem like when analog designers get to design the digital parts > >>>>>>> of a chip it often ends up with a hairball of hazards and weird quirks > >>>>>> > >>>>>> That was always my experience with part from NatSemi. Pure analog was > >>>>>> good, pure digital was good, mixed mostly was a mess. > >>>>> > >>>>> Mixed signal design is difficult, and doing it on a chip, where it is > >>>>> harder to keep the noisy digital bits away from the sensitive analog bits, > >>>>> wouldn't have made it any easier. > >>>>> > >>>>> Sadly, mixed signal design can do a lot more than pure analog or pure > >>>>> digital, so if you have got something complicated to do, that tends to be > >>>>> what you end up doing. > >>>> > >>>> It was never the problem of digital noise coupling into the analog portions > >>>> but the digital totally mixed up, like the LM75 going into a state where > >>>> only a power cycle helps to get it working again. This can be caused by > >>>> noise on the I2C signals. > >>> > >>> > >>> I2C is a bus I try not to use if it can be avoided because of various > >>> hang-ups. SPI is much more robust IME and, therefore, that is what I prefer. > >> > >> I prefer SPI too, and it's faster, but lots of people design terrible > >> SPI interfaces, bad logic design and bad clock/data circuits. Every > >> SPI should have schmitt inputs and safe timing margins. Maybe cooking > >> a digital design into an analog process causes compromises, but I > >> suspect it's just sloppy engineering. > >> > >>> > >>> > >>>> I had the same with a part from Microchip. It has a config bit to > >>>> automatically reset its I2C interface after a timeout period without any > >>>> activity on the bus. This bit is reset after power on. So if the interface > >>>> goes gaga because of a poor POR you never get it working. > >>>> > >>> > >>> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. > >>> However, a poor POR is something the circuit designer should take care > >>> of. Never trust any on-chip POR/BOR. Ever. > >> > >> The little NXP ARM chips, LPC1768 and such, seem to do POR right. > >> > > > >Even they seem to have their oops moments. > > > >http://www.nxp.com/documents/user_manual/UM10430.pdf > > > >Quote page 9: "POR reset value of the event router STATUS register > >corrected" > > > >http://www.nxp.com/documents/errata_sheet/ES_LPC176X.pdf > > > >Quote page 18: > > > >"Problem: > > > >The USB host controller will hang indefinitely if it sees a dribble bit > >on the USB bus. It will hang the first time a dribble bit is seen. Once > >it is in this state there is no recovery other than a hard chip reset. > >This problem has no effect on the USB device controller. > > > >Work-around: > > > >None." > > > >End quote > > > > > >> All the FPGAs that we have used lately, ditto. > >> > >> You can connect one of those ARMs, or an FPGA, to a serial flash chip > >> and have the whole thing boot up reliably. > >> > > > >If you use certain FPGA you'd first have to call the people at your > >energy provider that you are about to turn it on :-) > > Nah, 0.9 volts at 15 amps isn't a lot of power. > > It's your bank that you have to call before you design in a big FPGA. > Some of the chips cost over $10K. > > Digikey offers one Virtex for $54,976.08000. Why steal diamonds when a > reel of FPGAs is worth millions? a couple of zeros was added to make up the numbers for a military contract ;)
[toc] | [prev] | [next] | [standalone]
| From | "Tim Williams" <tiwill@seventransistorlabs.com> |
|---|---|
| Date | 2017-02-15 21:25 -0600 |
| Message-ID | <o8360m$18v$1@dont-email.me> |
| In reply to | #447773 |
"John Larkin" <jjlarkinxyxy@highlandtechnology.com> wrote in message news:ti89ac5vffhmu7jmrulvq4vq5091baefa9@4ax.com... > It's your bank that you have to call before you design in a big FPGA. > Some of the chips cost over $10K. > > Digikey offers one Virtex for $54,976.08000. Why steal diamonds when a > reel of FPGAs is worth millions? What, you think anyone would actually pay for illegitimate ones? They depreciate faster than cars! Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-02-15 20:18 -0800 |
| Message-ID | <ht9aacltinj49qm35lchsfqnrlid548l15@4ax.com> |
| In reply to | #447820 |
On Wed, 15 Feb 2017 21:25:56 -0600, "Tim Williams" <tiwill@seventransistorlabs.com> wrote: >"John Larkin" <jjlarkinxyxy@highlandtechnology.com> wrote in message >news:ti89ac5vffhmu7jmrulvq4vq5091baefa9@4ax.com... >> It's your bank that you have to call before you design in a big FPGA. >> Some of the chips cost over $10K. >> >> Digikey offers one Virtex for $54,976.08000. Why steal diamonds when a >> reel of FPGAs is worth millions? > >What, you think anyone would actually pay for illegitimate ones? > >They depreciate faster than cars! > >Tim There was a Vietnamese gang in San Jose that performed armed robberies on trucks full of Intel CPUs. -- John Larkin Highland Technology, Inc lunatic fringe electronics
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-17 15:44 -0500 |
| Message-ID | <o87n8n$vh5$1@dont-email.me> |
| In reply to | #447773 |
On 2/15/2017 1:53 PM, John Larkin wrote: > > It's your bank that you have to call before you design in a big FPGA. > Some of the chips cost over $10K. > > Digikey offers one Virtex for $54,976.08000. Why steal diamonds when a > reel of FPGAs is worth millions? You think that doesn't happen? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-17 15:30 -0500 |
| Message-ID | <o87mdm$qru$2@dont-email.me> |
| In reply to | #447746 |
On 2/15/2017 11:30 AM, John Larkin wrote: > On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> > wrote: > >> On 2017-02-14 19:55, Reinhardt Behm wrote: >>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>> >>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>> wrote: >>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>>>> >>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>> >> >> IME most analog failures are caused by ESD and that is often squarely in >> the court of the board level designer. >> >> Upsets without subsequent chip damage are also considered a fault where >> the function is mission-critical. That is very often due to EMI. >> >> >>>>>>> My experience is that we find a lot of bugs and documentation problems >>>>>>> with the digital parts of mixed-signal chips. >>>>>> >>>>>> It does seem like when analog designers get to design the digital parts >>>>>> of a chip it often ends up with a hairball of hazards and weird quirks >>>>> >>>>> That was always my experience with part from NatSemi. Pure analog was >>>>> good, pure digital was good, mixed mostly was a mess. >>>> >>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>> harder to keep the noisy digital bits away from the sensitive analog bits, >>>> wouldn't have made it any easier. >>>> >>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>> digital, so if you have got something complicated to do, that tends to be >>>> what you end up doing. >>> >>> It was never the problem of digital noise coupling into the analog portions >>> but the digital totally mixed up, like the LM75 going into a state where >>> only a power cycle helps to get it working again. This can be caused by >>> noise on the I2C signals. >> >> >> I2C is a bus I try not to use if it can be avoided because of various >> hang-ups. SPI is much more robust IME and, therefore, that is what I prefer. > > I prefer SPI too, and it's faster, but lots of people design terrible > SPI interfaces, bad logic design and bad clock/data circuits. Every > SPI should have schmitt inputs and safe timing margins. Maybe cooking > a digital design into an analog process causes compromises, but I > suspect it's just sloppy engineering. Not trying to be snarky, but most digital engineers work to eliminate noise and to have proper clocks without noise on the transition edge. Schmitt is only needed on the clock inputs, but even there proper design at the board level eliminates the need. >>> I had the same with a part from Microchip. It has a config bit to >>> automatically reset its I2C interface after a timeout period without any >>> activity on the bus. This bit is reset after power on. So if the interface >>> goes gaga because of a poor POR you never get it working. >>> >> >> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >> However, a poor POR is something the circuit designer should take care >> of. Never trust any on-chip POR/BOR. Ever. > > The little NXP ARM chips, LPC1768 and such, seem to do POR right. > > All the FPGAs that we have used lately, ditto. > > You can connect one of those ARMs, or an FPGA, to a serial flash chip > and have the whole thing boot up reliably. > > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-17 14:05 -0800 |
| Message-ID | <egpackFdjfvU2@mid.individual.net> |
| In reply to | #448047 |
On 2017-02-17 12:30, rickman wrote: > On 2/15/2017 11:30 AM, John Larkin wrote: >> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >> wrote: >> >>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>> >>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>> wrote: >>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>> wrote: >>>>>> >>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>> Larkin: >>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>> >>> >>> IME most analog failures are caused by ESD and that is often squarely in >>> the court of the board level designer. >>> >>> Upsets without subsequent chip damage are also considered a fault where >>> the function is mission-critical. That is very often due to EMI. >>> >>> >>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>> problems >>>>>>>> with the digital parts of mixed-signal chips. >>>>>>> >>>>>>> It does seem like when analog designers get to design the digital >>>>>>> parts >>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>> quirks >>>>>> >>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>> good, pure digital was good, mixed mostly was a mess. >>>>> >>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>> harder to keep the noisy digital bits away from the sensitive >>>>> analog bits, >>>>> wouldn't have made it any easier. >>>>> >>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>> digital, so if you have got something complicated to do, that tends >>>>> to be >>>>> what you end up doing. >>>> >>>> It was never the problem of digital noise coupling into the analog >>>> portions >>>> but the digital totally mixed up, like the LM75 going into a state >>>> where >>>> only a power cycle helps to get it working again. This can be caused by >>>> noise on the I2C signals. >>> >>> >>> I2C is a bus I try not to use if it can be avoided because of various >>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>> prefer. >> >> I prefer SPI too, and it's faster, but lots of people design terrible >> SPI interfaces, bad logic design and bad clock/data circuits. Every >> SPI should have schmitt inputs and safe timing margins. Maybe cooking >> a digital design into an analog process causes compromises, but I >> suspect it's just sloppy engineering. > > Not trying to be snarky, but most digital engineers work to eliminate > noise and to have proper clocks without noise on the transition edge. > Schmitt is only needed on the clock inputs, but even there proper design > at the board level eliminates the need. > Schmitt is needed everywhere a signal connect to the outside world. A lot of uC design engineers do not understand this. [...] -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-17 17:16 -0500 |
| Message-ID | <o87sjs$h3a$2@dont-email.me> |
| In reply to | #448065 |
On 2/17/2017 5:05 PM, Joerg wrote: > On 2017-02-17 12:30, rickman wrote: >> On 2/15/2017 11:30 AM, John Larkin wrote: >>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >>> wrote: >>> >>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>> >>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>>> wrote: >>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>> wrote: >>>>>>> >>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>> Larkin: >>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>> >>>> >>>> IME most analog failures are caused by ESD and that is often >>>> squarely in >>>> the court of the board level designer. >>>> >>>> Upsets without subsequent chip damage are also considered a fault where >>>> the function is mission-critical. That is very often due to EMI. >>>> >>>> >>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>> problems >>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>> >>>>>>>> It does seem like when analog designers get to design the digital >>>>>>>> parts >>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>> quirks >>>>>>> >>>>>>> That was always my experience with part from NatSemi. Pure analog >>>>>>> was >>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>> >>>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>> analog bits, >>>>>> wouldn't have made it any easier. >>>>>> >>>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>>> digital, so if you have got something complicated to do, that tends >>>>>> to be >>>>>> what you end up doing. >>>>> >>>>> It was never the problem of digital noise coupling into the analog >>>>> portions >>>>> but the digital totally mixed up, like the LM75 going into a state >>>>> where >>>>> only a power cycle helps to get it working again. This can be >>>>> caused by >>>>> noise on the I2C signals. >>>> >>>> >>>> I2C is a bus I try not to use if it can be avoided because of various >>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>> prefer. >>> >>> I prefer SPI too, and it's faster, but lots of people design terrible >>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>> a digital design into an analog process causes compromises, but I >>> suspect it's just sloppy engineering. >> >> Not trying to be snarky, but most digital engineers work to eliminate >> noise and to have proper clocks without noise on the transition edge. >> Schmitt is only needed on the clock inputs, but even there proper design >> at the board level eliminates the need. >> > > Schmitt is needed everywhere a signal connect to the outside world. A > lot of uC design engineers do not understand this. Define "outside world". Do you mean off board? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-17 14:38 -0800 |
| Message-ID | <egpc9uFe0r5U1@mid.individual.net> |
| In reply to | #448069 |
On 2017-02-17 14:16, rickman wrote: > On 2/17/2017 5:05 PM, Joerg wrote: >> On 2017-02-17 12:30, rickman wrote: >>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >>>> wrote: >>>> >>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>> >>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>>>> wrote: >>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>> Larkin: >>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>> >>>>> >>>>> IME most analog failures are caused by ESD and that is often >>>>> squarely in >>>>> the court of the board level designer. >>>>> >>>>> Upsets without subsequent chip damage are also considered a fault >>>>> where >>>>> the function is mission-critical. That is very often due to EMI. >>>>> >>>>> >>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>> problems >>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>> >>>>>>>>> It does seem like when analog designers get to design the digital >>>>>>>>> parts >>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>> quirks >>>>>>>> >>>>>>>> That was always my experience with part from NatSemi. Pure analog >>>>>>>> was >>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>> >>>>>>> Mixed signal design is difficult, and doing it on a chip, where >>>>>>> it is >>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>> analog bits, >>>>>>> wouldn't have made it any easier. >>>>>>> >>>>>>> Sadly, mixed signal design can do a lot more than pure analog or >>>>>>> pure >>>>>>> digital, so if you have got something complicated to do, that tends >>>>>>> to be >>>>>>> what you end up doing. >>>>>> >>>>>> It was never the problem of digital noise coupling into the analog >>>>>> portions >>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>> where >>>>>> only a power cycle helps to get it working again. This can be >>>>>> caused by >>>>>> noise on the I2C signals. >>>>> >>>>> >>>>> I2C is a bus I try not to use if it can be avoided because of various >>>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>>> prefer. >>>> >>>> I prefer SPI too, and it's faster, but lots of people design terrible >>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>>> a digital design into an analog process causes compromises, but I >>>> suspect it's just sloppy engineering. >>> >>> Not trying to be snarky, but most digital engineers work to eliminate >>> noise and to have proper clocks without noise on the transition edge. >>> Schmitt is only needed on the clock inputs, but even there proper design >>> at the board level eliminates the need. >>> >> >> Schmitt is needed everywhere a signal connect to the outside world. A >> lot of uC design engineers do not understand this. > > Define "outside world". Do you mean off board? > Yes, or via a noisy area on the board. Also if slow on-board sensors are involved. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-17 17:58 -0500 |
| Message-ID | <o87v36$pph$1@dont-email.me> |
| In reply to | #448073 |
On 2/17/2017 5:38 PM, Joerg wrote: > On 2017-02-17 14:16, rickman wrote: >> On 2/17/2017 5:05 PM, Joerg wrote: >>> On 2017-02-17 12:30, rickman wrote: >>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >>>>> wrote: >>>>> >>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>>> >>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt >>>>>>>> Behm >>>>>>>> wrote: >>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>>> Larkin: >>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>> >>>>>> >>>>>> IME most analog failures are caused by ESD and that is often >>>>>> squarely in >>>>>> the court of the board level designer. >>>>>> >>>>>> Upsets without subsequent chip damage are also considered a fault >>>>>> where >>>>>> the function is mission-critical. That is very often due to EMI. >>>>>> >>>>>> >>>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>>> problems >>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>> >>>>>>>>>> It does seem like when analog designers get to design the digital >>>>>>>>>> parts >>>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>>> quirks >>>>>>>>> >>>>>>>>> That was always my experience with part from NatSemi. Pure analog >>>>>>>>> was >>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>> >>>>>>>> Mixed signal design is difficult, and doing it on a chip, where >>>>>>>> it is >>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>> analog bits, >>>>>>>> wouldn't have made it any easier. >>>>>>>> >>>>>>>> Sadly, mixed signal design can do a lot more than pure analog or >>>>>>>> pure >>>>>>>> digital, so if you have got something complicated to do, that tends >>>>>>>> to be >>>>>>>> what you end up doing. >>>>>>> >>>>>>> It was never the problem of digital noise coupling into the analog >>>>>>> portions >>>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>>> where >>>>>>> only a power cycle helps to get it working again. This can be >>>>>>> caused by >>>>>>> noise on the I2C signals. >>>>>> >>>>>> >>>>>> I2C is a bus I try not to use if it can be avoided because of various >>>>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>>>> prefer. >>>>> >>>>> I prefer SPI too, and it's faster, but lots of people design terrible >>>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>>>> a digital design into an analog process causes compromises, but I >>>>> suspect it's just sloppy engineering. >>>> >>>> Not trying to be snarky, but most digital engineers work to eliminate >>>> noise and to have proper clocks without noise on the transition edge. >>>> Schmitt is only needed on the clock inputs, but even there proper >>>> design >>>> at the board level eliminates the need. >>>> >>> >>> Schmitt is needed everywhere a signal connect to the outside world. A >>> lot of uC design engineers do not understand this. >> >> Define "outside world". Do you mean off board? >> > > Yes, or via a noisy area on the board. Also if slow on-board sensors are > involved. That's why I said... "most digital engineers work to eliminate noise and to have proper clocks without noise on the transition edge. " -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-17 15:37 -0800 |
| Message-ID | <egpfp7Fel2lU1@mid.individual.net> |
| In reply to | #448074 |
On 2017-02-17 14:58, rickman wrote: > On 2/17/2017 5:38 PM, Joerg wrote: >> On 2017-02-17 14:16, rickman wrote: >>> On 2/17/2017 5:05 PM, Joerg wrote: >>>> On 2017-02-17 12:30, rickman wrote: >>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>> <news@analogconsultants.com> >>>>>> wrote: >>>>>> >>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>>>> >>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt >>>>>>>>> Behm >>>>>>>>> wrote: >>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>>>> Larkin: >>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>> squarely in >>>>>>> the court of the board level designer. >>>>>>> >>>>>>> Upsets without subsequent chip damage are also considered a fault >>>>>>> where >>>>>>> the function is mission-critical. That is very often due to EMI. >>>>>>> >>>>>>> >>>>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>>>> problems >>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>> >>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>> digital >>>>>>>>>>> parts >>>>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>>>> quirks >>>>>>>>>> >>>>>>>>>> That was always my experience with part from NatSemi. Pure analog >>>>>>>>>> was >>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>> >>>>>>>>> Mixed signal design is difficult, and doing it on a chip, where >>>>>>>>> it is >>>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>>> analog bits, >>>>>>>>> wouldn't have made it any easier. >>>>>>>>> >>>>>>>>> Sadly, mixed signal design can do a lot more than pure analog or >>>>>>>>> pure >>>>>>>>> digital, so if you have got something complicated to do, that >>>>>>>>> tends >>>>>>>>> to be >>>>>>>>> what you end up doing. >>>>>>>> >>>>>>>> It was never the problem of digital noise coupling into the analog >>>>>>>> portions >>>>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>>>> where >>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>> caused by >>>>>>>> noise on the I2C signals. >>>>>>> >>>>>>> >>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>> various >>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>>>>> prefer. >>>>>> >>>>>> I prefer SPI too, and it's faster, but lots of people design terrible >>>>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>>>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>>>>> a digital design into an analog process causes compromises, but I >>>>>> suspect it's just sloppy engineering. >>>>> >>>>> Not trying to be snarky, but most digital engineers work to eliminate >>>>> noise and to have proper clocks without noise on the transition edge. >>>>> Schmitt is only needed on the clock inputs, but even there proper >>>>> design >>>>> at the board level eliminates the need. >>>>> >>>> >>>> Schmitt is needed everywhere a signal connect to the outside world. A >>>> lot of uC design engineers do not understand this. >>> >>> Define "outside world". Do you mean off board? >>> >> >> Yes, or via a noisy area on the board. Also if slow on-board sensors are >> involved. > > That's why I said... > > "most digital engineers work to eliminate > noise and to have proper clocks without noise on the transition edge. " > ... and then overlook that there can be external influences into boards and system. Such as EMI, magnetic fields or even weird stuff like that inexplicable double-pulse whenever somebody uses the freight elevator. But who am I to complain, this stuff brought me plenty of assignments. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-17 18:51 -0500 |
| Message-ID | <o8826j$6fq$1@dont-email.me> |
| In reply to | #448080 |
On 2/17/2017 6:37 PM, Joerg wrote: > On 2017-02-17 14:58, rickman wrote: >> On 2/17/2017 5:38 PM, Joerg wrote: >>> On 2017-02-17 14:16, rickman wrote: >>>> On 2/17/2017 5:05 PM, Joerg wrote: >>>>> On 2017-02-17 12:30, rickman wrote: >>>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>>> <news@analogconsultants.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>>>>> >>>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt >>>>>>>>>> Behm >>>>>>>>>> wrote: >>>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>>>>> Larkin: >>>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> >>>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>>> squarely in >>>>>>>> the court of the board level designer. >>>>>>>> >>>>>>>> Upsets without subsequent chip damage are also considered a fault >>>>>>>> where >>>>>>>> the function is mission-critical. That is very often due to EMI. >>>>>>>> >>>>>>>> >>>>>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>>>>> problems >>>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>>> >>>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>>> digital >>>>>>>>>>>> parts >>>>>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>>>>> quirks >>>>>>>>>>> >>>>>>>>>>> That was always my experience with part from NatSemi. Pure >>>>>>>>>>> analog >>>>>>>>>>> was >>>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>>> >>>>>>>>>> Mixed signal design is difficult, and doing it on a chip, where >>>>>>>>>> it is >>>>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>>>> analog bits, >>>>>>>>>> wouldn't have made it any easier. >>>>>>>>>> >>>>>>>>>> Sadly, mixed signal design can do a lot more than pure analog or >>>>>>>>>> pure >>>>>>>>>> digital, so if you have got something complicated to do, that >>>>>>>>>> tends >>>>>>>>>> to be >>>>>>>>>> what you end up doing. >>>>>>>>> >>>>>>>>> It was never the problem of digital noise coupling into the analog >>>>>>>>> portions >>>>>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>>>>> where >>>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>>> caused by >>>>>>>>> noise on the I2C signals. >>>>>>>> >>>>>>>> >>>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>>> various >>>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is >>>>>>>> what I >>>>>>>> prefer. >>>>>>> >>>>>>> I prefer SPI too, and it's faster, but lots of people design >>>>>>> terrible >>>>>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>>>>> SPI should have schmitt inputs and safe timing margins. Maybe >>>>>>> cooking >>>>>>> a digital design into an analog process causes compromises, but I >>>>>>> suspect it's just sloppy engineering. >>>>>> >>>>>> Not trying to be snarky, but most digital engineers work to eliminate >>>>>> noise and to have proper clocks without noise on the transition edge. >>>>>> Schmitt is only needed on the clock inputs, but even there proper >>>>>> design >>>>>> at the board level eliminates the need. >>>>>> >>>>> >>>>> Schmitt is needed everywhere a signal connect to the outside world. A >>>>> lot of uC design engineers do not understand this. >>>> >>>> Define "outside world". Do you mean off board? >>>> >>> >>> Yes, or via a noisy area on the board. Also if slow on-board sensors are >>> involved. >> >> That's why I said... >> >> "most digital engineers work to eliminate >> noise and to have proper clocks without noise on the transition edge. " >> > > .... and then overlook that there can be external influences into boards > and system. Such as EMI, magnetic fields or even weird stuff like that > inexplicable double-pulse whenever somebody uses the freight elevator. > But who am I to complain, this stuff brought me plenty of assignments. I'm not overlooking anything. All that is part of the engineer's job. A Schmitt trigger would be a panacea for none of the above. A Schmitt trigger is useful when appropriate, but the original post was about "every SPI" having Schmitt inputs. First, its only useful on edges and so only the clock. Secondly it is not something you can't add externally. I don't know why a chip designer wouldn't include a Schmitt trigger on clock inputs, but I'm not going to second guess them on something as unimportant as this. I'd much prefer they got the circuit design right. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | sci.electronics.design
csiph-web