- Vi arbetar med fokus på stora digitala integrerade kretsar, dvs . den typ av kretsar som förväntas att bli våran verklighet inom de närmaste fem åren. Frågan vi arbetar med är: Hur skall man kunna tänkas utforma testbarheten så att sådana kretsar kan testas i produktionen. Samt hur kan man tänkas göra detta så att testbarheten går att återanvända både på kretskort/MCM och i den slutliga produkten ?

- Även om fokus ligger på digital kretsar så tillåter den teknik vi studerar även att det finns analoga funktioner (bara testinterfacet är digitalt).

- Vi strävar hela tiden efter att hålla våran forskning industrinära. Det känns viktigt för mig, antagligen för att jag har 10 års arbetserfarenhet från industrin.

- Traditionell produktionstest går normalt till så att man använder en extern testare för att testa integrerade kretsar. Nackdelen med detta är att man bara kan använda testet i produktionen. En annan nackdel är att en produktionstestare gärna kostar 1-2 MUSD. Vad vi strävar efter är att försöka bygga in dom här vita elefanterna till testare i kretsen. Dvs., vi studerar hur man kan tänkas skapa en inbyggd virtuell testare som följer med den integrerade kretsen under hela dess livstid.

- Den här presentationen kommer först att kort och i grova drag visa den teststruktur vi sysslar med sedan motivera varför vi gör detta genom att först titta på de visioner som idag finns vad gäller den tekniska utvecklingen fram till år 2000. Visionerna är sådana som presenteras på forskningskonferenser. Presentationen avslutas sedan med en inblick i hur den struktur vi studerar ser ut.

- Det vi försöker göra är att använda redan kända metoder för testbarhet men kombinera dom på ett sådant sätt att dom kan skapa total inbyggd självtest för komplexa integrerade kretsar.

- Den övre halvan visar en test-struktur som man ibland föreslår som en möjlig lösning för att testa komplexa integrerade kretsar.. Den under halvan visar den variant av teststrukturen som vi arbetar med.

- För att kunna skapa en generell struktur för testbarhet så behövs en standard, detta är mer eller mindre alla inom området överens om. En standard som normalt används för test av framförallt kretskort är IEEE standarden 1149.1 Boundary SCAN. Man skulle kunna tänka sig att använda den standarden också för att skapa ett kommunikationsinterface mellan yttervärlden och den integrerade kretsen. Via Boundary SCAN skulle man sedan kunna testa kretsen genom att aktivera t.ex. inbyggda självtestfunktioner (BIST) och tex. skicka in och läsa av data från interna SCAN kedjor. Eftersom intelligensen fortfarande ligger utanför kretsen så kommer den här lösningen att kräva en hel del kommunikation mellan kretsen och yttervärlden, detta försvårar möjligheten att kunna återanvända testbarheten i t.ex. fält. En annan svårighet som man ser är hur man skall kunna inkludera testmetoder som t.ex. IDDQ.

- Vad vi studerar är att gå steget längre. Jag föreslår att man skall stoppa in något flexibelt och intelligent mellan boundary SCAN och kretsens interna struktur. En mikroprocessor har sådana egenskaper.

- Men är det verkligen rimligt att använda en mikroprocessor för att skapa en flexibel struktur för test, kommer inte detta att kosta mer än det smakar i form av stor extra yta ?

- Vi tror inte att mikroprocessorn i sig själv kommer att medföra så stor extra yta att den skulle avskräcka från att användas, varför tror vi det ?

- På marknaden finns idag kompakta och snabba mikroprocessorer som är optimerade för att användas för inbyggnad i integrerade kretsar. Ett exempel på en sådan mikroprocessor är uRISCen från det norska företaget VLSI Nordic AS i Trondheim. Den har en Harvard arkitektur.
......... beskriv kort bilden .........

- I tabellen här så visas tre olika minneskonfigurationer när den används i en 1 um process.
...... beskriv kort tabellen...........

- Visa bild 1 igen och peka på testaren. För att testa kretsen så går det åt massor med testvektorer, dvs både indata och utdata som krävs för att utföra testet finns sparat i testaren.

