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
On 1/15/2011 6:20 PM, Warren Brayshaw wrote:
Hi Michael
Sounds as if you are doing it the way I suggested and don't have any ideas
to refine it any further. Since my initial response I have determined that
circles around the junction dots work best,in my opinion, (see attached).
You need to get the width of the circle wire to something you like.
Regards
Warren
Yes, I built my symbol with a circle as well. Think I used a 5 mil wire
width (0.127 mm) and it looked fairly decent.
I still say the best solution for this is for CadSoft to create a
testpoint object in the layout tool that, like you suggested, works like
a via without a drill. Then you could write a ULP to add unplaced
testpoints to the layout that the PCB designer could then place and
route. Your ULP might optionally load a list of net names that are to
have test points added (there are third party tools that will analyze a
netlist and generate a list of needed testpoints). If you wanted to get
really sophisticated your ULP could read your netlist and import the
BSDL files for whatever JTAG devices you have on the board and it would
skip placing testpoints for anything you can cover with a JTAG scan
chain. BSDL is just a subset of VHDL so it can be pretty readily
parsed. You'd probably also like the ability to attach a "no_test"
attribute on any nets that for instance, carried high speed signals
where a hanging testpoint might act as a stub and generate reflections
so the ULP would skip placing testpoints on those as well. This is all
sort of blue sky thinking but if Eagle would support such a testpoint
object you could do all sorts of cool things.
Someone mentioned the possibility of having a ULP autoplace the
testpoints and route them. Some might be interested in that, but
personally I'd be happy with just unplaced testpoints at the bottom of
the layout. I think a human can do a better job of looking at the trade
offs deciding the best place to drop the testpoint and route it.
Anyway, thanks for your help. This is now a part of my layout process.
-Michael
"Michael Sansom" wrote
Warren,
Thanks for your suggestion. It has proven to be the most workable near
term solution for placing ICT test points on schematics. I built a
schematic symbol much like you suggested. I used the point type symbol
pin, I assumed that you did the same. Putting it on a separate layer
really makes it workable. The only (small) fly in the ointment is the
connection dot that Eagle places when you drop the symbol on a net. As
you pointed out, it's completely invisible if you drop it on existing
connection dots and turn the test point layer off. I suppose that Eagle
is generating a short (or even null) wire segment and joining it to the
wire you dropped it on and generating the connection dot in the process.
Do you know of any way to modify this behavior of Eagle while still
getting the net connection to the test point?
Thanks again for the suggestion.
Regards,
-Michael
Hi Michael
Sounds as if you are doing it the way I suggested and don't have any ideas
to refine it any further. Since my initial response I have determined that
circles around the junction dots work best,in my opinion, (see attached).
You need to get the width of the circle wire to something you like.
Regards
Warren
begin 666 ICT2.jpg
M_]C_X `02D9)1@`!`0```0`!``#_VP!#``P)"0L)" P+"@L.#0P/$Q\4$Q$1
M$R8;'1<?2@PRPH+"LR.$@],C5$-BLL/E4_1$I,4%%0,#Q87E=.7DA/4$W_
MVP!#`0T.#A,0$R44%"5-,RPS34U-34U-34U-34U-34U-34U-34U-34U-34U-
M34U-34U-34U-34U-34U-34U-34U-34W_P `1" #H`(H#`2(``A$!`Q$!_\0`
M'P```04!`0$!`0$```````````$"`P0%!@<("0H+_\0`M1 ``@$#`P($`P4%
M! 0```%]`0(#``01!1(A,4$&$U%A!R)Q%#!D:$((TQP152T? D,V)R@@D*
M%A7J#A(6&AXB)BI3E)66EYB9FJCI6FIZBIJKSM6VM[BYNL#Q,7&
MQ\C)RM+3U-76U]C9VN'BX3EYN?HZ>KQ\O/T]?;W/GZ_\0`'P$``P$!`0$!
M`0$!`0````````$"`P0%!@<("0H+_\0`M1$``@$"! 0#! <%! 0``0)W``$"
M`Q$$!2$Q!A)!40=A<1,B,H$(%$*1H;'!"2,S4O 58G+1"A8D-.$E\1<8&1HF
M)R@IC4V-S@Y.D-$149'2$E4U155E=865IC9&5F9VAI:G-T=79W>'EZ@H.$
MA8:'B(FDI.4E9:7F)F:HJ.DI::GJFJLK.TM;:WN+FZPL/$Q<;'R,G*TM/4
MU=;7V-G:XN/DY>;GZ.GJ\O/T]?;W^/GZ_]H`# ,!``(1`Q$`/P#U6J&H?\?F
ME?\`7RW_`)DJ_5#4/\`C\TK_KY;_P!$R5,MB9;%^BBBJ"BBB@`HHHH`***
M* "BBHR9K>RN)D`1QLX!Z9`S0!/14$\S12VR*!B60HV?38QX_$"H[>ZDGN
MIHVCV1JB.F?O$$L,D=ON].OKZ `MT444`%%%% !5#4//S2OOEO_1,E'DZK
M_P`_ME_X"/\`_'*XKQ59>(9-7ME\UYXY&7[/]G!1%B45#:K,EI`MTZO<"-1(R]&;')'3O4U:FZ"BBB@ HHIJLKHKHP
M96&00<@B@!U%-#Q8P)4X8`]#C//X$4Z@`J&ZA^TVLT&[;YJ,F[&<9&,UR]
MMJGB?5G4?[.72%M[6[DMA]H$H8[3UX..A%6O^*T_P"H!_Y&J>8V=)K=HV/
MN9YX&GCAC6)RXV2%R3M*XY48^]G/M3(TO1>O,\-N%=$0@3,2`"QS]SG[W3VK
MXK3J ?1J/T_P"H!_Y&HYA>S\T=)17-_P#%:?\`4 \C4?\5IU`/\`
MR-1S![/S1TE%S\T=)5#4//S2OOEO
M_1,E']CVW_/6]_\``V;_`.JE?:5;K=Z:!)=X:X(.;R4_P#*0\?-QT[?UI2
MO8YI.5MC<HJA_8]M_P`];W_P-F_^+H_L>V_YZWO_`(&S?_%T]2KR[$.M:TFC
MQ1_N_-EDR0"=JHQN9FP< 9'8DD@`$FJ6C>X-6N4B")LE'[J6%V=2V"Q5MR
M5.T9&1@X/.016;XG\+><S7-LM[,DD!AF"7#22(%8.KK,"W0@KN[@@$BJGA
MKP8;*ZB(FNS9Q8<S.TD#2L%9`%CW90#<Q)/7@ 8R3>O;3^OZV+][LK6WO_7Y
M?\#NM4>UD67?Y;##!%$@]1@ GGIQ^E9J2S'2+6&$31,B(DS- ^5&WG`X)Y
M`&5Z9SQUJ:;2K-(BTLU\JC'2GSUX P2<]N]5)+2P2T@N VILLX!4#4)@0-
MI;G,@ X![U.H1M]HT]/R+;;Y2QHK$)MC,88=<[#RO)(Y],]ZMUC6NF6=W")5
M?454G SJ4K9]P5D(_P#U5/\`V':?\]=0_P#!A/\`_%T:CM'O_7WF;X0_YCW_
M`&%[C_V6N@FF6! [`D%U3CU9@!^IKG/!D8BCUN-2Q5-5G4%F+'C;U)Y)]S70
M7<3P;4(W!U<9Z$JP;'MG&,TH[%UOC8R:^BAF,*[287:JKG<3NP!_WP>N![
MTCWVQ(R;:?S'?RQ'A<YP6ZYQC :B>VN96EEDC@WNJ)Y7F-C"EB"'P"#EL
M]/X??(CDL;EX(02&*3>8$-PXVKM(P),;CR<_CCI5&1-_:(,@B6VG:;YMT8V9
M7&WJ2V.C+T)ZTXZE`OE;PZ^8'_AS@J0"IQWR<#U/3J,UXK.[@F2:-(6.'!1Y
MFXSLQ\Y4EON=_4#HFM[.2:*1BO"R[@#TN&P/4#!&?TH L6UPEU#YL88N
M9<,,'@D'C\*FJ"UA:")D8@DR2/QZ,Y(_0U/0!0_MBV_YY7O_`(!3?_$52OM5
MMVN]-(CN\+<$G-G/64@X7GKV_I6Y5#4//S2OOEO_1,E1]C.2E;</[8
MMO\`GE>_^ 4W_P`11_;%M_SRO?\`P"F_^(J_13U*M+N<?XB\426S$6:WL45O
M&)IW%HREMS;44%T.W^(DE3]T`'FL[POXQ>ZN(UV7K6DK;3%*KSO"Q5G!60)E
MQ\K##9(P""1D#K-:T5-8BC_>>5'D D;D93C<KD9!P.X((!!!%4M&\*0:3<
MI'39$/W44,BAL%2S;G8L=IP,G R>,DFKU[Z?U_6_\`P;][NK>G]?G_`,&_
M-K4,<1:."\=,*;.< \T9_E6=!J@2R@AELI7:W";-UE<D,0,9SY7RGOT/I[
MUTE%3J$;?:,6UU>",S22PWH>9]Y5;"X(7Y0N,^6,_=ST[U8_MRT_YY:A_P""
M?\`(K2HHU'>/;^ON.8\&2"6/6Y%#!7U6=@&4J>=O4'D'V-=!=3-!$KJ 29
M(TY]&< H:PO"',>_["]Q_[+703PK/$48D<@@CJ"#D'\"!2CL76^-E2YO)X
MKB2.(.JHA8%=Q<$X'+?='`]>HZB2_F6"$JZ%VF\MF$#D@;2W,>=P/ [G
MCGO5D6.-S&YG,S8_>Y4$`9P,`;2.3U'?V&$.G@JN)YA*)/-,HV[BVW;R,8Z<
M=.U49%>*\NYYDAC>%3AR7>%N<;,?(6!7[_?T!Z&G+=7,[PQ1-#&Q$N]F0L"4
M<+P-PQG.>IJ3S@)!*MS.LWS;I!LRV=O4%<=%7H!TIQTRV?RO-C$WEA) &!
M+$$L1CKD=O4T`2VDS3P;G W!V0XZ$JQ7/MG&<5/35541410JJ, `8 %.H *H
M:A_Q^:5_U\M_Z)DJ_61JU]:6U]IBW%U#$RSER'D"DY4@SSVSQGUJ9.R(F[
M4UZ**HL***`"BH+MH$M9&NF"P`9?)X(]/?/3'?I6,[VPB62 P"%I1YL$4J
MK&B[7QO(..3C/8X`YQR =!16?I*A8IPCJ\/F_NVC`"8VKG:!QC=N_7.3FM"@
M#F_"'_,>_P"PON-N,YQS
MTZ<]HR+%%1PSI.A:,G@X(92I!]P>1_]>I "BBB@ KAO%GAF[U+6H)[>=-M
MSB(*Y^1@K-Q@<A?S)KJO[<TK_H)V7_`'_3_&J5]K&F/=Z:RZC:,$N"S$3J
M=H\J09//J0/QK*IRS5FS"JH3C9LGM=!M[:T@@:>[8QQJA9;J5 <#&0H?`^@J
M;Q!.R_P"_Z?XT?VYI7_03LO\`OG^-/W/(I>S
M78/['MO^>M[_`.!LW_Q=']CVW_/6]_\``V;_`.+K"\0>,;6Q'EV-[:N5C,LT
MBR!BJY"JJ_P[B3GG. I.T]#2\,^-H;XQ&\U*'9,Q4Q3E!)"VW<,N-JLN%?\`
MA!!('(YJK0\B^6GY'33Z59QP/)-?&@+,1?3\ T
MA'0BI_[#M/\`GKJ'_@PG_P#BZ9%KNAPQA(]6T\*/GE#]23GD]/_P"$AT7_
M`*"G_\`@2G-'NFG[SS,KP9&(H];C4L5359U!9BQXV]2>2?<UT%W"T\&U"-
MP=7&>AL&Q[9QC-<_P"#)$FCUN2)U>-]5G964Y# [<$'NZ.<RK"Y@4-+C"@
M],I]O6B.P5OC90D@N&N4O3#RK+Y5@6VA7'4X&?WG(SCCJ:EF\^403_`&=@
M8I2WE;EWD;&7UQG>O3WXJ*'4)'N(HA)!<(SA3-$,]USMZGD;1WZ-TJ62YF
M(NA'Y2F*4O?[JKL5BS<CU/3V]S5&1:A=Y$21&+GA6()Q[XX_4_TJ2LV&]F
MG(AB>%I"6*SA28V4!<D#//;>O8G/:I>\DEFBC8+RLNX@=2CA<CT!R3C]:
MU%9DEU=F#SHG@4>>8=K1EO^6NP'.X=L5HKN"*'(8Y(& 3]* '50U#_`(_-
M*_Z6_\`1,E7ZH:DLWF6,T-N\_DSEV1"H.#&ZY8@=6'>IEL3+8OT50_M"Y_
MZ!%[_P!]P_\`QRCT+G_`!%[_WW#_\`'.9!S(H(=!.K*LL!C$X3RI%?Y1
M&6!VE@"000&!Y&<Y!!-5/#GA4Z-(C/Y2QQ?<17:1F8M#LY"C(#2# 4##<Y
M(%;/]H7/_0(O?^X?_CE']H7/_0(O?\`ON'_`..49;VU]!\ZWMKZ%^H+J[A
MLH3+.X5-V?
M;&<^U.Q=;XV-%DSN\EQ&F8*%>)=FS;G!&2>?F/L1QCKERVTL_K^"B
MQDC$;PS)EWY9TW=[;FXR,<CCGIZ]:BO($6W"I/.2D\:<3ME0S*""0<G@YY
MR1GCM3<R&'[49I3*+KRP-V%"=LQM'!X[D$_2@"U]B_T58?,Y\T2LV.IW[S
M@=AG/T]ZMUFZ_>3V&B7EQ:Q2/*D+E63;[(4D,=Q&0".V3[&CT[O_H":A_W
MW!_\=I74&U<TJ**9(4444`%%%%`!13)94AC+R'"CVS] !W/M3(;F.XW;"P
M*]5="A'O@@''7GV-`$U%1PSQ7"%X7#IG&Y>0?H>_X5)0!S?A#_F/?]A>X_\`
M9:Z2N;\(?\Q[_L+W'_LM=)4QV-:WQLC:"%X?):)&BP!L@K@=.;]EM_(\CR
M(O)_YY[!MZYZ=.M3451D5VL1XTC:U@9$SM4QC"YZX':G?9;?S_/\BSO^>F
MP;NF.O7I4U% !1110 4444 %%%% !116'H^CZ9+HMA))IUH[M;QLS- I))49
M).EMWLB6W>R-B>800O4=]HSMC4LQ]@*RY$:[B:3,ZLSYX6)E/EC=A5#\
MP!.3QDC/'(6I9M#TORCMT>QE/&%," $Y[\=._P#C6;-8Z5;G9)H.E^;O"<1J M5Y5B!G9G=\OW1-K,N!R1@8YR.@X ^M6JQ
M;/1M'N8B[ZIJ,&P5%NI(^H9`0?PZ8]:L?\`"/:_P! C3__``&3_"C4=H]_
MZ\S?"'_`#'OPO<?RUT,ID$9,2JS]@S;1>#_N;\&1I#'K<<2D::K.JJ
MHP% VX '85T]*.Q=;XV9L=_<R06T@MH0;DCRQYQZ%2W/R\<#WZU.]Q<1I&'A
MB\Z5]B)25Z$Y)VY' /8]JKR:?(;"P@,<$YM]N])#\K80KZ'N<]ED@FELA$
M;>V4JPQ"6W1LHQP?EX]L#J!]HR"XNKJWM9)C:Q$QS./.."`,_*=O/X@<C\
M:MQ&0Q@RJJOW"MN'YX'\JI"QD_LZ[MP(HC,K!(T/R1Y7&!P.,\].YK0H`***
M* *\]UY,L<2P2S.ZLP";> ,9ZD?WA4D,C2H2\+PG.-KE2?KP365%!]KU.25D
MN$B)<AOGB/W81['L?RK9H **** ,SQ!J,NE:<7MNJ-%MP'!(Y8#L1ZU@^$
M?$5U>6!M3I[S?9%1%:!E'RXP-P=AS\O4?D._7NB2QM'(JNC JRL,@@]016=X
M>@B@TP\F)(]\$;OL4#<Q49)]3[UE,G--/0QE&3J)IZ6$N;^^:W<0:7>I*1
MA6S V/?!E%58KK5(H=BZ7=*5.5VK#@]<[LSDG.<YR#GUK>JO>>68@)/-R6^5
M8G*LS>@P1_AW/2M+>9O'3?4SK:\O8?,:31[YY)7WN5,"C. .!YI[`=ZG_M.[
M_P"@)J'_`'W!_P#':M6=NUO$0[LS,VX@NSA?8%N<<?GGITJQ18?,NWYG,>#&
M+QZV[(T;-JLY-C_=X."1GZ&M]G>VMFDC3>Y54>[,%'<>OJ/J*P_"'_,>
M_P"PO<?^RUT$ZQ-$3-@1J0Y). -IR#GV(I1V+K?&S,6\NS.EHX,3LZCS'5=V
MTJYZ`D93KTY[ZGVNZ B2/>TBW/ENLRH&9?++D94XSZ'CMGN3;Q8WA\Q94D
MD('CEYR`3@$'@X=.Q/:@BQM54R2HGER9W22\[RN.23R=I[]L51D5(U
M!XHKIXX@7QL5<\+%P=P.,%F]_P`JOV4KRV^9#N97=,XZ[6*@GWXJ#[+82HUU
M&P5"6<RQ3%!SC<<J1_=&?I5R)(8PD8PH]\_4D]S[T /HHHH`*** "BBB@#
M(\3PW-QX>O8K-7:9E&%0\D;AN'OQGCOTK!\%V.LQ::TOVA(;>7!ACGC:3CDD
MJ R[0<_CU],]?=74-E;27%S(L4,8RS-VK,\,ZA:WVBVL=M,LCV\,<<J\@JP4
M=C//3@UC**=1-LPE"JIMZV+0ZN1\M]8@ILW/_M6J[PZG(D<[:EII2/\`
M>_V-\#@C.?.Z8)K2N?,#><K-'QN55$\],#DCU'IUXK4E]LD%O9;?R]
MQ>%_W9"XSMV_/Z8'KG(ZC6QT1?L31JTT8DBU/39$/1ELW(/X^=3_(UK_H(
M:?\`^ 3_`/QVIM/#E9Y)`<R2;MQ0IN51D*>5Z8Y],]#5RBP=_TD<QX,#B/
M6Q*RM(-5GW,J[03\N2!DX'MDUN:CQ9ES]V-TD8BJX8G\@:QO"'_`#'OPO<
M?RUT$\RP1%V!/(``ZDDX _$D4H[%UOC9C.?MUY KRP3()4*SVZX8)*0,Y(
M)! ./?IS1%<;9A=E82M[MD?*N1!C(SV)Z>Q%:+:BD1B%Q#- 9)!&H<`\D'
M'()';'Y9XYI9;]8W*%(XE\K:NWD[-_<CC%49&7>R6TEGJ3R3ILD+F$%QME
M(B49'][!'Y^X&-R6.:,21.LB'HRG(/XU7%\"I MYS&VF(*"0<`\G.T<$'K
M^O%3P3+/$'4$<D$'J"#@C\"#0!)1110`4444`%%%% %#6M-_M?2I['S?)\W;
M\^W=C# ],CTK#\+^&8;34N9BX=[N-),1RO"%!7('RL,]3R?R'?<UK4O[(T
MJ>^\KSO*V_)NVYRP'7!]:P?"GB:.YTM+:>"82VBK'F&%Y RXP#\H.#QW_#T&
M,N3VBON<\_9U7-O;OU-FYTJW2W=E-_(P'RHM]."Q[#(;CGO^=5186R.\=P
M;Y9E"E4BU*X??NS@#+#GY3[ <YZXM7.M1I;N8(;II<84/93XS[X0FJ<.M&&)
M@+*Y,A;))MKDESW)/D]>G&,8], 5HN7H=-.]O<_ L6NDVES:PS9J":BOM_
MM&<XR,X^_4W]AVG_`#UU#_P83_\`Q=5=/U>*"RAAG@O T2! 4L;A@0`!GF,8
ME6O[<M/>6H?"?_XBCW33]YYF5X,C$4>MQJ6*IJLZ@LQ8\;>I/)/N:Z"[
MA:>#:A&X.KC/0E6#8]LXQFN?\&2"6/6Y%#!7U6=@&4J>=O4'D'V-;][*\5LQ
MC.UV98U;&=I9@H..^,YQ[41V"M\;<>G2MCS8\L/\T33/,,;'!.6]=XX]J%
MLF%MZ.DS"Y,J^8Q7Y/V $X/(]>*B-Y<+/%%;RO-\7<L\6QRI5R1RJC^'
MCWSDXJ3[7)=2(;ADBDN`JNJC.PP[^X/>J,A[07H60QB$-/)OE E9=H"A<V
MWOMZX&.WK5Z ,L**T:1D#&R,Y4#MC@=O:J:-<,+B(SMM@?!E"@R$;%; `&,_
M,>W08QDY%BRE>6V5G.X[F&<8) 8@$CL<`9'&#G@=* +%%%% !1110 4444 0
MW5K#>VTEO<QK+#(,,K=ZSO#=E;6FB636\"1O-!&\C <N2,Y)ZGDGZ5KUG: Q
M?P]I;$8)M(CC/^P*FWO7)Y?>YK&C1115%!1110!S?A#_`)CW_87N/_9:Z">%
M9XBC$CD$$=00<@_@0Y&P/B#1;G5$@T#[9%<WTMPDOVR./L1C@Y[#/XU>_M
MKQ)_TG_`)48_P#"H3LCHJ4W5TU]Z_S-E+!1,DTDLLLJL"';:. & ' `Q\[
M>_-,_LR)2QADEA8SF?*D'#%=IZ@\<FLGVO$G_0J?5&/_"CVO$G_0J?5&
M/_"GS(CV4O[U_F;(L=JDI<SK*S;FD!7< <C&WH!V[>YS/!"L$0123R22>I
M).2?Q)-<_P#VUXD_Z%3_`,J,?%']M>)/A4_P#*C'_A1S(/92\OO7^9TE%<
MW_;7B3_H5/\`RHQ_X4?VUXD_Z%3_`,J,?%',@]E+R]?YG244451D%%%9^J
MB&XM7LWNKFWDD .ZT)\Y0#G(P"0.,9QWQ0-;ZFA6;X>_Y%S2O^O2'_T`5C+X
M)4\3ZXQE#&/;?9#8ZX.KV_AF.TLH(I_$&MI+&%A>.VN&!]@8J@"YVX
MZ>U3=WV-N6'+;F_ .2Q29H]1U&]\P@$7LI8QD9Z @%<Y_'BM:J1BT
MD] HHHH$%%%%`!1110`4444`%%%%`!1110`5GW!,5Y,[&=%DB15>&(N059B>
M@..HZCO110!$EO+<R6_VDRGY)2)"H!'[Q"A/& <`'!';D=:C4SQS^=<PN-MZ
M23&A;*^3M# #)P3]<9Q110!>LLL]U+M94EE#)N4J2-BCH>1R#UJW110`4444
3`%%%% !1110`4444`%%%% '_V0``
`
end
Warren,
Thanks for your suggestion. It has proven to be the most workable near
term solution for placing ICT test points on schematics. I built a
schematic symbol much like you suggested. I used the point type symbol
pin, I assumed that you did the same. Putting it on a separate layer
really makes it workable. The only (small) fly in the ointment is the
connection dot that Eagle places when you drop the symbol on a net. As
you pointed out, it's completely invisible if you drop it on existing
connection dots and turn the test point layer off. I suppose that Eagle
is generating a short (or even null) wire segment and joining it to the
wire you dropped it on and generating the connection dot in the process.
Do you know of any way to modify this behavior of Eagle while still
getting the net connection to the test point?
Thanks again for the suggestion.
Regards,
-Michael
On 12/31/2010 2:01 AM, Tilmann Reh wrote:
Warren Brayshaw schrieb:
>> 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.
To my knowledge, this is not true. Especially in high volume ICT,
testpoints always are separate SMD pads. This makes sure that these
areas are always free for the test needles and have a clean, smooth
surface. When using pads as test points, it is very difficult to get
reproducible contact - and the needles wear out much faster due to
horizontal forces.
>> So, how do you analyse the layout to determine if nets have test points or
>> pads acting as testpoints or nothing suitable?
If there were special ICTP objects (as suggested), it would be no
problem to generate a list of covered and uncovered signals, including
statistics, with a small ULP.
Tilmann
You can use regular SMT pads, but in general you shouldn't use vias (or
at least the contract manufactures I use will not use them).
Tilmann is right, in general you want to use a dedicated test pad that
is separate from both your vias and your SMT pads. The reasons are as
follows:
1.) CMs have problems with the ICT test probes sticking in the holes of
vias. In some cases this will result in the board getting hung up on
the ICT test fixture when the fixture tries to open. In my experience
very few CMs will want to try this for this reason.
2.) Some CMs will let you use SMT pads but they don't like it since they
don't know the height of the solder "bump" precisely so they have some
issues setting the ICT pin height. They really don't like building a
fixture that has a mix of dedicated ICT pads (which are unsoldered) and
SMT pads with solder (or at least in my experience). However, if your
board is such that you can get good coverage from just the SMT pads this
is an option.
3.) Complicating point 2 is the fact that in general you want your ICT
fixture probes to only interface with one side of the board (this is a
cost and complexity issue, you can test on both sides if you're
motivated). If you've got a board with components on one side only,
generally you're going to find that you want the ICT test points on the
side opposite the components. This also tends to take testing against
your topside SMT pads off the table. For a design with components on
the top side only, you'll tend to be driven to putting all your ICT pads
on the bottom side.
-Michael
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.
Warren Brayshaw schrieb:
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.
To my knowledge, this is not true. Especially in high volume ICT,
testpoints always are separate SMD pads. This makes sure that these
areas are always free for the test needles and have a clean, smooth
surface. When using pads as test points, it is very difficult to get
reproducible contact - and the needles wear out much faster due to
horizontal forces.
So, how do you analyse the layout to determine if nets have test points or
pads acting as testpoints or nothing suitable?
If there were special ICTP objects (as suggested), it would be no
problem to generate a list of covered and uncovered signals, including
statistics, with a small ULP.
Tilmann
"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
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/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.
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.
