Ingesloten ontwerp met FPGA's:ontwikkelingsproces

Als de vereisten voor digitale verwerking in een systeemarchitectuur de mogelijkheden van microcontrollers en microprocessors overschrijden die anders geschikt zouden zijn voor gebruik in het systeem, kan het passend zijn om te overwegen een FPGA in het ontwerp op te nemen. Sommige systeemarchitecturen, met name die welke profiteren van snelle digitale hardware die parallelle bewerkingen uitvoert, zijn natuurlijke kandidaten voor FPGA-implementatie. Andere systeemarchitecturen kunnen mogelijk voldoende presteren met traditionele digitale verwerking, maar er kunnen waardevolle kansen zijn om te profiteren van de flexibiliteit en uitbreidbaarheid die wordt geboden door een FPGA-implementatie gedurende een geplande levensduur die aanzienlijke systeemupgrades in de toekomst voorziet.

Nadat de beslissing is genomen om een ​​FPGA in het ontwerp op te nemen, is de volgende stap het toewijzen van de delen van de algemene systeemvereisten voor digitale verwerking aan het FPGA-apparaat. Dit omvat doorgaans de specificatie van de FPGA-ingangs- en uitgangssignalen, de updatesnelheden van in- en uitgangen en de identificatie van componenten waarmee de FPGA moet communiceren, inclusief onderdelen zoals ADC's en RAM-apparaten.

Vereiste FPGA-functies identificeren

Na het definiëren van de functies die door de FPGA moeten worden uitgevoerd, en met kennis van de interfaces naar andere apparaten die de FPGA moet ondersteunen, wordt het mogelijk om een ​​lijst met functies te ontwikkelen die kandidaat-FPGA-apparaten moeten bieden.

Sommige FPGA-families zijn ontworpen voor goedkope, minder complexe toepassingen en bieden dus een beperkte set middelen voor het implementeren van digitale logica. Deze apparaten werken mogelijk op batterijvoeding en hebben alleen passieve koeling nodig. Andere, krachtigere FPGA-families ondersteunen grootschalige, volledig uitgeruste digitale ontwerpen, zijn bedoeld om topprestaties te leveren en vereisen mogelijk continue actieve koeling.

De systeemvereisten die aan de embedded applicatie zijn gekoppeld, zullen leidend zijn bij de selectie van een geschikte FPGA-familie voor de applicatie. Op dit moment is het waarschijnlijk niet mogelijk om een ​​specifiek FPGA-model binnen de voorkeursfamilie te identificeren, omdat de resourcevereisten van de FPGA-implementatie niet volledig zijn gedefinieerd. Met ervaring is het echter mogelijk om een ​​klein aantal FPGA-modellen te identificeren die geschikt lijken voor het ontwerp.

Naast de FPGA-bronnen voor de implementatie van digitale circuits, bevatten veel FPGA-modellen extra functies die belangrijk kunnen zijn voor het systeemontwerp. Een ingebouwde ADC kan bijvoorbeeld handig zijn om het aantal systeemonderdelen te minimaliseren. De lijst met vereiste en gewenste FPGA-functies helpt de selectie van geschikte FPGA-apparaten voor het systeem verder te verkleinen.

Het FPGA-ontwerp implementeren

Na het identificeren van een kandidaat-FPGA-model en met de gedetailleerde definitie van de functionaliteit die aan de FPGA is toegewezen, is het tijd om te beginnen met de implementatie van het FPGA-ontwerp. Dit zal over het algemeen het gebruik van de FPGA-ontwikkeltoolsuite inhouden en bestaat meestal grotendeels uit het ontwikkelen van HDL-code in de voorkeurstaal voor het project.

Indien van toepassing, kan de FPGA-implementatie beginnen met een blokdiagramweergave van het FPGA-ontwerp op het hoogste niveau. Indien nodig kunnen componenten die zijn ontwikkeld in HDL of C/C++ worden opgenomen in het blokontwerp om de volledige systeemimplementatie te voltooien.

Als alternatief is het ook gebruikelijk dat complete systeemontwerpen direct in HDL worden ontwikkeld. Voor ontwikkelaars die bekend zijn met de taal en met een volledig begrip van de functies en beperkingen van het FPGA-model dat wordt gebruikt, kan dit leiden tot het meest hulpbronnenefficiënte en best presterende ontwerpresultaat.

