Hvorfor elektronikkutvikleren bør tenke på testing

Det finnes mange muligheter, men én løsning skaper uavhengighet og fleksibilitet for elektronikkdesigneren og gjør det samtidig enkelt å overføre testene til produksjonen. Det skal vi se nærmere på her.

Hverdagen til utvikleren

Mange utviklere vil kjenne seg igjen i følgende situasjon: Den første prototypen er klar, men må nå vente i flere dager eller uker på sin første bruk, til den første fastvaren er ferdig. Hvis det oppstår feil, oppstår ofte spørsmålet: Hvor ligger feilen? I programvare- eller maskinvareutviklingen? Under feilsøkingen blir prosjektet flyttet frem og tilbake, og overføringen til produksjonen blir utsatt. Denne forlengede time-to-market koster ikke bare nerver, men også tid og dermed penger. Løsningen ville derfor være å gi utvikleren verktøy for å kunne starte med programvareuavhengig kvalitetssikring så tidlig som mulig.

Design for testbarhet

I løpet av snart tre tiår har JTAG/Boundary Scan etablert seg som en standardisert elektrisk testprosedyre (IEEE 1149.x) og åpnet døren for en rekke teknologier og applikasjoner. GÖPEL electronic har siden starten aktivt forsket på utviklingen av disse løsningene og tilbyr i dag test- og programmeringsløsninger for komplekse komponenter med høyhastighets datalinjer under paraplyteknologien «Embedded JTAG Solutions». Det ble tidlig klart at kostnadene reduseres hvis man tenker på testing på et tidlig stadium – dette kalles også «design for testbarhet». Dette er designregler som man bør følge for å forenkle testingen. Hvis man ser bort fra visse punkter, kan den oppnåelige testdybden bli betydelig redusert eller i ekstreme tilfeller gå helt tapt. Og ingenting er mer irriterende enn en komponent som ikke kan testes på grunn av en eneste manglende forbindelse. Det er imidlertid ikke nødvendig å frykte «mange» designregler. Programvare som SYSTEM CASCON tilbyr nemlig støtte for å overholde disse reglene. Det understreker imidlertid nok en gang at det er fornuftig å legge testingen til en veldig tidlig utviklingsfase av produktet. For når layouten først er fastlagt, er det relativt vanskelig å endre ting.

Utviklere og tester

Spørsmålet gjenstår: hvorfor skal utvikleren befatte seg med å lage tester? Det er mange gode grunner til det. For det første er det ingen som kjenner enheten bedre enn utvikleren. Han er kjent med alle komponentbetegnelser og vet hvor problemområdene ligger. Designendringer for å øke testdybden kan raskt gjennomføres – dette resulterer i en optimal testbar utforming av enheten.

Allerede den første prototypen kan testes med de samme testene som serieproduktet. Det er ikke behov for langvarig feilsøking, og samtidig spares utviklingstid. På grunn av de samme testene oppnås samme testdybde for utvikling og produksjon. I tillegg kan man gi en identisk, pinne-nøyaktig feilmelding. Dette fører igjen til en effektiv igangsetting av prototypene og nullseriene under serieforhold.

I tilfelle av kontraktsproduksjon fungerer utviklingen også som et optimalt grensesnitt. Testarkivet overføres enkelt til produsenten, så det er ikke behov for avstemming av testoppsett og testomfang fra produsentens side (fig. 1). Endringer i testene kan raskt gjennomføres selv. Testkostnadene og -omkostningene er dermed svært lave for kontraktsprodusenten, da han bare trenger å stille utstyret til rådighet. 

Maskinvare

Tradisjonelle testsystemer er store og dyre, f.eks. på grunn av nålefiksturer eller funksjonstestsystemer. Men det trengs ikke mye for å teste på et like høyt nivå som produksjonen allerede på ingeniørens arbeidsplass. Bare en innebygd JTAG Solutions-kontroller som SCANFLEX II CUBE sparer plass og anskaffelseskostnader og danner grunnlaget for omfattende testscenarier. Utvikleren kan selv lage en test for å overlevere et fungerende produkt til produksjonen – allerede inkludert testprogram. Verktøyene i Embedded JTAG Solutions-programvaren forenkler også arbeidet enormt. En testdekninganalysator gir informasjon om hvilke pinner som er tilstrekkelig testet og hvilke som er utilstrekkelig testet. På denne måten kan man avdekke åpne problemområder eller mulige tids- og plassbesparelser (f.eks. gjennom overflødige testpunkter).

Lite arbeid for utvikleren

Arbeidsinnsatsen for de første testene er liten, utvikleren trenger ikke mye for å generere testene. Først og fremst trengs det informasjon som utvikleren bør kjenne godt til: hvilke komponenter av hvilken type som finnes på kretskortet, og hvordan de enkelte pinnene på komponentene er koblet sammen. Komponenttypene må bare tilordnes de tilsvarende modellene. For eksempel finnes det for hver komponent som er kompatibel med boundary scan, en modell som beskriver boundary scan-strukturen til IC-en (den såkalte BSDL-modellen (Boundary Scan Description Language)). Avhengig av leverandør finnes det også forskjellige modeller for å beskrive komponenter som ikke er kompatible med boundary scan (f.eks. RAM-komponenter eller driver-IC-er).

Modellene leveres av testsystemet, og de nødvendige DAK-dataene er begrenset til en nett- og komponentliste. Disse kan hentes fra kretsskjemaet, som vanligvis allerede er tilgjengelig i tidlige utviklingsstadier av enheten. Fordelen: Man kan enkelt løse problemer som kan oppstå under testgenereringen, eller raskt og enkelt endre et design som er ugunstig for testdybden.

De genererte testene er da allerede tilgjengelige for den første prototypen. Denne kan uten videre testes med nøyaktig samme kvalitet som nullserien og til slutt serieproduktet: samme testdybde, samme pinne-nøyaktige feilmelding. Siden testbussen som er nødvendig for Boundary Scan allerede er utformet slik at den kan tilpasses på testobjektet (f.eks. via en kontakt), kan man også laste FPGA-er eller CPLD-er via dette grensesnittet, eller lagre bootloaderen i programflashminnet. Besparelsene som følger av dette er åpenbare.

Sammendrag og konklusjon

Hvis man tenker på testing allerede under utviklingen, gir det mange fordeler. Prototyper kan testes uten fastvare – og det i serieproduksjonskvalitet. In-system-programmering og testing kjører over samme grensesnitt. Utviklingstiden reduseres, og time-to-market blir kortere. Embedded JTAG Solutions tilbyr dermed et optimalt grensesnitt mellom utvikling og produksjon. Med en fleksibel kontroller som SCANFLEX II CUBE finnes det en maskinvareplattform som også er rustet for alle andre eventualiteter. (Abb3) For eksempel kan funksjonsbaserte teknologier for testing, programmering og emulering av FPGA-er og prosessorer enkelt integreres og senere overføres til produksjonsklar tilstand.

 Om forfatteren: Alexander Labrada-Diaz er applikasjonsingeniør i GÖPEL electronic.