Stephan van Beek, Sudeepa Prakash en Sudhir Sharma zijn werkzaam bij Mathworks.

21 December 2012

Dit artikel beschrijft vier best practices om met Mathworks-tooling sneller en met meer zekerheid FPGA‘s te prototypen.

Hardware-engineers ontwerpen hun algoritme doorgaans op hoog niveau en vertalen dat later naar een implementatie in HDL. Hier bespreken we vier best practices voor Mathworks-gebruikers. Dat doen we aan de hand van een digital down converter (DDC) die als model in Simulink is ontworpen. Een DDC is in veel communicatiesystemen een gangbaar onderdeel om een invoersignaal met hoge bandbreedte om zetten naar een signaal met lage bandbreedte. De benodigde hardware die dat signaal verwerkt, kan daardoor zuiniger.

Met de beschreven best practices kunnen engineers FPGA-prototypes veel sneller en met meer zekerheid ontwikkelen dan met de traditionele handmatige procedure. Bovendien kunnen ze hun modellen tijdens de hele ontwikkeling verfijnen en code snel opnieuw genereren voor implementatie in FPGA‘s. Hierdoor kost elke iteratie in het ontwerp minder tijd dan met de traditionele methode met handgeschreven HDL.

1. Vroeg analyseren van kwantisatie naar fixed-point

Het testen van nieuwe ideeën en het ontwerpen van de eerste algoritmes gaat het snelst met floating point-datatypes. Voor de hardware-implementatie in FPGA‘s en Asics zijn echter fixed point-datatypes nodig. Op een goed moment moeten engineers de algoritmes dus omzetten naar een representatie in fixed point, waarbij nauwkeurigheid verloren gaat. Ze moeten dus beslissingen nemen over het aantal bits dat nodig is voor elk datatype. Een grotere fractielengte resulteert in kleinere kwantisatiefouten, maar in meer benodigde ruimte en een hoger energieverbruik.

Doorgaans gebeurt het omzetten tijdens de handmatige HDL-codering. Engineers kunnen de twee representaties dan echter niet gemakkelijk vergelijken om het effect van fixed-point-kwantisatie te zien. Ook is het niet eenvoudig de HDL-implementatie te analyseren voor overflow. Om de juiste beslissingen te kunnen nemen, moeten engineers dus de resultaten tussen de simulatie met floating point en fixed point kunnen vergelijken voordat zij aan de HDL-codering beginnen.

 advertorial 

The waves of Agile

Derk-Jan de Grood has created a rich source of knowledge for Agile coaches and leaders. With practical tips to create a learning organization that delivers quality solutions with business value. Order The waves of Agile here.

Simulaties met floating en fixed point voor de DDC geven engineers inzicht in de gevolgen van de kwantisatie. Simulink Fixed Point helpt hen verder om de optimale grootte van hun datatypes te vinden.

2. Automatisch HDL-code genereren

Van oudsher schrijven engineers Verilog- of VHDL-code met de hand. Door HDL-code automatisch te genereren vanuit een model zijn echter belangrijke voordelen te behalen. Zo is de weg naar een prototype in een FPGA een stuk sneller en is het eenvoudig om te beoordelen of het algoritme in hardware kan worden geïmplementeerd, of om verschillende implementaties met elkaar te vergelijken.

In het DDC-voorbeeld hebben we in minder dan 55 seconden 5780 regels (goed leesbare) HDL-code gegenereerd. Dankzij automatische codegeneratie kunnen engineers het model op systeemniveau wijzigen en binnen enkele minuten de HDL-code opnieuw genereren.

3. Cosimulatie met een HDL-simulator

De Simulink-modellen zijn te hergebruiken om de HDL-simulator met de gegenereerde (of handgeschreven) code aan te sturen en de simulatie-uitvoer op systeemniveau interactief te analyseren. De visualisatiemogelijkheden van HDL-simulatoren zijn beperkt tot een digitale waveform, maar HDL-cosimulatie geeft inzicht in de HDL-code en biedt tevens toegang tot alle Simulink-analysetools op systeemniveau. Verschillen tussen verwachte en gesimuleerde resultaten zijn zo beter te begrijpen.

In het DDC-voorbeeld meldt de waveform bijvoorbeeld een verschil tussen de verwachte uitkomst en de resultaten van de HDL-simulatie. Uit het spectraalbeeld van de cosimulatie blijkt dat de verschillen in de stopband van het filter liggen (zie figuur). Engineers kunnen zo veel sneller beslissen om die te negeren.

Dankzij de koppeling tussen HDL Verifier, Simulink Design Verifier en Modelsim/Questa kunnen engineers ook code coverage-analyse automatiseren. Bij deze methode produceert Simulink Design Verifier een verzameling testcases voor model-coverage. HDL Verifier voert automatisch HDL-simulaties uit in Modelsim/Questa met deze testset om coverage-gegevens te verzamelen voor een volledige analyse van de gegenereerde code.

4. FPGA-in-the-loop-simulatie

Nadat het algoritme is geverifieerd met HDL-cosimulatie, kan het op het FPGA-targetplatform worden geïmplementeerd. FPGA-gebaseerde verificatie, ook wel FPGA-in-the-loop-simulatie genoemd, geeft meer zekerheid dat het algoritme ook in werkelijkheid presteert.

Voor het DDC-algoritme wordt een Simulink-model gebruikt om FPGA-invoer aan te sturen en om de FPGA-uitvoer te analyseren. Net zoals bij HDL-cosimulatie kunnen de resultaten in Simulink worden geanalyseerd. In dit geval is FPGA-in-the-loop-simulatie 23 keer sneller dan HDL-cosimulatie. Dankzij deze hogere snelheid kunnen engineers uitgebreidere testcases bestuderen en regressietests uitvoeren voor hun ontwerpen. Met zulke tests kunnen zij mogelijke probleemgebieden herkennen die nader geanalyseerd moeten worden.

Hoewel HDL-cosimulatie langzamer is, biedt het wel meer inzicht in de HDL-code tijdens simulatie. Het is daarom uitstekend geschikt voor een verfijndere analyse van de probleemgebieden die tijdens FPGA-in-the-loop-simulatie worden gevonden.

Edited by Pieter Edelman