De ontwikkeling van FPGA verloopt in fasen naarmate het oorspronkelijke ontwerp in meer detail wordt gespecificeerd totdat een programmeerbestand voor het FPGA-apparaat is geproduceerd. Het is gebruikelijk om deze fasen meerdere keren te doorlopen voor een groot project, waarbij tijdens elke stap door de stappen een klein deel van het totale ontwerp wordt ontwikkeld. Deze fasen worden in de volgende secties beschreven.

Ontwerpinvoer

Ontwerpinvoer is de fase waarin de systeemontwikkelaar de systeemfunctionaliteit definieert met behulp van HDL-code, blokdiagrammen en/of C/C++-code. De code en andere artefacten, zoals blokdiagrammen, definiëren de logische functionaliteit van het systeem in abstracte termen. Met andere woorden, de ontwerpartefacten definiëren een logisch circuit, maar ze bepalen niet hoe het is geïntegreerd met de rest van het systeem.

I/O-planning

FPGA I/O-planning is het proces van het identificeren van de pinnen die zijn toegewezen om bepaalde I/O-functies uit te voeren en het koppelen van apparaatfuncties zoals de I/O-signaalstandaard die voor elk signaal moet worden gebruikt. Als onderdeel van het I/O-planningsproces kan het belangrijk zijn om zaken te overwegen, zoals waar op het fysieke apparaatpakket de I/O-pinnen zich bevinden. Deze stap is belangrijk om de spoorlengte van de printplaat te minimaliseren voor hogesnelheidssignalen en om te voorkomen dat circuitsignaalsporen onnodig over elkaar heen moeten gaan.

De definitie van I/O-signaalvereisten is een vorm van beperking in het FPGA-ontwikkelingsproces. De andere primaire beperkingscategorie bestaat uit timingvereisten die de prestaties van de FPGA-oplossing bepalen. Het FPGA-syntheseproces gebruikt de HDL-code en de projectbeperkingen om een ​​functioneel correcte FPGA-oplossing te ontwikkelen die aan alle gedefinieerde beperkingen voldoet. Als de tool niet aan alle beperkingen kan voldoen, mislukt de synthese.

Synthese

Synthese transformeert de broncode in een circuitontwerp genaamd een netlist . De netlijst vertegenwoordigt het circuit dat is opgebouwd uit de bronnen van het doel-FPGA-model. De netlijst vertegenwoordigt een logische of schematische versie van het circuit. Het definieert niet hoe het circuit zal worden geïmplementeerd in het fysieke FPGA-apparaat. Dit gebeurt in de volgende stap.

Plaats en route

De plaats proces neemt de FPGA-bronnen gedefinieerd in de netlijst en wijst deze toe aan specifieke logische elementen binnen de geselecteerde FPGA. De resulterende resourceplaatsingen moeten voldoen aan alle beperkingen die de toewijzing van deze elementen beperken, inclusief I/O-beperkingen en timingbeperkingen.

Nadat aan de logische elementen fysieke locaties zijn toegewezen tijdens het plaatsproces, wordt een set verbindingen tussen de logische elementen geconfigureerd tijdens de route werkwijze. Routing implementeert alle verbindingen tussen de logische elementen en stelt de schakeling in staat te functioneren zoals beschreven in de HDL-code. Nadat de plaats- en routebewerkingen zijn voltooid, is de configuratie van de FPGA volledig bepaald.

Bitstream-generatie

De laatste stap in het FPGA-ontwikkelingsproces is de productie van een bitstream-bestand. Om de hoogste prestaties te bereiken, slaan de meeste moderne FPGA-apparaten hun configuratie intern op met behulp van statisch RAM (SRAM ).

Je kunt de FPGA-configuratie SRAM zien als een zeer groot schuifregister, dat misschien miljoenen bits bevat. De inhoud van dit schuifregister specificeert volledig alle aspecten van de configuratie en werking van het FPGA-apparaat. Het bitstreambestand dat tijdens de FPGA-ontwikkeling wordt geproduceerd, vertegenwoordigt de instellingen voor het schuifregister die ervoor zorgen dat het apparaat de beoogde functies uitvoert die zijn gespecificeerd door de HDL en de beperkingen. In termen van traditionele softwareontwikkelingsprocessen is het bitstream-bestand analoog aan een uitvoerbaar programma dat door een linker wordt geproduceerd.

