> > Stuart Brorson wrote: > > >I am very pleased to see how much intelligent discussion my little > >comments have sparked. This is a very educational thread. > > > > > > > >>Hopefully I'm not putting words in Stuarts mouth, but we're really > >>talking about 2 different things in this thread. Some of the comments > >>here are related to testing a bare board (no components soldered down > >>yet). In that case, the component pads are probably sufficient. > >> > >>The 2nd case, which I think is the one Stuart was initially asking > >>about, is for automated testing of a board which has been already > >>assembled. In that case, you really do want test pads on all the nodes > >>and preferably on one side of the board. We used to do that at a place > >>I worked and it was pretty cool. They'd stick a fully assembled > >>analog/mixed signal board into the tester and catch nearly all of the > >>boards with manufacturing (placement/soldering) defects. > >> > >> > > > >Thanks, Dan. I am indeed talking about testing fully assembled > >boards, not raw PCBs. That's why probing the component pads isn't > >possible or applicable. > > > >Stuart > > > > > > > Analog or digital? If digital, you could use boundary scan - if your > parts are jtag. What about some level of in circuit tests (ICT), > followed by system checkout at run-time via diagnostics?
JTAG is great. I've used it in the past at my day jobs. We use it to both test *and* program our PLDs. However, it only tests connectivity for larger chips (QFPs, BGAs, etc). For testing smaller glue logic, analog, and passives it doesn't help. > Not sure about analog designs though - not enough experience there. But > you could specify bed of nails tests to verify that the components are > correct value, and indeed soldered in place. Yup. That's why you need the test pads. > Where I work today - they have 0 test coverage from the board house, and > we pay dearly for lousy workmanship. Somehow the management doesn't see > it that way - but that's a whole other story. That's why I raise the issue of testpads in PCB. At work I have a board (my responsibility, but not my design -- ugh!) with a dismal yeild. The raw PCBs go through inspection at the assembler OK as far as I can tell. Since it has no test pads the vendor can't test it once it's stuffed. They just send us the stuffed boards, and we do functional test on a test platform which is a mock-up of our system. A good percentage of the boards fail. The failure mode is that the system acts flakey when this board is installed. If components would just burn up I could identify the problem. However, the boards look fine, and all connections which I have buzzed out are good. One clue: When I stress or flex a failing board in the test system, I can often make it work (until I release the board). This suggests cracked vias, ripped internal traces, or SMT passives with microcracks. All of these are hard to find visually. However, if the original designer had testpadded the board, we'd be able to reject these boards at the assembler. Given the amount of time I have spent debugging these board (usually with a factory tech idling beside me), added to the amount of management time spent holding senseless meeting about this problem board, and multiplied by the amount we are all paid/hour, I'd say that we have spent easily into the five figures because of this board. If the board was testpadded, we could have easily purchased a dedicated test machine from Teradyne dedicated to this board from the savings. That's why I became interested in the ability to place testpads in PCB. Finally, Dan suggested that one can testpad in both gschem and PCB. I have no problem with that. Indeed, if you take the route of placing testpad symbols in gschem, you can do testpads today -- just create a testpad element like the one DJ and I shared a couple of days ago and place one on every net. Like Dan says, this could be done with a script. Putting testpadding directly into PCB is a little tricker since PCB needs to know that the testpad is a non-netlist structure which shouldn't cause DRCs by itself (but should be checked for shorts to other nets, just like a polygon region or a via). One way to do it is to make a testpad a differentt type of via -- just like a non-plated through-hole is a different type of via. That is, you place a testpad, then click on it to edit its properties: Select "testpad", and it turs off the drill hole, and puts a metal disk on only the top (or bottom) layer. Stuart
