Test din FPGA i simulator og opnå økonomisk gevinst

man dec 13, 2010 (Rolf)

$I mange udviklingsafdelinger føler FPGA designeren det måske overflødigt at bruge tid og kræfter på at teste FPGA inden det kommer ned på print. Det er så let at opdatere sit design, så det er fristende – og føles mere logisk – at vente med at teste i hardware. Man kan altid ændre designet og uploade igen. Men det kan vise sig at være problematisk, hvis FPGA’en indgår i større komplekse systemer.
”Ved at teste løbende sikrer du dig, at der er styr på processen, så du ikke skal til at lokalisere en fejl i sidste øjeblik, tæt på lancering af et produkt,” fortæller Anders Enggaard, udviklingsingeniør i Axcon.

Han kan berette om adskillige situationer, hvor han som konsulent er blevet indkaldt til sidste-øjebliks-redninger fordi et produkt er meget tæt på release, men har vist sig at fejle under den samlede regressionstest med FPGA, CPU operationssystem og applikation.

”Så står alle og kigger på hinanden, for hvor er fejlen? Det bliver til en fælles kamp mod tiden i lab, hvor software, hardware og FPGA folk i bedste fald kæmper side om at finde frem til fejlen,” fortæller Anders Enggaard, der konsekvent benytter sig af simuleringsredskaber i sit udviklingsarbejde.

FPGA skal ikke være blackbox

En anden fordel ved at benytte sig af simuleringer er, at det bliver meget lettere at fortsat udvikle på funktioner.

Lad os tage et eksempel, hvor der ligger 100 mandeårs investering i software, 20 mandeår i FPGA. Software processen er typisk indrettet med godt styr på modultest, definitioner af interface, kontrol af ændringsprocessen osv.

De 20 mandeårs investering bliver derimod håndteret som en stor ’blackbox’, hvor ingen rigtigt tør forbedre eller tilføje nye funktioner.  Der er ikke en simpel måde at sikre, at designet efter ændring stadigvæk virker, hvis den eneste fælles reference er, at FPGA designet oversættes i løbet af nogle timer. Så kigger man så på apparatet for at se om det som den gør stadigvæk giver mening.

”Sig så at test i hardware er den rigtige måde at gøre det på. Jeg mener nej – test i hardware er rigtig stærk til at kontrollere realtime opførsel af systemet og i øvrigt sikre at beregninger etc. som er langsommelige i HDL simulatoren er korrekte, men det er bestemt ikke nok,” siger Anders Enggaard.

Lad FPGA ingeniøren få tid til kvalitetssikring

Gode dækkende test som kan repeteres skal ses ikke blot som en glæde her og nu over at man kan se produktet virke, men kan også sikre at man på sigt kan vedligeholde og rette i konstruktionerne uden at ligge søvnløs om natten.

Samtidig kan man også være mere tryg ved, at de test der er udviklet til at stimulere specialtilfældene i simulatoren bliver kørt hver gang en ny version af produktet frigives. Med den ekstra gevinst, at mængden af brandslukningstilfælde daler. Når der så kommer en fejlrapport så takker man den som har rapporteret fejlen – laver en test som provokerer fejlen, retter den og frigiver igen.

”Sådan skal det føles. Men det kræver at der rent faktisk blive afsat tid til at skabe det miljø og flow omkring FPGA verifikation som er holdbart og kan vedligeholdes så længe produktet lever.

FPGA ingeniørerne som skal have lov til at blive taget seriøst med deres behov for at kvalitetssikre designs og at det er noget som rent faktisk skal betragtes som en designopgave,” understreger Anders Enggaard.

Test dig selv: Hvilken type FPGA ingeniør er du?

Kategori: Process
Meta: ping/trackback | RSS 2.0

Hvad mener du?