De inzet van best practices uit de software-engineering zorgt voor kwaliteit, betrouwbaarheid en efficiëntie bij de ontwikkeling van fpga’s. En de aanpasbaarheid blijft behouden. Technolution legt uit.
Fpga’s zijn moeilijk te verslaan als het gaat om maatwerk waarbij verwerkingssnelheid en flexibiliteit cruciaal zijn. Maar er is ook een keerzijde. Het ontwikkelen van de benodigde programmeerbare logica is tijdrovend en complex. Efficiënt testen is lastig en vrijwel nooit uitputtend. Het naderhand aanpassen of upgraden van bestaande fpga’s wordt vaak gezien als een riskant avontuur en daarom maar achterwege gelaten. Terwijl die aanpasbaarheid juist de grote kracht is van fpga’s.
Bij Technolution integreren we al jaren fpga’s in onze oplossingen. We zetten de programmeerbare chips in in veel klantenprojecten en ze vormen de basis voor een eigen videomanagementsysteem en verschillende andere high-speed systemen. Bij de ontwikkeling van fpga’s hebben we vanaf het begin een systematische, softwaregeoriënteerde aanpak gehanteerd. Deze heeft geleid tot een gestructureerde ontwikkelmethode, die eindgebruikers optimaal laat profiteren van de kracht en flexibiliteit van fpga’s.
Nightly build
De ontwikkelaars van Technolution leggen de programmeerbare logica vast in VHDL, een hardwarebeschrijvingstaal die veel kenmerken heeft van een ‘gewone’ programmeertaal. We hebben een eigen ip-library met veelgebruikte componenten, zoals infrastructuur voor geheugen, datastreams en registerbussen, en blokken voor ethernet, i2c en andere veelgebruikte interfaces. Kroonjuweel is een softcore die we in eigen huis hebben ontwikkeld op basis van de opensource Risc-V-processorarchitectuur. Deze softcore en andere grote componenten nemen we niet rechtstreeks op in ontwikkelprojecten, maar linken we vanuit het versiebeheersysteem. Daarmee voorkomen we verschillende afsplitsingen van zulke componenten. Dit komt de efficiëntie en herbruikbaarheid ten goede.
Tegelijk met de VHDL bouwt de ontwikkelaar dekkende simulaties om zijn code te testen. Deze simulaties zijn vergelijkbaar met unittests bij software en bevatten alle relevante invoer van data en besturingsinstructies voor de fpga, gecombineerd met de verwachte resultaten. Ze zijn daarmee zelfcontrolerend. De VHDL-code en de simulaties van een module horen bij elkaar en blijven bij elkaar. De simulaties zijn dus altijd volledig up-to-date met de VHDL. Ze zijn met een opdracht op de command-line of vanuit een script op te starten en het is relatief eenvoudig om ze op een later moment opnieuw uit te voeren.
Device lifecycle management for fleets of IoT devices
Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .
Code bouwen (of simuleren) doen we altijd op een generieke buildserver. Alle benodigde versies van alle tools zijn hierop beschikbaar. Dit zorgt ervoor dat we altijd exact dezelfde code kunnen bouwen – zelfs vele jaren na de eerste oplevering – zonder dat we tijd verliezen omdat we de juiste toolversies moeten opzoeken en installeren. Zo’n generieke buildserver vergt veel minder overhead en onderhoud dan het gebruik van specifieke (al dan niet virtuele) machines per project. Bovendien is het eenvoudiger om security-updates te implementeren, waardoor we de veiligheid van de uiteindelijke fpga’s beter en vooral langer kunnen waarborgen.
De combinatie van scriptable simulaties en een generieke buildserver maakt het mogelijk om te werken met een methode die tot nu toe vooral bij softwareontwikkeling werd gebruikt: de nightly build. Deze doet precies wat de naam suggereert: alle code wordt elke nacht automatisch gebouwd en gesimuleerd. Als er iets is ‘omgevallen’ tijdens de build of de simulatie, staat er de volgende ochtend een waarschuwing in het buildlog, dat we elke dag verwerken. De tijd tussen de implementatie en de melding van het veroorzaakte probleem is heel kort. De ontwikkelaar heeft de details nog vers in het geheugen en kan het probleem snel oplossen. De voordelen voor de eindklant zijn evident: geen onnodig oponthoud tijdens het ontwikkeltraject en een hogere kwaliteit van de code.
De nightly build blijft niet beperkt tot lopende projecten of projecten waar we nieuwe code op inchecken. Ook reeds opgeleverde oplossingen bouwen en simuleren we periodiek opnieuw. Dit biedt inzicht en zekerheid bij aanpassingen van bestaande, werkende fpga-implementaties en garandeert de correcte werking van de buildserver. De kwaliteitsborging strekt zich zo uit over de hele levenscyclus van het eindproduct. De combinatie van de nightly build met de generieke buildserver zorgt ervoor dat we ook afgeronde projecten altijd snel kunnen reactiveren. De klant kan daardoor op elk moment beslissen om de functionaliteit van een bestaande fpga-implementatie te laten aanpassen of uitbreiden.
Harnas
Voor versiebeheer gebruiken we de opensource tool Git. Componenten bouwen we in een ontwikkelbranch van het archief. Wanneer een component gereed is, doet de ontwikkelaar een ‘merge request’. Een tweede ontwikkelaar reviewt de code en pas als deze in orde is, volgt de samenvoeging met het project. Discussies over de code voeren de ontwikkelaars via de Git-server, die de conversaties automatisch archiveert. Deze methode biedt een goede balans: elk stukje code reviewen we voordat we het in het project opnemen, terwijl het risico op oponthoud door onvoldoende reviewers minimaal is.
De uiteindelijke hardware testen we zo veel mogelijk automatisch. Met een zelfontwikkeld regressietestsysteem bouwen we voor elk stuk hardware een projectspecifiek ‘harnas’. Hierin sluiten we alle inputs aan op een ‘stimuligenerator’ (bijvoorbeeld een videogenerator) en alle outputs op sensoren. Dit maakt het mogelijk testscripts te schrijven om de programmeerbare logica en de software geautomatiseerd te testen. De tests zijn herhaalbaar en eventuele problemen voor het eindproduct komen snel in beeld. Een ontwikkelaar kan een gelokaliseerd probleem eenvoudig oplossen – er is geen kennis van het hele systeem nodig om te bepalen of alles goed werkt. Deze aanpak biedt een goede bescherming tegen onderbrekingen in de test- en opleverfase.
Met een gestructureerde werkwijze op basis van ervaring met software-engineering is het goed mogelijk om stevige grip te krijgen en te houden op de kwaliteit van het fpga-ontwikkelproces. Testen zal altijd een uitdaging blijven door het ‘low-level’ karakter en de complexiteit van programmeerbare logica. Maar door slim om te gaan met simulaties, scripting en werkprocessen worden de bouw en de doorontwikkeling van fpga’s een stuk voorspelbaarder en vooral een stuk betrouwbaarder. Het grootste voordeel van fpga’s – de aanpasbaarheid – kunnen we hierdoor veel beter benutten, ook jaren na de oorspronkelijke ontwikkeling.