battery chargers, again
in [Design]
|
From: Joerg on 5 Oct 2009 13:19 krw wrote: > On Sun, 04 Oct 2009 14:44:45 -0700, John Larkin > <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >> On Sat, 03 Oct 2009 12:04:03 -0700, Joerg <invalid(a)invalid.invalid> >> wrote: >> >>> John Larkin wrote: >>>> On Fri, 02 Oct 2009 07:09:34 -0700, Joerg <invalid(a)invalid.invalid> >>>> wrote: >>>> >>>>> John Larkin wrote: >>>>>> On Thu, 01 Oct 2009 14:06:36 -0700, Joerg <invalid(a)invalid.invalid> >>>>>> wrote: >>>>>> >>>>>> >>>>>>>> The layout is tedious, because we're optimizing the BGA FPGA routing >>>>>>>> as we go along... can't just draw the schematic and go forward to the >>>>>>>> board. >>>>>>>> >>>>>>> Ouch. >>>>>>> >>>>>>> >>>>>>>> This *is* rev 30. >>>>>>>> >>>>>>> Double-Ouch. I am firing up rev 1 of a really unorthodox cicuit this >>>>>>> afternoon. Wish me luck, and if you hear a muffled boom north-east from >>>>>>> you guys ... >>>>>> Was that an earthquake or was the Joerg? >>>>>> >>>>> No, it worked, must have been an earthquake then ;-) >>>>> >>>>> >>>>>> To calarify, this is rev 30 of the working layout. We haven't fabbed >>>>>> any boards yet. >>>>>> >>>>>> The PCB file will be formally released as 26D150A.PCB, to make rev A >>>>>> of the product. During layout, we number every iteration. If we change >>>>>> a net or add a resistor or whatever, we start with schematic >>>>>> 26S150A29.SCH, change it to 26S150A30.SCH and save that, make the >>>>>> differences file ECO30, apply that onto pcb 26D150A29.PCB, and save as >>>>>> 26D150A30.PCB. So we have all the iterations and all the ECO files, >>>>>> all organized. When we release the schematic and pcb as rev A, we >>>>>> delete all that working junk. Since we're iterating on the BGA pinout, >>>>>> we're spinning a lot of ECOs. >>>>>> >>>>>> If we go A to B, we start the sequence all over, 26S150B1.SCH etc. >>>>>> >>>>> I do it similarly, except adding X1, X2 and so on. And I usually cannot >>>>> erase the intermediates upon ECO-release because federal agencies often >>>>> require that a complete design history be kept. So if you do medical, >>>>> maybe better not to toss it. >>>> The next logical step would be to log every key and mouse click, and >>>> videotape everything that happens in Engineering. >>>> >>> Orwell ... >>> >>> But seriously, all they want is that you are able to show, for example, >>> why you dismissed a direct conversions scheme somewhere, how the old >>> schematic looked, and how the new one looks. An answer like "Oh, ahm, >>> well, I guess we must have purged the old files" raises some flags and >>> creates an urge to dig some more. >>> >>> They don't want to know the shoe size of all the people signing an ECO. >>> At least not yet :-) >> The ECOs I'm talking about are just "differences" files that PADS >> makes whenever you edit a schematic and want to carry the changes over >> to the PCB. We can do several of them a day when a board is being >> created or revised. At the end, we crosscheck the schematic and pcb >> netlists and formally release the new letter rev. We always archive >> all the released files of all the revs, and anything else that >> controls the configuration or processing of anything shippable. > > What do you do with "what if" branches off a work in progress? What > does Joerg do? > >> We do formally release "real" ECOs. >> >> But so far, we answer to nobody as regards internal procedures. What >> you buy is what you get. > > Joerg's process sounds like it's the "bury 'em in bullshit" answer to > design documentation. ;-) You probably haven't worked in aerospace or medical :-) Those are markets where the federales _tell_ you how it's done. You don't get to pick. And their requested methods make a lot of sense. If you violate that chances are they either put you out of business or you land in front of a jury some day. I've seen the FDA snuff out a huge business. It was not pretty. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: Joerg on 5 Oct 2009 13:27 krw wrote: > On Sun, 04 Oct 2009 17:28:59 -0700, John Larkin > <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >> On Sun, 04 Oct 2009 17:06:33 -0500, krw <krw(a)att.bizzzzzzzzzzz> wrote: >> >> >>>> The ECOs I'm talking about are just "differences" files that PADS >>>> makes whenever you edit a schematic and want to carry the changes over >>>> to the PCB. We can do several of them a day when a board is being >>>> created or revised. At the end, we crosscheck the schematic and pcb >>>> netlists and formally release the new letter rev. We always archive >>>> all the released files of all the revs, and anything else that >>>> controls the configuration or processing of anything shippable. >>> What do you do with "what if" branches off a work in progress? What >>> does Joerg do? >> I'm not sure what you mean by that. > > You apparently save/rename on any small layout change (with Joerg > taking the obsession to the schematic level). What do you do if you > just want to see how something will work out, not necessarily with the > intention of keeping the test? I often try things on a schematic > (don't do layout myself) just to see how it'll work. I certainly am > not going to do an ECO on every tweak. We're already beat up for the > number of ECOs generated (stupid, but reality often is). You do not have to generate an ECO for every little change, as long as nothing is produced with that change. As for obsession, this is the MO here: My last design has 16 consecutive SPICE files and three consecutive schematic files, of course along with three versions of the module spec. Now product was built, I am testing it right now. 16 might sound excessive but I can go back to every major design decision, look up the reasons and so on. It is very nice to be able to say "Oh, let's simulate this situation with the #5 file again where the other comparators were used". Of course I don't store when I simply try out another resistor value or transistor somewhere. Only after I decide to keep the changes. The SPICE files are under 50kB each and the schematics a few hundred kB. What's the big deal? And yeah, I am the kind of guy who starts every design with a blank word processor document. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
From: John Larkin on 5 Oct 2009 14:54 On Mon, 05 Oct 2009 10:14:18 -0700, Joerg <invalid(a)invalid.invalid> wrote: >John Larkin wrote: >> On Sun, 04 Oct 2009 15:01:18 -0700, Joerg <invalid(a)invalid.invalid> >> wrote: >> >>> John Larkin wrote: >>>> On Sat, 03 Oct 2009 12:04:03 -0700, Joerg <invalid(a)invalid.invalid> >>>> wrote: >>>> >>>>> John Larkin wrote: >>>>>> On Fri, 02 Oct 2009 07:09:34 -0700, Joerg <invalid(a)invalid.invalid> >>>>>> wrote: >>>>>> >>>>>>> John Larkin wrote: >>> [...] >>> >>>>>>>> To calarify, this is rev 30 of the working layout. We haven't fabbed >>>>>>>> any boards yet. >>>>>>>> >>>>>>>> The PCB file will be formally released as 26D150A.PCB, to make rev A >>>>>>>> of the product. During layout, we number every iteration. If we change >>>>>>>> a net or add a resistor or whatever, we start with schematic >>>>>>>> 26S150A29.SCH, change it to 26S150A30.SCH and save that, make the >>>>>>>> differences file ECO30, apply that onto pcb 26D150A29.PCB, and save as >>>>>>>> 26D150A30.PCB. So we have all the iterations and all the ECO files, >>>>>>>> all organized. When we release the schematic and pcb as rev A, we >>>>>>>> delete all that working junk. Since we're iterating on the BGA pinout, >>>>>>>> we're spinning a lot of ECOs. >>>>>>>> >>>>>>>> If we go A to B, we start the sequence all over, 26S150B1.SCH etc. >>>>>>>> >>>>>>> I do it similarly, except adding X1, X2 and so on. And I usually cannot >>>>>>> erase the intermediates upon ECO-release because federal agencies often >>>>>>> require that a complete design history be kept. So if you do medical, >>>>>>> maybe better not to toss it. >>>>>> The next logical step would be to log every key and mouse click, and >>>>>> videotape everything that happens in Engineering. >>>>>> >>>>> Orwell ... >>>>> >>>>> But seriously, all they want is that you are able to show, for example, >>>>> why you dismissed a direct conversions scheme somewhere, how the old >>>>> schematic looked, and how the new one looks. An answer like "Oh, ahm, >>>>> well, I guess we must have purged the old files" raises some flags and >>>>> creates an urge to dig some more. >>>>> >>>>> They don't want to know the shoe size of all the people signing an ECO. >>>>> At least not yet :-) >>>> The ECOs I'm talking about are just "differences" files that PADS >>>> makes whenever you edit a schematic and want to carry the changes over >>>> to the PCB. We can do several of them a day when a board is being >>>> created or revised. At the end, we crosscheck the schematic and pcb >>>> netlists and formally release the new letter rev. We always archive >>>> all the released files of all the revs, and anything else that >>>> controls the configuration or processing of anything shippable. >>>> >>> That appears to be a sound procedure. As long as some prose is kept >>> alongside so you don't have to wonder in front of an inspector "Now why >>> did we change that?". >> >> Inspector? >> > >Yep. Sometimes also called auditors. And they do surprise audits. Knock, >knock. "Good morning. I am Mr.So-and-so from the FDA and I would like to >review your complaint database and some engineering items." I hired an engineer that worked on cancer treatment X-ray machines, essentially particle accelerators, for a Silicon Valley branch of a big European company. They had a pop inspection and the FDA boys found a new-production subassembly on the same test bench as a repair unit. Shutdown. After almost a year of doing procedure paperwork, and no engineering, he quit. > > >> We keep a "next" file on a server, something like >> >> J:\NEXT\V470\AtoB.TXT >> >> where anybody who has anything to say about rev A adds whatever they >> want to say. Production will comment on a pad or drill size. >> Purchasing will note any part EOL notices or whatever. Engineering >> might suggest a circuit change or a possible feature. Like that. Keeps >> us from forgetting the little stuff. We check any effective ECOs and >> the NEXT file whenever we do a board spin, before we decide what to >> actually do. >> >> Everything on the servers gets archived regularly. >> > >Sounds like a good method. I keep similar text files so nothing falls >through the cracks. Also helps if a Dodge Ram hits me head-on and >someone else would need to take over. No joke, this has happened. Not to >me but the motorcycle of a client engineer in Europe decided to develop >a crack in the frame at 100mph and then split into two parts. Sparks >flying, leather suit, skin, muscle tissue and some bone chafed off. He >survived but I had to take over for a while. This was only possible >because he documented as much as I do. What kind of bike? Some of the Kawasakis used to behave like that. > >Later he bought a Mercedes Diesel and quit riding motorcycles ... I gave up motorcycling too... the car drivers are insane lately. My wife has done therapy on too many brain-damaged bikers and decided she didn't want to be married to a member of the plant kingdom. I might still get a dirt bike for plunking out in the woods. At least trees don't *try* to kill you. John
From: Joerg on 5 Oct 2009 15:46
John Larkin wrote: > On Mon, 05 Oct 2009 10:14:18 -0700, Joerg <invalid(a)invalid.invalid> > wrote: > >> John Larkin wrote: >>> On Sun, 04 Oct 2009 15:01:18 -0700, Joerg <invalid(a)invalid.invalid> >>> wrote: >>> >>>> John Larkin wrote: >>>>> On Sat, 03 Oct 2009 12:04:03 -0700, Joerg <invalid(a)invalid.invalid> >>>>> wrote: >>>>> >>>>>> John Larkin wrote: >>>>>>> On Fri, 02 Oct 2009 07:09:34 -0700, Joerg <invalid(a)invalid.invalid> >>>>>>> wrote: >>>>>>> >>>>>>>> John Larkin wrote: >>>> [...] >>>> >>>>>>>>> To calarify, this is rev 30 of the working layout. We haven't fabbed >>>>>>>>> any boards yet. >>>>>>>>> >>>>>>>>> The PCB file will be formally released as 26D150A.PCB, to make rev A >>>>>>>>> of the product. During layout, we number every iteration. If we change >>>>>>>>> a net or add a resistor or whatever, we start with schematic >>>>>>>>> 26S150A29.SCH, change it to 26S150A30.SCH and save that, make the >>>>>>>>> differences file ECO30, apply that onto pcb 26D150A29.PCB, and save as >>>>>>>>> 26D150A30.PCB. So we have all the iterations and all the ECO files, >>>>>>>>> all organized. When we release the schematic and pcb as rev A, we >>>>>>>>> delete all that working junk. Since we're iterating on the BGA pinout, >>>>>>>>> we're spinning a lot of ECOs. >>>>>>>>> >>>>>>>>> If we go A to B, we start the sequence all over, 26S150B1.SCH etc. >>>>>>>>> >>>>>>>> I do it similarly, except adding X1, X2 and so on. And I usually cannot >>>>>>>> erase the intermediates upon ECO-release because federal agencies often >>>>>>>> require that a complete design history be kept. So if you do medical, >>>>>>>> maybe better not to toss it. >>>>>>> The next logical step would be to log every key and mouse click, and >>>>>>> videotape everything that happens in Engineering. >>>>>>> >>>>>> Orwell ... >>>>>> >>>>>> But seriously, all they want is that you are able to show, for example, >>>>>> why you dismissed a direct conversions scheme somewhere, how the old >>>>>> schematic looked, and how the new one looks. An answer like "Oh, ahm, >>>>>> well, I guess we must have purged the old files" raises some flags and >>>>>> creates an urge to dig some more. >>>>>> >>>>>> They don't want to know the shoe size of all the people signing an ECO. >>>>>> At least not yet :-) >>>>> The ECOs I'm talking about are just "differences" files that PADS >>>>> makes whenever you edit a schematic and want to carry the changes over >>>>> to the PCB. We can do several of them a day when a board is being >>>>> created or revised. At the end, we crosscheck the schematic and pcb >>>>> netlists and formally release the new letter rev. We always archive >>>>> all the released files of all the revs, and anything else that >>>>> controls the configuration or processing of anything shippable. >>>>> >>>> That appears to be a sound procedure. As long as some prose is kept >>>> alongside so you don't have to wonder in front of an inspector "Now why >>>> did we change that?". >>> Inspector? >>> >> Yep. Sometimes also called auditors. And they do surprise audits. Knock, >> knock. "Good morning. I am Mr.So-and-so from the FDA and I would like to >> review your complaint database and some engineering items." > > I hired an engineer that worked on cancer treatment X-ray machines, > essentially particle accelerators, for a Silicon Valley branch of a > big European company. They had a pop inspection and the FDA boys found > a new-production subassembly on the same test bench as a repair unit. > Shutdown. After almost a year of doing procedure paperwork, and no > engineering, he quit. > I am usually against inbreeding and have hired guys outside med devices, against the advice of colleagues and even the CEO. And it has paid off very well. But it is important that a guy with med device background runs the place because he can make sure that this sort of thing does not happen. We had fun, did tons of engineering and were never threatened with a shutdown. A lot also depends on attitude. If you tell the inspector that corrective action will commence immediately that's a different story than, for example, letting off a rant about bureaucrats (no matter how badly you'd want to) and basically blowing him off. Not sure if they've done that but such a small infraction usually does not result in a shutdown. Unless the inspector found a dozen other ones. >> >>> We keep a "next" file on a server, something like >>> >>> J:\NEXT\V470\AtoB.TXT >>> >>> where anybody who has anything to say about rev A adds whatever they >>> want to say. Production will comment on a pad or drill size. >>> Purchasing will note any part EOL notices or whatever. Engineering >>> might suggest a circuit change or a possible feature. Like that. Keeps >>> us from forgetting the little stuff. We check any effective ECOs and >>> the NEXT file whenever we do a board spin, before we decide what to >>> actually do. >>> >>> Everything on the servers gets archived regularly. >>> >> Sounds like a good method. I keep similar text files so nothing falls >> through the cracks. Also helps if a Dodge Ram hits me head-on and >> someone else would need to take over. No joke, this has happened. Not to >> me but the motorcycle of a client engineer in Europe decided to develop >> a crack in the frame at 100mph and then split into two parts. Sparks >> flying, leather suit, skin, muscle tissue and some bone chafed off. He >> survived but I had to take over for a while. This was only possible >> because he documented as much as I do. > > What kind of bike? Some of the Kawasakis used to behave like that. > I think it was a water-cooled one, could have been a two-stroke. Don't remember the brand but it was a wild thing on steroids. The kind where experienced bikers would say "Before you hop on one of these get your affairs in order". >> Later he bought a Mercedes Diesel and quit riding motorcycles ... > > I gave up motorcycling too... the car drivers are insane lately. My > wife has done therapy on too many brain-damaged bikers and decided she > didn't want to be married to a member of the plant kingdom. I might > still get a dirt bike for plunking out in the woods. At least trees > don't *try* to kill you. > Well, that's what a guy in my former hometown thought. Until he skidded a bit off the dirt path, went airborne and smacked onto the turf a couple hundred feet below. AFAIR he was instantly killed. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM. |