Hvilken type FPGA ingeniør er du?

ons dec 08, 2010 (Anders Enggaard)

Test dig selv – hvilken stil matcher du bedst på?

Cowboyen

Du er vant til at arbejde i FPGA og lader altid dit FPGA design blive downloaded før du tester, så du kan se hvordan det fungerer på printpladeniveau. Herregud, hvis der er en fejl er den jo hurtig at rette og det tager kun et par timer at ændre og downloade designet igen. Desuden er en test kun noget værd, hvis man kan kontrollere realtime opførsel i systemet

Løsningsmuligheder ved fejl:

Jamen det kan jo ikke dig der har lavet en fejl. Det er garanteret ham kaosprogrammøren ved nabobordet. Men nu er du nødt til at hjæpe ham og du leder i koden for at finde ud af, om fejlen alligevel eventuelt findes der.

Alibi-rytteren

Du tester den samlede kode inden du frigiver den til integation med hardware/software. Du nyder at se dine kurveformer i simulatoren som bevis på at din konstruktion virker. Selvfølgelig kan du risikere, at en ændring et andet sted i systemet vil forstyrre din cycle timing og dermed din FPGA kode, men risikoen er ret lille.

Løsningsmuligheder ved fejl:

Du ved at din kode virker, for det har du testet (sidste år da du sidst indspicerede dine kurveformer i simulatoren). Alligevel kan der godt opstå fejl, når hele designet samles og derfor er du nødt til at fejlsøge i samarbejde med dine kollegaer finde ud af, hvor der skal laves en modifikation.

Den ansvarsbevidste

Når du har lavet dit FPGA design, har du gjort det en vane, at teste hvert delelement og den samlede kode i et simuleringsværktøj inden du frigiver det til integration med hardware og software. Det gør du typisk løbende flere gange om dagen under udviklingen af moduler. Også dit testmateriale for allerede eksisterende moduler genkøres jævnligt, så du ikke spilder andres tid på at finde fejl, som du selv kunne finde. Du downloader først, når du har tjekket, at der ingen fejl er i din egen regressionstest.

Løsningsmuligheder ved fejl

Når produktet ikke virker kaster du dig med ildhu over fejlfindingen. Din faglighed er pirret og du er lidt spændt på at se hvordan fejlen kunne opstå. “Er det din test, som ikke har været dækkende nok? Eller er du en af nøglepersonerne til at lokalisere fejlen. Om fejlen optræder i det du selv har lavet eller ej er af mindre betydning for dig.

Kategori: Debat, Process
Meta: ping/trackback | RSS 2.0