SRAM is vluchtig en verliest zijn inhoud telkens wanneer de stroom naar het apparaat wordt verwijderd. De realtime ingebedde systeemarchitectuur moet een middel bieden om het bitstreambestand in de FPGA te laden telkens wanneer stroom wordt ingeschakeld. Doorgaans wordt de bitstream ofwel geladen vanuit het flashgeheugen dat zich in het apparaat bevindt, of vanaf een externe bron, zoals een pc, die tijdens elke opstartcyclus op het apparaat is aangesloten.

Nadat de compilatie van de FPGA-bitstream is voltooid, is de volgende stap het testen van de implementatie om te controleren of deze correct werkt. Deze stap is niet anders dan het testen dat nodig is aan het einde van een traditioneel software-buildproces.

De implementatie testen

FPGA-ontwikkeling is vatbaar voor alle soorten bugs die traditionele softwareontwikkelingsinspanningen bemoeilijken. Tijdens de ontwikkeling van FPGA zult u waarschijnlijk veel foutmeldingen krijgen met betrekking tot onjuiste syntaxis, pogingen om bronnen te gebruiken die momenteel niet toegankelijk zijn en vele andere soorten overtredingen. Zoals bij elke programmeerpoging, moet je de bron van elke fout identificeren en het probleem oplossen.

Zelfs nadat de FPGA-toepassing met succes alle fasen heeft doorlopen om bitstream te genereren, is er geen garantie dat het ontwerp zal presteren zoals bedoeld. Om binnen een redelijk tijdschema tot een succesvol ontwerp te komen, is het absoluut essentieel om in elke ontwikkelingsfase adequaat te testen.

De eerste testfase moet het gedrag van de HDL-code grondig oefenen om aan te tonen dat deze werkt zoals bedoeld. Het voorbeeldproject aan het einde van dit hoofdstuk demonstreert het gebruik van de Vivado-toolsuite om een ​​grondige test van de HDL-logica in het ontwerp uit te voeren.

Nadat de bitstream is gegenereerd, is er geen vervanging voor uitgebreide tests van de FPGA zoals geïmplementeerd in de uiteindelijke systeemconfiguratie. Deze test moet alle functies en modi van de FPGA grondig oefenen, inclusief de reactie op out-of-range en foutcondities.

Bij elke stap van het ontwerp-, ontwikkelings- en testproces moet het projectpersoneel afgestemd blijven op de mogelijkheid om systeemfuncties te implementeren die vatbaar zijn voor onjuist gedrag in onwaarschijnlijke of zeldzame situaties. Het optreden van dit soort problemen kan bugs vertegenwoordigen die buitengewoon moeilijk te dupliceren zijn en die de perceptie van het embedded systeemontwerp en de organisatie die het heeft geproduceerd voor altijd kunnen aantasten. Als u uitstekend testwerk verricht, wordt de kans op deze uitkomst aanzienlijk kleiner.

Het volgende gedeelte geeft een gedetailleerde beschrijving van de stappen in de ontwikkeling, het testen en de implementatie van een eenvoudig FPGA-project met behulp van het Arty A7-ontwikkelbord en de Xilinx Vivado-toolsuite.

Herdrukt met toestemming van Packt Publishing. Copyright © 2021 Packt Publishing

Verwante inhoud:

• Ingesloten ontwerp met FPGA's:hardwarebronnen
• Ingesloten ontwerp met FPGA's:implementatietalen
• Open-source tools helpen FPGA-programmering te vereenvoudigen
• Implementatie van drijvende-kommaalgoritmen in FPGA's of ASIC's
• Gebruik maken van FPGA's voor diepgaand leren
• Softwaretools migreren GPU-code naar FPGA's voor AI-toepassingen
• FPGA's verdringen ASIC's in op Subaru Eyesight gebaseerde ADAS

Abonneer u voor meer Embedded op de wekelijkse e-mailnieuwsbrief van Embedded.