Is there a way to systematically insert ICT testpoints onto a PCB layout
without putting a testpoint component on each net on my schematic?
Ideally I'd like to know the percent of nets covered by testpoints and
have someway to highlight or locate nets without a testpoint so I can
either add one or can decide that the particular net isn't worth the
trouble to test.
-Michael
Michael Sansom schrieb:
Is there a way to systematically insert ICT testpoints onto a PCB layout
without putting a testpoint component on each net on my schematic?
Not to my knowledege.
Ideally I'd like to know the percent of nets covered by testpoints and
have someway to highlight or locate nets without a testpoint so I can
either add one or can decide that the particular net isn't worth the
trouble to test.
You could write an ULP that collects all net names and then checks which
nets are connected to testpoints (which should be identifiable by a
common prefix, for example). The easiest way to provide the results is a
list containing covered and uncovered net names - and that would also be
sufficient for your decision.
I don't know if such an ULP already exists.
Tilmann
On 12/28/2010 2:12 AM, Tilmann Reh wrote:
Michael Sansom schrieb:
>> Is there a way to systematically insert ICT testpoints onto a PCB layout
>> without putting a testpoint component on each net on my schematic?
Not to my knowledege.
This is quite unfortunate. In any engineering company I've ever
participated in of even a moderate size, the insertion of test points is
normally a post processing function, done by the PCB designer who more
often than not is not the engineer who generated the schematic. The PCB
designer is generally tasked with inserting test points so as to insure
that a minimum fault coverage is achieved during ICT (say 90% perhaps).
It is generally solely a function of the manufacturing/quality control
people to determine what test coverage level they desire and to insert
the test points to meet that level. The design engineer generally
neither cares nor wants to be bothered with that information. Only if
there are particular nets of interest that the design engineer wants to
ensure to be tested at ICT will he explicitly insert test points on the
schematic, and typically this will be for a very small percentage of the
total nets on the board.
Practically, having to insert all testpoints on the schematic results
in a cluttered, less readable schematic since you will in general want
to cover a high percentage of nets (ideally 100%). If this is not a
planned feature for future versions of Eagle I would encourage CadSoft
to seriously consider it.
I would think you would accomplish this by having a special class of PCB
components which are specifically excluded from consideration when
doing a cross check between the PCB layout and the schematic netlist.
-Michael
Michael Sansom wrote on Tue, 28 December 2010 11:25
In any engineering company I've ever
participated in of even a moderate size, the insertion of test points
is
normally a post processing function, done by the PCB designer who more
often than not is not the engineer who generated the schematic.
That's a bad idea. If you have a separate person doing the layout (that
itself is usually not a good idea), then they are usually a draftsman and
not a electrical engineer. They can't look at the circuit and determine
which nets need to be brought out to be measured or driven externally
during board test. This process may include a separate production test
engineer, but should always include the circuit designer.
For example, many points connected to a microcontroller don't need to be
connected directly to the tester. Usually you set up a communication link
to the microcontroller and have it report on the state of signals or drive
them as required. With a little cleverness, you can infer the operation of
components between the external connections and the micro too sometimes.
The point is, you don't want to blindly connect a pogo pin pad (or whatever
you use to connect to the tester) to every net. That would add needless
complexity to the board, the tester, and the test process.
Since you have to think about where to connect test points, these should be
on the schematic. Someone will need to review the test plan, which will
include matching test point on the board with the schematic. For
troubleshooting you want to know what TP7, for example, is connected to.
Or often you have the reverse case where you want to put a scope probe on a
particular net and want to know if it has a test point, where it is on the
board, and how it's labeled. In other words, you want test points to show
up in the cross reference list just like any other component.
--
Web access to CadSoft support forums at www.eaglecentral.ca. Where the CadSoft EAGLE community meets.
On 12/30/2010 8:08 AM, Olin Lathrop wrote:
Wow, that was a amazing bit of sideways logic. I was reacting to your
rediculous assertion that you always need to give a tester access to all
nets. It only takes a single counter example to disprove that, and I
supplied several such counter examples.
Your response is to act as if I said you are always limited to doing things
as in the counter examples, which is completely illogical.
Of course there are many methods to test a board. The point is that you
don't always need to have access to every net, not that you should never
have access to any net.
Sorry, been traveling for some time, back in the office now.
If I used sideways logic then you are just as guilty of it. I gave you
several counter examples where your methodology would not work and
several points on how your way can in some cases cause you to spend
recurring costs on the BOM, yet you choose to ignore those as well. So,
perhaps we are both guilty of sideways logic.
I have never claimed that I want access to every net on a board in all
cases. Sometimes I might (particularly if it's a board with no
microcontroller or reprogrammable logic, which I certainly admit is
rather rare). In fact, in general I want to use a combination of
methodologies to do automated testing of boards. Ideally, I'd use JTAG,
ICT test points, and yes your method as well where appropriate
(meaning where possible and where it does not incur recurring BOM cost).
A mix of methods will give me the most thorough and cost effective
means to test a populated board.
In summary I still propose that CadSoft should consider a means to add
test points during layout without adding them explicitly to the
schematic, (much like the way we add vias). This is supported in many
of the major CAD systems that Eagle competes with and follows the
methodology and division of labor used by many enterprises.
Wow, that was a amazing bit of sideways logic. I was reacting to your
rediculous assertion that you always need to give a tester access to all
nets. It only takes a single counter example to disprove that, and I
supplied several such counter examples.
Your response is to act as if I said you are always limited to doing things
as in the counter examples, which is completely illogical.
Of course there are many methods to test a board. The point is that you
don't always need to have access to every net, not that you should never
have access to any net.
Michael Sansom wrote on Wed, 29 December 2010 21:28
So the functionality of Eagle is perfect, ad unguem factus. No changes
necessary. Carve it in stone, it's done.
If you want to take that stance I think I'm not the one that sounds
silly.
No, I said your request is silly, not that all are.
The issues with your request are:
You are fixated on having a test point on every net, and therefore don't
want the test points to appear in the schematic and clutter it up.
You want to make circuit changes (test points are components, so adding
them is making a circuit change) without changing the schematic or it being
shown there.
Eagle can already do what you want anyway. You could write a ULP that runs
over every net in the schematic and adds a test point to it. The test
points would be a real part you define in the library, so would appear in
the board editor and need to be placed along with all the other parts. If
you don't want them to appear on the schematic, have the ULP add pages to
the end of the schematic that show only the test points connected to nets
by name. If you really really don't want people to see these test points
in the schematic, don't export those pages when you make the PDF file. I
really don't see the big deal with this method. All this fuss is because
you don't want a extra page or two at the end of the schematic with test
points on it!?
Quote:
But care to explain to me how you test the output of a microcontroller
that doesn't terminate on another JTAG device without adding
additional hardware or taking up additional pin resources on the micro?
I already did several times, but to reiterate, you have various options.
Of course you can put a test point on the output of the subcircuit driven
by that micro pin. Sometimes that output will be a board output you
already have access to. Sometimes you do have extra pins on the micro and
you can feed some signals back. Each case is different. The point is you
don't always need a test point on every net to accomplish the task.
Quote:
Let's say that I have a port pin on a microcontroller which I've hooked
to the internal PWM. I want to filter the output and run it to a
connector that goes off board. So, the output of the micro goes to an
op-amp and associated passive components which implement a 2nd order
Butterworth LPF. The output of that active LPF goes to a connector and
drives some externally connected device (maybe even someone else's
product). Sure, I could take the output of the LPF and run it to an
A/D
pin on my micro, but I've got to use precious port pins on my micro and
if I've got many signals like this I'll either run out of port pins or
A/D pins. If I run out of pins I can go to a bigger, higher pin count
micro or I can start dropping analog mux chips around the board. Each
generates recurring cost on the product.
Who said the only choice was to run the output of the LPF back to the
micro? Obviously it isn't. Sometimes a pin is available and that's a good
choice. In this case the signal goes off board, so of course the tester
will have access to it. It could hook up to the intended board connector,
or you could place a pogo pin pad close to the connector, depending on how
mechanically awkward it is to connect to the real connector.
Again, the point was you don't need access to every single net. This
example actually makes that point very well. The micro's PWM output drives
the filter, and you can verify the filter to acceptable confidence just be
looking at its output with a known input pattern. The filter in your
example has several internal nets. Most failures are going to manifest
themselves as incorrect output given a well designed input pattern, thereby
not requiring each component in the filter to be tested individually. This
is also a good case where using the micro as part of the test process is
probably useful. You can use the micro's own PWM generator to produce the
test signals for the LPF.
Just because I said you don't always need to test every net, you are
arguing against my statement because sometimes you do have to test some
nets. That is a logical fallacy since it doesn't counter my statement at
all.
Quote:
OTOH - I can drop ICT test points around my op-amp and the passive
components. Using the JTAG on the micro I can wiggle that port pin and
watch the effects on the nets connected to it. I can also directly
measure the resistors, capacitors, and inductors values and confirm
I've
loaded the right components and that indeed they did get soldered to
the
board. If my board isn't super tight, this cost me exactly nothing.
That is wrong. Of course it costs something. Testing every net in the
filter causes high cost in the tester, engineering time to design and debug
the test procedure, and incremental production time to perform the test.
The first two are fixed costs and amortized over all units. If your
volumes are high, the cost may be low per unit, but certainly not free.
The third is incremental cost per unit, and adds directly to the production
cost. Production time is not free.
So now let me explain some logic because you seem to have a problem in that
area. I can forsee you countering this with "but my volumes are so high,
and the cost of sending bad LPFs out there is much more than the extra
production time", or some such irrelevant statement. The paragraph is a
rebuttal to your silly statement that what you describe "cost you exactly
nothing", not that the LPF can't or shouldn't be tested, or whatever. I
have shown three ways the cost is more than zero, thereby disproving your
assertion. If you want to rebut, you need to show how all three points are
invalid.
Quote:
I understand completely the approach you propose.
Clearly not, since I haven't proposed anything. I have only provided
counter examples to your claim that you need access to all nets.
Quote:
I've used it. It
works well in some cases. But it can easily require you to bump into a
higher pin count microcontroller or start dropping analog muxes or
digital gates on your design. I'm not prepared to expend recurring
costs like that.
Of course. Looping signals back to the micro to facilitate testing isn't
always the optimum tradeoff, and I never said it was. I'm not the one who
thinks one plan (bringing out all nets to a tester) is the right approach
for all boards. In cases where you have unused pins on the micro, using
them for testing is something to consider.
Quote:
Yes, the sometimes the smallest micros don't do JTAG. But, since JTAG
has become the de facto standard for connecting a debugger to a
microcontroller it's pretty rare.
Then you're not up on what microcontroller products there are. Some do
have JTAG, but many many, in fact the majority don't, especially when you
look at units shipped. Take the leading microcontroller supplier,
Microchip, for example. How many PICs have JTAG? None of the 10, 12, and
16 family I think. Maybe some large 18s do, but most don't. Some of the
16 bitters, particularly in the larger packages do, like the 24, 30, and 33
families, but many also don't. It may be that most of the 32 family do.
In any case, the point is that many many digital parts, including the vast
majority of microcontrollers, don't support JTAG. JTAG can be useful when
present, but you can't claim a universal test strategy that relies on JTAG
always being there because it isn't.
Quote:
JTAG + ICT is a very powerful way to insure that your boards are
properly loaded and soldered.
Of course JTAG can be useful and appropriate for testing some designs, but
the point is ...?
Quote:
Almost certainly not unless field
reliability is
very very important and doubling the cost makes it worth it.
In my (and many other products) it is worth it.
OK, sometimes it is worth it (as I said), but again, your point is ...?
Quote:
Besides, a properly
implemented JTAG + ICT test procedure cost little to implement on the
product and it is much cheaper than doing any hands-on functional
testing.
Which would actually be relevant if I had somehow proposed the only
alternative to testing every single net is to do manual hands-on testing.
Quote:
Sure, no absolutes. But if all I was worried about was untested bypass
caps I wouldn't even think about ICT or JTAG.
Because I mentioned a hard to test case (bypass caps), this was somehow
taken to be a argument against JTAG or any other in-circuit testing!!?
Quote:
You could also
have the micro produce a known pattern on that pin and check for
the
expected result elswhere, perhaps even at output of the whole
board.
Sometimes with a little cleverness, it's not hard to verify most of
the
in-between components if the micro wiggles it's pin the right way
and you
analyse the output signal the right way.
Agree or not, it's very common. How would you propose to test such a
situation without adding additional cost to the product?
You could have the micro produce a known pattern on that pin and check for
the expected result elsewhere, perhaps even at output of the whole board.
Quote:
Ah, but with ICT test points its not a black box block. I can drop
test
points on "internal" nets and check them as well. I can even measure
R,
C, and L values and see if someone loaded the wrong reel on the pick
and
place machine (it does happen).
Being able to test all internal nets doesn't mean it couldn't be tested
effectively enough as a black box.
(now before you go off and knee jerk with a orthagonal argument, note that
this doesn't say all subsystems can be tested as black boxes, or that they
always should be if they can, only that it is possible and sometimes
appropriate and effective to do so, and that therefore there are
alternatives to always testing every net)
Quote:
For example, consider a switching power supply producing 3.3V from
10-30
volts in. That's hardly a far fetched case. The tester can often
verify
the power supply to acceptable confidence by varying the input
voltage and
measuring its current, and measuring the output voltage and being
able to
switch some additional loads onto it perhaps. If everything is
right with
a few test cases, you know the inductor, switch, catch diode,
feedback, and
control circuit are all working correctly without having to look at
the
various internal nets of the power supply.
If I have a switching power supply on my design (which I do) and the
output voltage doesn't leave the board, I've either got to drop some
ICT
test points on the board and measure the supply voltage at ICT, drop
test points on the board and have a human measure it by hand with a
voltmeter ($$$) or rely on your self testing scheme.
This reinforces my pointer very well. You don't need access to the power
supply's internal nets to be able to test it to acceptable confidence in
many cases.
Quote:
In fact, I think your
example is a fine demonstration of why you might need ICT.
Right, but since nobody was saying you should leave your board untested or
do it by hand or something, I don't see what your point is.
--
Web access to CadSoft support forums at www.eaglecentral.ca. Where the CadSoft EAGLE community meets.
Wow, that was a amazing bit of sideways logic. I was reacting to your
rediculous assertion that you always need to give a tester access to all
nets. It only takes a single counter example to disprove that, and I
supplied several such counter examples.
Your response is to act as if I said you are always limited to doing things
as in the counter examples, which is completely illogical.
Of course there are many methods to test a board. The point is that you
don't always need to have access to every net, not that you should never
have access to any net.
Michael Sansom wrote on Wed, 29 December 2010 21:28
So the functionality of Eagle is perfect, ad unguem factus. No changes
necessary. Carve it in stone, it's done.
If you want to take that stance I think I'm not the one that sounds
silly.
No, I said your request is silly, not that all are.
The issues with your request are:
You are fixated on having a test point on every net, and therefore don't
want the test points to appear in the schematic and clutter it up.
You want to make circuit changes (test points are components, so adding
them is making a circuit change) without changing the schematic or it being
shown there.
Eagle can already do what you want anyway. You could write a ULP that runs
over every net in the schematic and adds a test point to it. The test
points would be a real part you define in the library, so would appear in
the board editor and need to be placed along with all the other parts. If
you don't want them to appear on the schematic, have the ULP add pages to
the end of the schematic that show only the test points connected to nets
by name. If you really really don't want people to see these test points
in the schematic, don't export those pages when you make the PDF file. I
really don't see the big deal with this method. All this fuss is because
you don't want a extra page or two at the end of the schematic with test
points on it!?
Quote:
But care to explain to me how you test the output of a microcontroller
that doesn't terminate on another JTAG device without adding
additional hardware or taking up additional pin resources on the micro?
I already did several times, but to reiterate, you have various options.
Of course you can put a test point on the output of the subcircuit driven
by that micro pin. Sometimes that output will be a board output you
already have access to. Sometimes you do have extra pins on the micro and
you can feed some signals back. Each case is different. The point is you
don't always need a test point on every net to accomplish the task.
Quote:
Let's say that I have a port pin on a microcontroller which I've hooked
to the internal PWM. I want to filter the output and run it to a
connector that goes off board. So, the output of the micro goes to an
op-amp and associated passive components which implement a 2nd order
Butterworth LPF. The output of that active LPF goes to a connector and
drives some externally connected device (maybe even someone else's
product). Sure, I could take the output of the LPF and run it to an
A/D
pin on my micro, but I've got to use precious port pins on my micro and
if I've got many signals like this I'll either run out of port pins or
A/D pins. If I run out of pins I can go to a bigger, higher pin count
micro or I can start dropping analog mux chips around the board. Each
generates recurring cost on the product.
Who said the only choice was to run the output of the LPF back to the
micro? Obviously it isn't. Sometimes a pin is available and that's a good
choice. In this case the signal goes off board, so of course the tester
will have access to it. It could hook up to the intended board connector,
or you could place a pogo pin pad close to the connector, depending on how
mechanically awkward it is to connect to the real connector.
Again, the point was you don't need access to every single net. This
example actually makes that point very well. The micro's PWM output drives
the filter, and you can verify the filter to acceptable confidence just be
looking at its output with a known input pattern. The filter in your
example has several internal nets. Most failures are going to manifest
themselves as incorrect output given a well designed input pattern, thereby
not requiring each component in the filter to be tested individually. This
is also a good case where using the micro as part of the test process is
probably useful. You can use the micro's own PWM generator to produce the
test signals for the LPF.
Just because I said you don't always need to test every net, you are
arguing against my statement because sometimes you do have to test some
nets. That is a logical fallacy since it doesn't counter my statement at
all.
Quote:
OTOH - I can drop ICT test points around my op-amp and the passive
components. Using the JTAG on the micro I can wiggle that port pin and
watch the effects on the nets connected to it. I can also directly
measure the resistors, capacitors, and inductors values and confirm
I've
loaded the right components and that indeed they did get soldered to
the
board. If my board isn't super tight, this cost me exactly nothing.
That is wrong. Of course it costs something. Testing every net in the
filter causes high cost in the tester, engineering time to design and debug
the test procedure, and incremental production time to perform the test.
The first two are fixed costs and amortized over all units. If your
volumes are high, the cost may be low per unit, but certainly not free.
The third is incremental cost per unit, and adds directly to the production
cost. Production time is not free.
So now let me explain some logic because you seem to have a problem in that
area. I can forsee you countering this with "but my volumes are so high,
and the cost of sending bad LPFs out there is much more than the extra
production time", or some such irrelevant statement. The paragraph is a
rebuttal to your silly statement that what you describe "cost you exactly
nothing", not that the LPF can't or shouldn't be tested, or whatever. I
have shown three ways the cost is more than zero, thereby disproving your
assertion. If you want to rebut, you need to show how all three points are
invalid.
Quote:
I understand completely the approach you propose.
Clearly not, since I haven't proposed anything. I have only provided
counter examples to your claim that you need access to all nets.
Quote:
I've used it. It
works well in some cases. But it can easily require you to bump into a
higher pin count microcontroller or start dropping analog muxes or
digital gates on your design. I'm not prepared to expend recurring
costs like that.
Of course. Looping signals back to the micro to facilitate testing isn't
always the optimum tradeoff, and I never said it was. I'm not the one who
thinks one plan (bringing out all nets to a tester) is the right approach
for all boards. In cases where you have unused pins on the micro, using
them for testing is something to consider.
Quote:
Yes, the sometimes the smallest micros don't do JTAG. But, since JTAG
has become the de facto standard for connecting a debugger to a
microcontroller it's pretty rare.
Then you're not up on what microcontroller products there are. Some do
have JTAG, but many many, in fact the majority don't, especially when you
look at units shipped. Take the leading microcontroller supplier,
Microchip, for example. How many PICs have JTAG? None of the 10, 12, and
16 family I think. Maybe some large 18s do, but most don't. Some of the
16 bitters, particularly in the larger packages do, like the 24, 30, and 33
families, but many also don't. It may be that most of the 32 family do.
In any case, the point is that many many digital parts, including the vast
majority of microcontrollers, don't support JTAG. JTAG can be useful when
present, but you can't claim a universal test strategy that relies on JTAG
always being there because it isn't.
Quote:
JTAG + ICT is a very powerful way to insure that your boards are
properly loaded and soldered.
Of course JTAG can be useful and appropriate for testing some designs, but
the point is ...?
Quote:
Almost certainly not unless field
reliability is
very very important and doubling the cost makes it worth it.
In my (and many other products) it is worth it.
OK, sometimes it is worth it (as I said), but again, your point is ...?
Quote:
Besides, a properly
implemented JTAG + ICT test procedure cost little to implement on the
product and it is much cheaper than doing any hands-on functional
testing.
Which would actually be relevant if I had somehow proposed the only
alternative to testing every single net is to do manual hands-on testing.
Quote:
Sure, no absolutes. But if all I was worried about was untested bypass
caps I wouldn't even think about ICT or JTAG.
Because I mentioned a hard to test case (bypass caps), this was somehow
taken to be a argument against JTAG or any other in-circuit testing!!?
Quote:
You could also
have the micro produce a known pattern on that pin and check for
the
expected result elswhere, perhaps even at output of the whole
board.
Sometimes with a little cleverness, it's not hard to verify most of
the
in-between components if the micro wiggles it's pin the right way
and you
analyse the output signal the right way.
Agree or not, it's very common. How would you propose to test such a
situation without adding additional cost to the product?
You could have the micro produce a known pattern on that pin and check for
the expected result elsewhere, perhaps even at output of the whole board.
Quote:
Ah, but with ICT test points its not a black box block. I can drop
test
points on "internal" nets and check them as well. I can even measure
R,
C, and L values and see if someone loaded the wrong reel on the pick
and
place machine (it does happen).
Being able to test all internal nets doesn't mean it couldn't be tested
effectively enough as a black box.
(now before you go off and knee jerk with a orthagonal argument, note that
this doesn't say all subsystems can be tested as black boxes, or that they
always should be if they can, only that it is possible and sometimes
appropriate and effective to do so, and that therefore there are
alternatives to always testing every net)
Quote:
For example, consider a switching power supply producing 3.3V from
10-30
volts in. That's hardly a far fetched case. The tester can often
verify
the power supply to acceptable confidence by varying the input
voltage and
measuring its current, and measuring the output voltage and being
able to
switch some additional loads onto it perhaps. If everything is
right with
a few test cases, you know the inductor, switch, catch diode,
feedback, and
control circuit are all working correctly without having to look at
the
various internal nets of the power supply.
If I have a switching power supply on my design (which I do) and the
output voltage doesn't leave the board, I've either got to drop some
ICT
test points on the board and measure the supply voltage at ICT, drop
test points on the board and have a human measure it by hand with a
voltmeter ($$$) or rely on your self testing scheme.
This reinforces my pointer very well. You don't need access to the power
supply's internal nets to be able to test it to acceptable confidence in
many cases.
Quote:
In fact, I think your
example is a fine demonstration of why you might need ICT.
Right, but since nobody was saying you should leave your board untested or
do it by hand or something, I don't see what your point is.
--
Web access to CadSoft support forums at www.eaglecentral.ca. Where the CadSoft EAGLE community meets.
On 12/30/2010 8:08 AM, Olin Lathrop wrote:
Wow, that was a amazing bit of sideways logic. I was reacting to your
rediculous assertion that you always need to give a tester access to all
nets. It only takes a single counter example to disprove that, and I
supplied several such counter examples.
Your response is to act as if I said you are always limited to doing things
as in the counter examples, which is completely illogical.
Of course there are many methods to test a board. The point is that you
don't always need to have access to every net, not that you should never
have access to any net.
Sorry, been traveling for some time, back in the office now.
If I used sideways logic then you are just as guilty of it. I gave you
several counter examples where your methodology would not work and
several points on how your way can in some cases cause you to spend
recurring costs on the BOM, yet you choose to ignore those as well. So,
perhaps we are both guilty of sideways logic.
I have never claimed that I want access to every net on a board in all
cases. Sometimes I might (particularly if it's a board with no
microcontroller or reprogrammable logic, which I certainly admit is
rather rare). In fact, in general I want to use a combination of
methodologies to do automated testing of boards. Ideally, I'd use JTAG,
ICT test points, and yes your method as well where appropriate
(meaning where possible and where it does not incur recurring BOM cost).
A mix of methods will give me the most thorough and cost effective
means to test a populated board.
In summary I still propose that CadSoft should consider a means to add
test points during layout without adding them explicitly to the
schematic, (much like the way we add vias). This is supported in many
of the major CAD systems that Eagle competes with and follows the
methodology and division of labor used by many enterprises.