- Men inte får man väl plats med så mycket testvektorer i så lite ROM ? Nej det får man inte, men om man kan partionerar den total testen på ett vettigt sätt och man använder LFSRer för att både skapa testvektorer, kompaktera responserna och analysera testsvaren med, då räcker det att spara konstanter som definierar startmönster och algoritmer som används i LFSRerna. Genom att bygga in LFSRerna i registerbanken så tror vi att man kan få en mycket kompakt lösning på denna problematik. Vi studerar just nu en idé att använda två register för att skapa en mycket flexibel LFSR, dvs den är helt konfigurerbar via processorn. Eftersom en registerbank normalt har 16 register så har man teoretiskt möjligheten att ha ända upp till 8 LFSR som arbetar i parallell.

-

- Som vi ser här så har komplexitetsökningen för integrerade kretsar ökat med i snitt 58 % per år under perioden 1980 till år 2000. Under samma tidsperiod så har produktiviteten bara ökat med 20 % per år. Den här utvecklingen är i långa loppet helt ohållbar och kommer att leda till en kostnadskris om denna utveckling fortsätter.

- Tabellen visar vad denna snedhet mellan komplexitetsökning och produktivitetsökning medför. ....... beskriv tabell.

- Sådana kostnader för att ta fram komplexa kretsar blir svåra att bära även för kretsar som går i mycket stora volymer. Detta är en av drivkrafterna bakom att det börjar komma virtuella komponenter, sk. IP (Intellectual Property). Det är färdigutvecklade komponenter men dom är inte tillverkade. Men enbart införandet av IP moduler räcker inte för att hantera den ökande komplexiteten det måste också komma fram helt nya typer av verktyg som tillåter att vi kan arbeta med nya arbetsmetodiker.

- Tidigare har implementationsmetodiker som "capture - simulate" används, dvs. schemainmatning av nätlistan följt av simulering för att verifiera funktionen. Idag används metodiken "describe - synthesise", dvs beskriv funktionen med VHDL eller grafik och översätt sedan beskrivningen till en nätlista genom att göra en syntes. Båda dessa metoder har nackdelen att specifikationen manuellt översätts till en konstruktion och manuellt arbete tar tid och medför risker som att man direkt upptäcker om specifikationen innehåller fel eller om den tolkas felaktigt.

- För att få upp effektiviteten på utvecklingsarbetet så är visionen att utvecklingsmetodiken måste ändras till "Specify - Explore - Refine". Dvs man skapar först en specifikation som är både simulerbar och möjlig att utföra en syntes av arkitekturen på. Med arkitektursyntes så menar vi att man kan ta fram en optimal partitionering mellan hård och mjukvara. Efter denna automatiska uppdelning mellan mjuk och hårdvara så kan resterande implementering av både mjuk och hårdvara ske helt i parallell.

- Men vad kan tänkas krävas för att man skall kunna få fram ett verktyg som klarar av att utföra en syntes från specifikation till arkitektur ? Det kommer antagligen att kräva att man kan använda en generell modell som är på en hög abstraktionsnivå [byt bild]

- Men vad krävs det för att det skall vara rimligt att kunna syntetisera fram en struktur från en specifikation ?

- En vision som finns är att om vi arbetar på en tillräckligt hög abstraktionsnivå så borde det räcka med en generell modell. En sådan modell kan bestå av logiska moduler som är hopkopplade via en hierarki av lokala och globala bussar. Dvs man har en typ av distribuerad datorarkitektur där varje block självständigt kan utföra sin del av arbetet.

- Vi kommer senare att se att den teststruktur vi arbetar med har en hierarkisk uppbyggnad som i grova drag påminner om den här strukturen..

-

- Som jag visade tidigare så var komplexitetsökningen 58 % per år 1980-2000.

- Med den här bilden vill jag visa vad komplexitetsökningen i praktiken innebär.

- Beskriv kort vad bildens olika delar (rutor) betyder

- Det här betyder att vi antagligen också att testmetodiken som används på en nivå följer med ned till nästa kompaktare nivå, dvs vi har en koppling mellan teknologisk komplexitetsökning och vilken metodik för testbarhet vi använder på olika nivåer.

- En tänkbar slutsats som man kan dra av detta är att den metod som idag används för att testa kretskort är den metod som antagligen kommer att användas för att testa morgondagens integrerade kretsar. Detta indikerar att det kan vara vettigt att studera dagens standarder för kretskort när man studerar metoder för att testa morgondagens integrerade kretsar.

- Man vinner också tid genom att använda en redan existerande standard. Det tar ofta ca 10 år från det att en standard första gången blir definierad tills den får en bredare användning plus de år det tar att skapa standarden.

- I vårat forskningsprojekt så försöker vi använda redan kända/standardiserade metoder. Detta för att snabbare komma fram till praktiska resultat.

