Hoe u kunt voorkomen dat op FPGA gebaseerde projecten op een dwaalspoor raken

In de loop van mijn carrière ben ik betrokken geweest bij het ontwikkelen van een aantal FPGA-ontwerpen voor een aantal echt interessante projecten. Helaas ben ik ook betrokken geweest bij het redden van verschillende FPGA-ontwerpen die op een dwaalspoor zijn geraakt. Terwijl ik aan deze probleemontwerpen werkte, werd het duidelijk dat - hoewel de doelapplicaties en de leden van de ontwikkelingsteams verschillend waren - de ontwerpen een aantal gemeenschappelijke punten deelden die tot mislukken gedoemd waren voordat de eerste ingenieur zelfs maar ging zitten om de eerste regel te schrijven van HDL-code.

Met dit in gedachten dacht ik dat ik vijf veelvoorkomende problemen zou doornemen die ik heb waargenomen als onderdeel van het redden van deze projecten. Deze problemen zijn als volgt:

#1: De eerste zorg heeft niet alleen betrekking op op FPGA gebaseerde ontwikkeling, maar op engineering in het algemeen. Het probleem is dat er geen stabiele vereistenbasislijn is bij het starten. Er is altijd een wens om met het project te beginnen terwijl de vereisten nog rijpen op basis van het feit dat voortgang moet worden aangetoond. Als we echter inspringen en beginnen met ontwikkelen zonder de vereisten volledig te begrijpen, dan blijkt - maar al te vaak - enige initiële vooruitgang onjuist te zijn, en het uitvoeren van downstream-correcties brengt extra vertragingen en kosten met zich mee. Wat te vroeg beginnen eigenlijk doet, is het introduceren van risico in de ontwikkeling, en dit risico moet worden gemitigeerd. Ik waardeer dat, afhankelijk van de toepassing die voorhanden is, de diepte en details van de vereisten kunnen schalen. Ik zou veel meer en meer gedetailleerde vereisten verwachten voor een SIL4-systeem dan voor een commercieel systeem. Het komt er echter op neer dat, als de vereisten niet vanaf het begin worden overeengekomen en vastgelegd, er scope-kruip zal optreden. Hoewel het ontwerp misschien begon met een verstandige architectuur voor de vereisten zoals begrepen, zal het steeds ingewikkelder worden wanneer de ontwikkelaars proberen nieuwe functionaliteit toe te voegen naarmate de basislijn rijpt. Het duurt niet lang of er gaat iets kapot.

#2: Elk lid van het team heeft de situatie met de vereisten begrepen en moet het plan begrijpen om de FPGA te ontwikkelen. Daarom is het een goed idee om een ​​plan te hebben dat de aanpak definieert die zal worden gevolgd vanaf de kick-off tot de oplevering, de belangrijkste stappen in kwestie en de technische beoordelingspoorten die tijdens het ontwikkelingsproces zullen worden toegepast. Samen met het plan moeten we ook de architectuur en het ontwerp documenteren, elk van de belangrijkste functies identificeren, beslissen welke functies nieuw moeten worden ontwikkeld en welke IP van derden opnieuw moeten gebruiken of bestaande IP opnieuw moeten gebruiken (meer hierover later). Deze gecombineerde documentatie van plan, architectuur en ontwerpbeschrijving stelt het technische team in staat om de taak duidelijk te begrijpen. We kunnen ook alle functies herleiden tot de gestelde eisen om ervoor te zorgen dat de voorgestelde aanpak aan alle hoge eisen voldoet.

#3: Het ontwerpen van de modules en de algehele FPGA kost tijd; wat echter meer tijd kost, is het verifiëren van het ontwerp en ervoor zorgen dat het aan de eisen voldoet. Deze verificatie moet niet alleen logisch functioneel zijn, maar moet ook worden uitgevoerd in alle mogelijke bedrijfsomstandigheden van het apparaat. Dit betekent op zijn beurt dat het nodig is om een ​​duidelijke verificatiestrategie voor het ontwerp te ontwikkelen; het is niet langer een kwestie van alleen de code schrijven, een paar simulaties uitvoeren en dan het ontwerp op de hardware gooien.

#4: Soms komen we allemaal zo dicht bij de dingen en zitten we vast in ons denken dat het moeilijk wordt om te zien wanneer we iets hebben gemist. Dit is waar technische ontwerprecensies voor zijn uitgevonden. Door deze beoordelingen te houden, kunnen we ervoor zorgen dat we goede technische praktijken volgen en voldoen aan interne ontwikkelingsnormen. Belangrijk is dat ze ook onafhankelijke ingenieurs de mogelijkheid bieden om naar het ontwerp te kijken - de architectuur en implementatie - om ervoor te zorgen dat het de vereiste functionaliteit biedt. Als we het ontwerp niet beoordelen naarmate het vordert, zullen we er niet in slagen kwaliteit in te bouwen en zullen we eventuele downstream-integratieproblemen vergroten.

#5: Tot dusverre is het je misschien opgevallen dat de meeste punten die ik naar voren heb gebracht, te maken hebben met proces- en bredere technische aspecten, in tegenstelling tot de codering van het ontwerp zelf. Natuurlijk is het ontwikkelen van de code belangrijk, maar het is ook belangrijk om ervoor te zorgen dat we gebruik maken van IP van derden en interne IP hergebruiken. Idealiter zouden we zoveel mogelijk bestaande IP-blokken uit onze bibliotheek opnieuw moeten gebruiken. Waar dit niet mogelijk is, zullen we – uiteraard – nieuwe modules moeten ontwikkelen. In dit geval moeten we deze nieuwe modules zo maken dat ze opnieuw kunnen worden gebruikt in toekomstige projecten. Om ons te helpen deze nieuwe blokken te maken, moeten we het gebruik van High Level Synthesis (HLS)-tools overwegen. Door ons in staat te stellen op een hoger abstractieniveau te werken, bieden deze tools de mogelijkheid om de oplossingsruimte gemakkelijker te verkennen en risico's, ontwikkelingstijd en kosten te verminderen.

De bovenstaande punten zijn slechts enkele van de dingen die me zijn opgevallen tijdens het redden van FPGA-ontwerpen. Ik zou graag uw mening horen over projecten die op een dwaalspoor zijn geraakt.