Kommentar

  1. Jens added on 28. oktober 2012

    Cowboyen:
    Ofte, er nødvendigt, at arbejde med FPGA designet i FPGA’en. Fordi, at den er sat til andre komponenter, man ikke har FPGA modeller for, og det vil være for kompleks, at udvikle dem. Samtidigt, er svært at sikre, at egenudviklede modeller er 100% korrekte.
    En anden årsag, er analyser af pålidelighed, hvor printets layout, og forbindelsen til andre komponenter, kan have betydning. F.eks. kan laves test forsøg, hvor timing mv. kan justeres, med henblik på, at undersøge hvor optimal den er, eventuel pålidelighed som funktion af timing, og andet.

    Naturligvis er en ulempe, at det kan tage tid at kompilere – dette søges undgået ved at:
    1. Afprøve en blok af sit design af gangen.
    2. Anvende reprogrammerbare strukturer, f.eks. processorer, der muliggør data, f.eks. programmet, kan uploades via JTAG og afprøves direkte på boarded. Upload af program via JTAG tager kun få sekunder.
    Det er korrekt, at “Cowboyen” ofte er den der finder fejl i andres ting, fordi at det netop afprøves, med købekomponenter, der ikke haves modeller for, samt tilkoblet det udstyr, det skal fungere sammen med.

    En ulempe ved metoden, er når den viser noget fungerer. Så virker det – naturligvis. Men ikke nødvendigvis i teorien. Og laves flere kopier, så virker de måske ikke, fordi at diverse parametre, er “tilpasset”, det pågældende udviklingskort.

    Alibi-rytteren
    Selvom du ser kurverne simuleret først – så er det langtfra alle, der har tilstrækkelige præcise modeller, til at de giver et fornuftigt svar.
    Med gode modeller – så er muligt, at tage hensyn til komponent tollerancer, f.eks. på timing. Og dermed opdages fejl, som måske aldrig var opdaget, hvis det bare var testet på boarded, og fungerede.
    Men desværre, bruger langt de fleste ikke nøjagtige modeller. F.eks. bruges kun sjældent komponenter, der indeholder “rise” og “fall”, og laver hazard simulering. Og så kan kvaliteten diskuteres.
    Ved at anvende “rise” og “fall”, kombineret med “high” og “low”, kan angives hvornår et signal tidligst stiger, hvornår det er stabilt, hvornår det tidligst falder, og hvornår det er stabilt.
    Og det er muligt, at lave hazard simuleringer, der beregner en teoretisk mulighed for, om der opstår spikes, og hvis signalet bruges til clock, kan beregnes om der teoretisk kan opstå spikes på clock.
    Gode modeller, betyder således meget, for kvaliteten – og kvaliteten ved simulering, kan gøres større, end ved en afprøvning. Afprøvningen giver kun øjebliksresultatet. Simuleringen, tager højde for, at ikke to boards er ens, og at der kan være spredning på værdierne. Kun, hvis den kan gå igennem simuleringen, og hvis simuleringen er komplet, er muligt at stå inde for, at den virker med komponenternes spredning.

    Den ansvarsbevidste
    Mange virksomheder, der har styr på udviklingen, sætter netop krav til, at alle programmører tester deres ting, inden de afleverer det. Ethvert program, består af mindre dele, der hver for sig testes, inden de leveres videre til andre.
    Metoden er følgende:
    1. Du starter med, at teste det, du får fra andre. Derved sikre du dig, at du faktisk forstår hvordan det fungerer. Normalt, vil medleveres eksempler, f.eks. tests, og “demoer”, som du kan køre. Og herefter laver du dine egne tests, så du bliver fortrolig med det, de andre har lavet.
    Opdager du fejl, så rapporterer du den, til dem der har udviklet det, i stedet for at selv rette fejlen! Mange fejlretninger skyldes at smarte “programmører”, elsker at rette i andres kode, fordi den er uhumsk, dårlig, og udviklet af tåber. Oftest, medfører disse “kodepillere” flere fejl, end gavn, da de måske end ikke forstår koden.
    Fejlrettelser, der ikke gøres af programmøren selv, medfører op til over 80% af fejlene, fordi koden ikke forstås og rettes forkert. Koderettere, er ofte af “intuitiv” natur, og kan lige se, at noget skal fikses… Og faktum er, at de ikke udvike koden, uden at have “komponenten”, de kunne bruge, og “indkapsle”.
    2. Inden du afleverer noget til andre, skal du naturligvis teste det, så du kan stå inde for, at det fungerer. Du skal medlevere test, i form af testvektorer, testprogrammer, og demoeksempler. Så andre, kan prøve delen af, og se hvordan – og at den fungerer.
    3. Normalt, laves analyser på fejl-coverage, og de medleveres sammen med testprogrammerne og deres dokumentation.

    Ulempen er, at det tager tid. Og den ansvarsbevidste, er enhver virksomhedsleders mareridt. Spørger du, de forskellige typer, hvor lang tid en opgave tager – så vil den ansvarsbevidste, skulle bruge 2-3 gange længere tid. Fordi, opgaven skal dokumenteres, testes ordentligt igennem, og fejldækning skal undersøges, og alt skal være i orden, i alle små detaljer. Så normalt, er ikke plads til typen, i nutidens stressede virksomheder…

Hvad mener du?