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
On 12/28/2010 10:25 AM, Michael Sansom wrote:
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.
After a few more minutes of consideration, I don't see why Eagle
couldn't treat testpoints exactly the way they currently treat plated
holes. For instance, on the board I am currently working on, I have
four plated thru mounting hole. These holes are electrically tied to a
net (GND), and yet they appear nowhere on my schematic. They were added
during the PCB layout process and have nothing to do with the schematic.
Like testpoints, they are single port elements, i.e. they make one and
only one connection to a single net, so they do not interfere with the
functionality established by the schematic.
Clearly, Eagle already has a mechanism for handling single port elements
that are added to the PCB manually but not to the schematic. A
testpoint would simply be a similar element that consisted of a single
non-drilled pad.
Michael Sansom schrieb:
After a few more minutes of consideration, I don't see why Eagle
couldn't treat testpoints exactly the way they currently treat plated
holes. For instance, on the board I am currently working on, I have
four plated thru mounting hole. These holes are electrically tied to a
net (GND), and yet they appear nowhere on my schematic. They were added
during the PCB layout process and have nothing to do with the schematic.
Did you check if the files are still consistent?
Like testpoints, they are single port elements, i.e. they make one and
only one connection to a single net, so they do not interfere with the
functionality established by the schematic.
Clearly, Eagle already has a mechanism for handling single port elements
that are added to the PCB manually but not to the schematic. A
testpoint would simply be a similar element that consisted of a single
non-drilled pad.
I don't think that Eagle already has such a mechanism. For every
connected pad in the board, you need a pin in the schematic (more or
less visible, Warren already provided an example). And your ICTPs need
pads (normally small round SMDs on one of the outer layers), hence they
need pins in the schematic for a consistent connection.
BTW, it's good to see the testpoints in the schematic, too - and the
schematic designer can easily add them to all nets that shall be
accessible later (and leave the other nets without). Then, the
testpoints can also easily be considered during board layout and you
don't need a third person to add just the testpoints - without detailed
knowledge of the schematic and some layout details, this is somewhat
risky anyway.
Tilmann
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/29/2010 2:22 AM, Tilmann Reh wrote:
Michael Sansom schrieb:
>> After a few more minutes of consideration, I don't see why Eagle
>> couldn't treat testpoints exactly the way they currently treat plated
>> holes. For instance, on the board I am currently working on, I have
>> four plated thru mounting hole. These holes are electrically tied to a
>> net (GND), and yet they appear nowhere on my schematic. They were added
>> during the PCB layout process and have nothing to do with the schematic.
Did you check if the files are still consistent?
Yes, the files are still consistent. Why would they not be? Is this
not the way the add hole function works. It seems to work just like the
add via function as far as I can tell.
>> Like testpoints, they are single port elements, i.e. they make one and
>> only one connection to a single net, so they do not interfere with the
>> functionality established by the schematic.
>>
>> Clearly, Eagle already has a mechanism for handling single port elements
>> that are added to the PCB manually but not to the schematic. A
>> testpoint would simply be a similar element that consisted of a single
>> non-drilled pad.
I don't think that Eagle already has such a mechanism. For every
connected pad in the board, you need a pin in the schematic (more or
less visible, Warren already provided an example). And your ICTPs need
pads (normally small round SMDs on one of the outer layers), hence they
need pins in the schematic for a consistent connection.
Indeed Eagle must have such a mechanism. Do you have schematic elements
for all the vias on your PCB? What exactly is the difference between a
via and a test point from a schematic/layout consistency standpoint? An
ICT test point is simply a via without a drill through it.
BTW, it's good to see the testpoints in the schematic, too - and the
schematic designer can easily add them to all nets that shall be
accessible later (and leave the other nets without). Then, the
testpoints can also easily be considered during board layout and you
don't need a third person to add just the testpoints - without detailed
knowledge of the schematic and some layout details, this is somewhat
risky anyway.
Tilmann
You are telling me how you think adding test points should work. I'm
telling you how it does work in the vast majority of companies that I've
ever seen. I can say that fairly confidently based on the number of
companies that I have worked for as a hardware designer, and the far
greater number of schematics from different companies I have looked
at. It is very rare for the engineer to place test points on his
schematic for ICT testing (remember, for ICT ideally you want 100% of
nets to have test points). Generally, engineers will place test points
at signals of interest that he wants to probe with a scope or other
instrumentation for debug. Generally this will be a small fraction of
the total net count.
At all but the very smallest companies I've worked with, adding test
points for ICT is a post processing operation, in fact it's often not
done until the second or third prototype layout. As the layout
progresses, it is up to the hardware designer to look at high speed nets
to ensure that adding test points have not created any issues. In many
schematic capture/layout flows the hardware engineering will add some
sort of "no_test_point" attribute to critical high speed nets to inform
the pcb designer to not insert test points.
Do you really add test point components to all the nets on your schematic?
On 12/29/2010 6:40 AM, Olin Lathrop wrote:
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.
Once again, you guys are telling me how you think the Schematic
Capture/PCB Layout flow should work. I'm telling you how it does
work based on the large number of companies I have worked for or
interfaced with. Not surprisingly, the work flow you propose meshes
well with what your tools support. But that is putting the cart before
the horse. You're asking the world to conform to your concept of the
work flow. I think you're putting blinders on yourself.
In fact, there are excellent reasons to have the hardware designer
capturing the schematic and the PCB designer doing the layout to be
different people. The required skill sets are not the same. A
hardware designer needs to understand how to cost effectively implement
some desired function in hardware. The PCB designer needs to understand
the intricacies of PCB fabrication and the automated PCB assembly
process (i.e. board loading, wave & reflow soldering, etc.). The PCB
designer needs to be able to optimize the layout for best PCB yield and
lowest assembly costs. In all but the simplest hardware/PCB designs the
best way to optimize these two functions it to get two people who are
highly skilled in their respective fields. It is much harder to find
people that are truly expert in hardware design, PCB fabrication, and
manufacturing. Besides that, having a separate hardware and PCB
designer will normally get the work done faster. If I lay out a PCB
every couple of months, my layout skills will not be as good as
someone who lays out PCBs every day. He will be both faster and
better than me at laying out PCBs.
Now, of course the hardware designer should occasionally look over the
shoulder of the PCB designer to be aware of what he is doing and he
definitely should inspect and approve the final layout.
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.
Simply not true. How will you determine if a microcontroller's pins are
soldered to the PCB if you don't have an in-circuit test point.
Normally, the way that is tested is you will connect the microcontroller
and any other JTAG compliant devices to a JTAG scan chain. Signals that
route between two JTAG capable devices can indeed be checked without a
test point. But what about signals that don't terminate on another JTAG
device? Say a signal originating on a microcontroller port pin that
ultimately connects to some analog circuit. How are you going to test
connectivity without a test point? Normally you would use the JTAG port
to command the port pin to go high and low then use your ICT tester to
observe the result.
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.
Maybe you don't want to do that, but I and many other companies do
exactly that, except we don't do it blindly. On signals that are low
speed, you can pretty much put a test point wherever you want. However,
I agree that on high speed signals you either want to place the test
point at a specific place or skip the test point altogether. The former
is done by having the hardware designer communication with the PCB
designer (either verbally or through notes on the schematic). The
latter is typically done by putting a "no_test_point" (or something
similar) attribute on the critical nets.
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.
I do drop test points on the schematic on specific nets that I want to
make sure are covered so that I insure it is there and also get a
schematic reference designator. On the other hand, if I want to look at
a test point that is intended for ICT, I pull up the Gerber files or the
layout board files and find the ICT test point on the layout. It's not
that hard.
The work flow I've just described is the way a great many of medium
sized and larger companies do things. I agree, it's not the way a one
or two man shop may work. But even then, I've run small companies and
about half the time I hired a PCB designer as a subcontractor so even in
the case of a very small company (four people in this case) the
schematic capture and pcb layout functions were split. And I've seen
very very few schematic after 25 years as a hardware designer that had
all the ICT test points on the schematic (it just makes a mess if you've
got a complex schematic). I don't doubt that some people do this, but
it is rare in my experience (yours may vary). I've worked at
companies varying in size from ~2000 employees to 3 employees so far.
On 12/29/2010 6:40 AM, Olin Lathrop wrote:
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.
Once again, you guys are telling me how you think the Schematic
Capture/PCB Layout flow should work. I'm telling you how it does
work based on the large number of companies I have worked for or
interfaced with. Not surprisingly, the work flow you propose meshes
well with what your tools support. But that is putting the cart before
the horse. You're asking the world to conform to your concept of the
work flow. I think you're putting blinders on yourself.
In fact, there are excellent reasons to have the hardware designer
capturing the schematic and the PCB designer doing the layout to be
different people. The required skill sets are not the same. A
hardware designer needs to understand how to cost effectively implement
some desired function in hardware. The PCB designer needs to understand
the intricacies of PCB fabrication and the automated PCB assembly
process (i.e. board loading, wave & reflow soldering, etc.). The PCB
designer needs to be able to optimize the layout for best PCB yield and
lowest assembly costs. In all but the simplest hardware/PCB designs the
best way to optimize these two functions it to get two people who are
highly skilled in their respective fields. It is much harder to find
people that are truly expert in hardware design, PCB fabrication, and
manufacturing. Besides that, having a separate hardware and PCB
designer will normally get the work done faster. If I lay out a PCB
every couple of months, my layout skills will not be as good as
someone who lays out PCBs every day. He will be both faster and
better than me at laying out PCBs.
Now, of course the hardware designer should occasionally look over the
shoulder of the PCB designer to be aware of what he is doing and he
definitely should inspect and approve the final layout.
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.
Simply not true. How will you determine if a microcontroller's pins are
soldered to the PCB if you don't have an in-circuit test point.
Normally, the way that is tested is you will connect the microcontroller
and any other JTAG compliant devices to a JTAG scan chain. Signals that
route between two JTAG capable devices can indeed be checked without a
test point. But what about signals that don't terminate on another JTAG
device? Say a signal originating on a microcontroller port pin that
ultimately connects to some analog circuit. How are you going to test
connectivity without a test point? Normally you would use the JTAG port
to command the port pin to go high and low then use your ICT tester to
observe the result.
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.
Maybe you don't want to do that, but I and many other companies do
exactly that, except we don't do it blindly. On signals that are low
speed, you can pretty much put a test point wherever you want. However,
I agree that on high speed signals you either want to place the test
point at a specific place or skip the test point altogether. The former
is done by having the hardware designer communication with the PCB
designer (either verbally or through notes on the schematic). The
latter is typically done by putting a "no_test_point" (or something
similar) attribute on the critical nets.
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.
I do drop test points on the schematic on specific nets that I want to
make sure are covered so that I insure it is there and also get a
schematic reference designator. On the other hand, if I want to look at
a test point that is intended for ICT, I pull up the Gerber files or the
layout board files and find the ICT test point on the layout. It's not
that hard.
The work flow I've just described is the way a great many of medium
sized and larger companies do things. I agree, it's not the way a one
or two man shop may work. But even then, I've run small companies and
about half the time I hired a PCB designer as a subcontractor so even in
the case of a very small company (four people in this case) the
schematic capture and pcb layout functions were split. And I've seen
very very few schematic after 25 years as a hardware designer that had
all the ICT test points on the schematic (it just makes a mess if you've
got a complex schematic). I don't doubt that some people do this, but
it is rare in my experience (yours may vary). I've worked at
companies varying in size from ~2000 employees to 3 employees so far.
Michael Sansom wrote on Wed, 29 December 2010 11:44
You're asking the world to conform to your concept of the
work flow.
Actually you're the one asking for a change. Most here seem to be OK with
how Eagle handles this. Your request seems a bit silly.
Quote:
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.
Simply not true.
That's a bold statement, considering I've done exactly what I describe
above a number of times. Did you actually read what I wrote? Note the
part about the tester communicating with the on-board processor.
Quote:
How will you determine if a microcontroller's pins are
soldered to the PCB if you don't have an in-circuit test point.
As I already said, and you apparently missed, the tester communicates with
the micro. This doesn't work in all cases, of course, but is quite useful
when a communications port from the micro is already brought out, or you
can easily run the UART lines, for example, to test points. You can also
run a few unused pins to test points and create any kind of bit banged
communication interface you want.
Put another way, the on-board processor becomes part of the tester
temporarily during test. It's often in the ideal position to exercise
surrounding hardware and measure the result. Sometimes you feed back
signals into otherwise unused pins just for this purpose.
So if a processor pin connection is open, something will fail. If its a
communication pin, communication to the tester controller will fail. If
its a different pin, the processor won't measure something as expected or
the rest of the circuit won't produce something as expected.
This doesn't work for all nets, of course, but it can greatly cut down on
what the tester has to connect to and test itself.
Quote:
Normally, the way that is tested is you will connect the
microcontroller
and any other JTAG compliant devices to a JTAG scan chain.
Sometimes. Lots of micros don't have JTAG though. JTAG eats up a rather
large number of pins, so generally only large micros have JTAG.
Quote:
But what about signals that don't terminate on another JTAG
device?
There's a bigger world than JTAG out there. All you need is to somehow
detect something changes in a way that is very unlikely to happen other
than by the intended method working properly.
There are no absolutes. Everything is a probability game, even with JTAG.
To catch lower and lower probability failures requires ever increasing
complexity and effort. At some point you make the decision it's not worth
persuing the remaining possible failures. If you're going to produce
10,000 units each costing $100 to produce, how much is it worth to catch a
1:1,000,000 failure? Certainly at least $1/unit, but what about $10/unit?
Probably not. $100/unit? Almost certainly not unless field reliability is
very very important and doubling the cost makes it worth it.
For example, let's say you have a anlog input that goes thru some filters
and then into a A/D input of the on-board micro. You probably don't need
to probe every net in the filters. Many, if not all, of the filter
circuitry can be verified by driving the board input with certain signals
and having the micro report what it sees, or even having code in the micro
that analyses the pattern and reports good/bad directly.
And then there are some parts that are really hard to test for even if you
have access to all the signals. For example, what if a bypass cap
somewhere wasn't soldered right and one side was actually open. The other
bypass caps and bulk capacitance mask the single open cap when the power
net is probed as a whole, even if you do try to measure the capacitance on
the line (which is rarely done). You'd need circuitry in the tester
something like a transmission line analyser and a test point very close to
the cap to be able to detect this. Do you do this on every board for every
bypass cap. I didn't think so. No matter how sophisticated (and therefore
expesive) you make the tester, there will always be some failures it can't
detect. As I said, it's a probability game. There are no absolutes.
Quote:
Say a signal originating on a microcontroller port pin that
ultimately connects to some analog circuit. How are you going to test
connectivity without a test point? Normally you would use the JTAG port
to command the port pin to go high and low then use your ICT tester to
observe the result.
I don't agree that's the "normal" way, but it's one way. 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.
What makes sense has a lot to do with the specifics of that one design, how
much it costs, what the cost of a failure is, how many you intend to
produce, etc, etc, etc.
Quote:
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.
Maybe you don't want to do that, but I and many other companies do
exactly that, except we don't do it blindly. On signals that are low
speed, you can pretty much put a test point wherever you want.
However,
I agree that on high speed signals you either want to place the test
point at a specific place or skip the test point altogether.
I wasn't referring to delicate signals by "blindly" but rather that every
single net needs to be tested. I haven't seen a design yet where that
makes sense. In your system there is absolutely no way to infer the
correct operation of some block by seeing the correct outputs given some
specific inputs? That would be a first.
Actually, if you think about it you're already doing that anyway. Chips
are laregly black boxes with many internal nets. You don't need to, and
certainly wouldn't want to look at the state of every one of those internal
nets. You give the chip some specific inputs and verify that the outputs
are as expected.
You can consider your board the same way. You usually don't need to see
every internal signal if the right output is produced from a specific set
of well chosen inputs.
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.
--
Web access to CadSoft support forums at www.eaglecentral.ca. Where the CadSoft EAGLE community meets.
On 12/29/2010 5:32 PM, Olin Lathrop wrote:
Michael Sansom wrote on Wed, 29 December 2010 11:44
>> You're asking the world to conform to your concept of the work flow.
Actually you're the one asking for a change. Most here seem to be OK with
how Eagle handles this. Your request seems a bit silly.
Sounds like the start of a pissing match to me. Ok, I'm game. 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.
Quote:
>> > 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.
>>
>> Simply not true.
That's a bold statement, considering I've done exactly what I describe
above a number of times. Did you actually read what I wrote? Note the
part about the tester communicating with the on-board processor.
Quote:
>> How will you determine if a microcontroller's pins are soldered to the
>> PCB if you don't have an in-circuit test point.
As I already said, and you apparently missed, the tester communicates with
the micro. This doesn't work in all cases, of course, but is quite useful
when a communications port from the micro is already brought out, or you
can easily run the UART lines, for example, to test points. You can also
run a few unused pins to test points and create any kind of bit banged
communication interface you want.
Put another way, the on-board processor becomes part of the tester
temporarily during test. It's often in the ideal position to exercise
surrounding hardware and measure the result. Sometimes you feed back
signals into otherwise unused pins just for this purpose.
So if a processor pin connection is open, something will fail. If its a
communication pin, communication to the tester controller will fail. If
its a different pin, the processor won't measure something as expected or
the rest of the circuit won't produce something as expected.
This doesn't work for all nets, of course, but it can greatly cut down on
what the tester has to connect to and test itself.
Did you read what I wrote. I allowed that you can test connectivity
between two JTAG devices if you implement a scan chain (which I do).
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?
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.
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.
Test points are free (as long as you are not area constrained, besides I
put my test points on the bottom). All I have to do is pay to build the
ICT fixture but I'm building thousands per month so I'd much rather
pay for a single one time up front cost.
I understand completely the approach you propose. 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.
Quote:
>> Normally, the way that is tested is you will connect the
>> microcontroller and any other JTAG compliant devices to a JTAG scan
>> chain.
Sometimes. Lots of micros don't have JTAG though. JTAG eats up a rather
large number of pins, so generally only large micros have JTAG.
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.
JTAG is five pins. However, in general most of those five pins are
available for other uses on microcontrollers when not in test mode. It
can place some additional constraints on how you use those pins, but I
don't usually find that burdensome.
Quote:
>> But what about signals that don't terminate on another JTAG device?
There's a bigger world than JTAG out there. All you need is to somehow
detect something changes in a way that is very unlikely to happen other
than by the intended method working properly.
JTAG + ICT is a very powerful way to insure that your boards are
properly loaded and soldered. If you are building very uncomplicated
designs then perhaps it isn't needed, but I don't think you can just
ignore it. It is used quite a bit in the industry.
There are no absolutes. Everything is a probability game, even with
JTAG. To catch lower and lower probability failures requires ever
increasing
complexity and effort. At some point you make the decision it's not worth
persuing the remaining possible failures. If you're going to produce
10,000 units each costing $100 to produce, how much is it worth to catch a
1:1,000,000 failure? Certainly at least $1/unit, but what about
$10/unit? Probably not. $100/unit? 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. 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. If your product is such that you can essentially ship it
without doing any testing then great, you don't need it. I'm not in
that camp. For me, a combination of JTAG + ICT actually makes my
product cheaper to produce. That's kinda the whole point.
And then there are some parts that are really hard to test for even if you
have access to all the signals. For example, what if a bypass cap
somewhere wasn't soldered right and one side was actually open. The other
bypass caps and bulk capacitance mask the single open cap when the power
net is probed as a whole, even if you do try to measure the capacitance on
the line (which is rarely done). You'd need circuitry in the tester
something like a transmission line analyser and a test point very close to
the cap to be able to detect this. Do you do this on every board for every
bypass cap. I didn't think so. No matter how sophisticated (and therefore
expesive) you make the tester, there will always be some failures it can't
detect. As I said, it's a probability game. There are no absolutes.
Sure, no absolutes. But if all I was worried about was untested bypass
caps I wouldn't even think about ICT or JTAG.
Quote:
>> Say a signal originating on a microcontroller port pin that ultimately
>> connects to some analog circuit. How are you going to test
>> connectivity without a test point? Normally you would use the JTAG port
>> to command the port pin to go high and low then use your ICT tester to
>> observe the result.
I don't agree that's the "normal" way, but it's one way. 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? The port
pins on my micro are full. Am I going to pay more to drop a higher pin
count part on the board so I can test it your way?
I wasn't referring to delicate signals by "blindly" but rather that every
single net needs to be tested. I haven't seen a design yet where that
makes sense. In your system there is absolutely no way to infer the
correct operation of some block by seeing the correct outputs given some
specific inputs? That would be a first.
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).
Actually, if you think about it you're already doing that anyway. Chips
are laregly black boxes with many internal nets. You don't need to, and
certainly wouldn't want to look at the state of every one of those internal
nets. You give the chip some specific inputs and verify that the outputs
are as expected.
The silicon vendor has already tested that black box. Unless I damage
it it should be good. I do however need to verify that it got soldered
on the board properly. You'll get no argument from me that you can't
test everything, but if your only plan is to test components on your
board by essentially feeding signals back around to your micro you'll
have fairly poor coverage unless your designs are small. Mine aren't.
You can consider your board the same way. You usually don't need to see
every internal signal if the right output is produced from a specific set
of well chosen inputs.
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. The problem is,
your micro will run just fine if the supply voltage is +2.7V or +4.0V.
In fact, it will run just fine (for a while) if the supply voltage on
the micro is 20% higher than the absolute maximum on the micro (but of
course service life will be compromised). To make that scenario happen
all I've got to do is misload one resistor in the switcher's feedback
loop. Frankly, I'd like to catch that at ICT. In fact, I think your
example is a fine demonstration of why you might need ICT.
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.
