Testpoints for ICT testers

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.

I'm very interested about how that works - can you provide a valid (and

DRC-correct) sample of a consistent sch/brd pair?

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.

A hole is just a hole - no electrical connection. So you can simply add

it to the board, without any conflicts with the schematic (as with any

mechanical part).

A via is always related to a drill in it. So while you can simply drop

it where you like to, and attach it to any net you want, it will always

add a drill at that position, and some pad shape in at least one more

signal layer (most often, in all layers).

ICTPs normally are small SMD pads, on one (outer) layer only, without

drill. I don't know of a way to add single pads to a board only and

connect them to a signal without loosing consistency (as with any

package that contains connected pads).

So, if you provide a sample of what you have described above, we might

be able to understand better.

(The only way I can think of that fits your description, is to manually

add the hole, filled circles in (at least) the outer copper layers, and

filled circles in both stop mask layers. For the electrical connection

to a signal, the copper circles could be drawn as two arcs each, or the

DRC complaint of an overlapping ground connection must be ignored. But

you probably don't like to do this on hundreds of testpoints...)

Maybe I didn't notice a new feature of the current version?

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.

That's not a problem for me - please do it your way. Obviously, our

experience is different here.

Do you really add test point components to all the nets on your schematic?

Yes, if the customer wants me to (BTDT - not a big deal).

No, otherwise, since we don't use ICT inhouse.

Tilmann

On 12/29/2010 11:12 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.

 

I'm very interested about how that works - can you provide a valid (and

DRC-correct) sample of a consistent sch/brd pair?

It is very easy but I slightly misled you (unintentionally).  For the

mounting holes, I simply dropped vias (a really big via as you can

imagine).  I confused myself as I mis-remembered using the hole function

rather than the via function.  So, in my example, I dropped a via at a

certain x,y coordinate then set the drill size (4.8 mm in my example)

and then set the inner and outer layer dimensions appropriately to give

a topside annual ring sized slightly larger than the sheet metal screw

head size than I am using.  Using the NAME function I then tied it to

the desired net (in this case GND) and the "via" makes a perfectly

serviceable electrically connected mounting hole. Almost certainly

someone on this usenet group told me to use this method for mounting

holes.

>> 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.

 

A hole is just a hole - no electrical connection. So you can simply add

it to the board, without any conflicts with the schematic (as with any

mechanical part).

Agreed.  See above.  I mis-remembered using the Hole function and

instead had used the Via function.  To be honest when I start a new

layout I usually start with an old layout that had the mounting holes

dropped on it some time back, so it has been awhile since I've had to

drop new mounting holes on a layout.  Normally I just resize, move and

copy the holes on my standard starting layout as needed.

A via is always related to a drill in it. So while you can simply drop

it where you like to, and attach it to any net you want, it will always

add a drill at that position, and some pad shape in at least one more

signal layer (most often, in all layers).

Yes, agreed a via has a drill associated with it.  However, my point is

that Eagle already has a mechanism in place to for the PCB layout tool

to place a "single port" PCB component manually without causing any

consistency issues between the layout and the schematic.  We do it all

the time when we drop vias which of course are not represented on the

schematic (what a nightmare that would be!).

ICTPs normally are small SMD pads, on one (outer) layer only, without

drill. I don't know of a way to add single pads to a board only and

connect them to a signal without loosing consistency (as with any

package that contains connected pads).

Yes, we agree on what a ICTP is.  However, one would think that what

CadSoft already has in place to handle vias could be readily modified to

create an "add testpoint" button and command which would use perhaps 90%

of the code they have currently to handle vias.  A test point really is

just a one sided via with no drill.

So, if you provide a sample of what you have described above, we might

be able to understand better.

See above.