- På ITC’96 så presenterades bland annat visionen att komplexa integrerade kretsar kommer att bestå av ca 26 miljoner transistorer år 2001. Sådana kretsar brukar populärt kallas för SOC som står för "system på kisel".

- För att klara av att bygga sådana kretsar med en rimlig insats av tid och pengar så kommer det att krävas att man använder sig av sk. "virtuella komponenter", dvs. sk. IP som står för Intelligent Property. Det är färdigutvecklade men inte tillverkade komponenter. En krets som består av IP och egenutvecklade block, sk. "user logic" kan tex. tänkas se ut som på bilden som visas här.

- En fråga som genast dyker upp är: Vem har ansvaret för produktionstest av IP blocken, är det användaren eller utvecklaren ? Personligen anser jag att det måste vara utvecklaren av IP block som har ansvaret för testbarheten av själva blocket. Några anledningar är:

- Men även om utvecklaren av IP block tar ansvaret för testbarheten av logiken i blocket, hur garanterar man att det går att accessa de enskilda blocken vad gäller test ? Ett IP block kan ju ligga djupt inbäddat i en krets. Här krävs antagligen att det tas fram en standard för en intern teststruktur för den här typen av komplexa integrerade kretsar.

- Om vi nu antar att vi har löst testbarheten av alla de enskilda blocken av logik i kretsen, det betyder att vi har löst testbarheten för de gråfärgade delarna av kretsen. Men hur testar vi de delar som ligger mellan blocken, det kommer att vara km-vis av ledningar och kanske också diverse klisterlogik. Detta kan uppenbarligen inte utvecklarna av IP block ta ansvaret för.

- Det betyder att om man tar fram en standard för testbarhet av IP block så måste den också inkludera hur teststrukturen för IP skall se ut så att man kan testa alla ytorna utanför blocken.

- Det har nyligen bildats två olika arbetsgrupper som skall studera detta med IP moduler och standard. Den ena gruppen går under namnet VSI som står för "Virtual Socket Interface". Arbetsgruppen bildades i september 1996, det är ännu inte helt definierat vad gruppens arbete skall omfatta.

- Den andra gruppen går under namnet "Embedded Core Test TAC" (Technical Activity Committe) och den hade sitt första möte under ITC’96. Den har inte riktigt kommit igång med sitt arbete men den har fått ett formellt IEEE nummer som är P1500, detta kan vara ett nummer att hålla ögon öppna efter.

- Den teststruktur som vi studerar den ser ut enligt [visa sista bilden].

- Vi tänker oss att vi kopplar ihop alla dom olika logiska blocken med tex. Boundary SCAN, detta skapar kontrollerbarhet och observerbarhet av de olika blocken. Eftersom vi har en seriell struktur för att kunna prata med de enskilda blocken, kommunikationsflödet mellan blocken bör vara begränsad.

- Därför jobbar vi efter tesen att de enskilda blocken skall ha inbyggd självtest (BIST).

- De metoder som hittills har fått störst spridning inom testbarhet är metoder som tillåter att man först implementerar hårdvarustrukturen för testbarhet och först senare skapar man själva testprogrammet, dvs testvektorerna som skall användas för att utföra själva testet. genom att använda en inbyggd testprocessor i [peka] så kan vi separera testprogramutvecklingen från implementeringen av teststrukturen. Detta hoppas vi skall öppna dörren för att kunna används verktyg för att automatiskt skapa testprogrammet, dvs det program som styr processorns operationer.

- Vi låter test-processorn testar de vita ytorna, dvs det som ligger mellan blocken av logik. Vad det gäller test av de enskilda blocken, där används test-processorn enbart för att aktivera test genom att skicka kommandon att utföra BIST och en stund senare så kan test-processorn läsa tillbaks resultatet från testet av de olika blocken av logik. Detta ger en begränsad mändg kommunikation mellan test-processorn och de enskilda blocken och parallelitet i testning av de enskilda blocken.

- De enskilda blocken av logik skall företrädesvis använda inbyggd självtest av sin egen logik. Testprocessorn skall bara aktivera de inbyggda självtesten och sedan läsa tillbaks resultaten av testen från de enskilda blocken.

- Som ni ser så påminner strukturen om ett kretskort/MCM, dvs. det borde gå lika bra att använda samma strategi även på kretskort/MCM, dvs vi tror att den här strukturen är så pass flexibel att den kan vara användbar även för att skapa testbarhet av hela produkter under hela produkternas livstid.