(The only way I can think of that fits your description, is to manually

add the hole, filled circles in (at least) the outer copper layers, and

filled circles in both stop mask layers. For the electrical connection

to a signal, the copper circles could be drawn as two arcs each, or the

DRC complaint of an overlapping ground connection must be ignored. But

you probably don't like to do this on hundreds of testpoints...)

 

Maybe I didn't notice a new feature of the current version?

No, my fault for the confusion.

>> 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.

 

That's not a problem for me - please do it your way. Obviously, our

experience is different here.

 

>> Do you really add test point components to all the nets on your schematic?

 

Yes, if the customer wants me to (BTDT - not a big deal).

No, otherwise, since we don't use ICT inhouse.

That's probably the root of our difference of opinion on how test points

should be handled.  I have worked at several places where ICT testing

was emphasized, at one place for reliability/quality reasons, at others

for cost reduction reasons (i.e. to minimize the amount of hands-on

functional testing at the end of the manufacturing process.  At my small

company it is the latter reason driving my interest.

Regards,

-Michael

BTW, to give you a bit more information on the work flow I've used in

the past, normally what we do is take the netlist (without ICTPs) and

the BSDL files for all of the JTAG compliant components in the design.

This is then fed into a separate piece of software that looks at the

connectivity in the netlist and the BSDL files and figures out which

nets can be tested with the JTAG scan chain and which can not.  It then

outputs a list of nets that cannot be tested with JTAG and the PCB

designer brings in this list which then places airwire connected test

points for all of the nets not tested with JTAG (unless the net has a

NO_TEST_POINT attribute).  The PCB designer then only has to place these

ICTPs appropriately on the layout and hook them up.

You can readily see that given such a list of JTAG untestable nets, the

appropriate "add testpoint" command in Eagle and the right ULP you could

do exactly the same thing with Eagle.

In fact, if you were really motivated, Eagle's ULP capability would

probably allow you to read the BSDL files directly and let it figure out

itself which nets can be tested via JTAG and which can not, thus

eliminating the need for the external program (which cost several

thousand dollars if I recall correctly).

-Michael

Michael Sansom schrieb:

Yes, agreed a via has a drill associated with it.  However, my point is

that Eagle already has a mechanism in place to for the PCB layout tool

to place a "single port" PCB component manually without causing any

consistency issues between the layout and the schematic.  We do it all

the time when we drop vias which of course are not represented on the

schematic (what a nightmare that would be!).

I think that for EAGLE, vias are /not/ a "single port" component, at

least not intentionally. Currently, vias are just a "vertical segment"

of a track.

Yes, we agree on what a ICTP is.  However, one would think that what

CadSoft already has in place to handle vias could be readily modified to

create an "add testpoint" button and command which would use perhaps 90%

of the code they have currently to handle vias.  A test point really is

just a one sided via with no drill.

I can't tell if it's really a simple modification/addition to the

existing code. Maybe it is - in that case I wouldn't mind if CadSoft

adds this function. (If it's more work, I wouldn't mind either - it's

just that I don't need ICTPs too often. )

>>> Do you really add test point components to all the nets on your schematic?

>>

>> Yes, if the customer wants me to (BTDT - not a big deal).

>> No, otherwise, since we don't use ICT inhouse.

 

That's probably the root of our difference of opinion on how test points

should be handled.  I have worked at several places where ICT testing

was emphasized, at one place for reliability/quality reasons, at others

for cost reduction reasons (i.e. to minimize the amount of hands-on

functional testing at the end of the manufacturing process.  At my small

company it is the latter reason driving my interest.

We already have done designs for customers that wanted/needed every net

on ICTPs for their production tests. As said, it's not a big deal even

if they are visible in the schematic. Maybe this is also related to the

complexity of a board - in our cases, they were not too big. Of course,

these testpoints have to be added in the schematic then, you can't

simply add them later in the board alone.

The cost structure for post-manufacturing test heavily depends on

production volumes - for our rather small quantities, automated ICT

equipment would never calculate. So obviously we are working on

different targets.

Tilmann

"Tilmann Reh" wrote in response

I think that for EAGLE, vias are /not/ a "single port" component, at

least not intentionally. Currently, vias are just a "vertical segment"

of a track.

 

.................

Of course,

these testpoints have to be added in the schematic then, you can't

simply add them later in the board alone.

.............

The issue I see with the simple "SMD-via" approach is identifying this

copper so that a netlist  can show the net does have an ICTP or which point

of many possible (vias or pads or special) is the ICTP

Vias are used as ICTP but  not all of them on a net so at some point the

coords of the ICT-via and its associated net needs to be output. An Eagle

device can get this right with an 'Attribute' but a via cannot do that.

The link I have just referenced in the eagle.suggested.eng

http://www.orcad.com/forums/ShowPost.aspx?PostID=20085 shows competitive

software can assign the test point tag to a via and even a pad stack  It

looks like that can be done separately to the library, in the layout editor

and it looks like this is a Pin attribute set on the board.  Such

granularity  would enable the ICTP/ xy /netlist output to be generated most

easily from the board.

From the article it appears to be useful to 'Lock' the designated via ICTP

which Eagle cannot do currently.

Another consideration is ICTP spacing so potentially the DRC may need an

addition.

E&OE

Warren

On 12/29/2010 2:33 PM, Tilmann Reh wrote:

Michael Sansom schrieb:

 

>> Yes, agreed a via has a drill associated with it.  However, my point is

>> that Eagle already has a mechanism in place to for the PCB layout tool

>> to place a "single port" PCB component manually without causing any

>> consistency issues between the layout and the schematic.  We do it all

>> the time when we drop vias which of course are not represented on the

>> schematic (what a nightmare that would be!).

 

I think that for EAGLE, vias are /not/ a "single port" component, at

least not intentionally. Currently, vias are just a "vertical segment"

of a track.

Perhaps not.  But, from an electrical network point of view, they are

single port elements in that they connect to one and only one net.

However they may be implemented by Eagle internally, I still believe

that they would lend themselves to being made into test points without a

great deal of development.

>> Yes, we agree on what a ICTP is.  However, one would think that what

>> CadSoft already has in place to handle vias could be readily modified to

>> create an "add testpoint" button and command which would use perhaps 90%

>> of the code they have currently to handle vias.  A test point really is

>> just a one sided via with no drill.

 

I can't tell if it's really a simple modification/addition to the

existing code. Maybe it is - in that case I wouldn't mind if CadSoft

adds this function. (If it's more work, I wouldn't mind either - it's

just that I don't need ICTPs too often. )

Yes, the degree of difficulty is pure speculation on my part.  Only

CadSoft's developers know now hard or easy this task would be.

>>>> Do you really add test point components to all the nets on your schematic?

>>>

>>> Yes, if the customer wants me to (BTDT - not a big deal).

>>> No, otherwise, since we don't use ICT inhouse.

>>

>> That's probably the root of our difference of opinion on how test points

>> should be handled.  I have worked at several places where ICT testing

>> was emphasized, at one place for reliability/quality reasons, at others

>> for cost reduction reasons (i.e. to minimize the amount of hands-on

>> functional testing at the end of the manufacturing process.  At my small

>> company it is the latter reason driving my interest.

 

We already have done designs for customers that wanted/needed every net

on ICTPs for their production tests. As said, it's not a big deal even

if they are visible in the schematic. Maybe this is also related to the

complexity of a board - in our cases, they were not too big. Of course,

these testpoints have to be added in the schematic then, you can't

simply add them later in the board alone.

 

The cost structure for post-manufacturing test heavily depends on

production volumes - for our rather small quantities, automated ICT

equipment would never calculate. So obviously we are working on

different targets.

I'm looking at board that has a couple of small (thankfully) BGAs, a few

TSSOPS and SOICs and a couple of dozen discrete SMT components (I think

there's about 75 line items on my BOM) and would be made in 10k to 25k

piece monthly volumes (if the product succeeds that is).  The product is

relatively cost sensitive and the cost to build the ICT fixture is

easily amortized, even over the first 1,000 units built.

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.

"Michael Sansom"  wrote .

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.

There have been a lot of discussion on  the placement of pads and the

validity of testing regimes but very little on the second part of the

question.

As I understand it, most of the points contacted during testing are regular

pads. Eagle does not have a way of flagging these pads with a test point

attribute. Hopefully this will arrive when 'pad stacks' are implemented.

So, how do you analyse the layout to determine if nets have  test points or

pads acting as testpoints or nothing suitable?

It maybe reasonable to give a library part an 'ICT-testpoint' attribute.

This would imply that any time it is used all its pins were useful for

machine probing. The format of the text value within  the attribute could

even exclude or include particular pins. Only this would not be acceptable

for parts under heatsinks, for example. To counter this an attribute applied

to the part on the board of  'Don't probe' could be used. Now a ULP could

provide a listing of nets to points, close to what you were asking.

I imagine something could be done with another ULP that copies these points

designated as testpoints, and that includes vias, to a user defined layer or

the tTest and bTest layers. A bright colour here may assist in confirming

testpoint locations before generating a file for the fixture maker.

Just some thoughts

Warren