Het programmeren van processors wordt ingewikkelder naarmate er meer en verschillende soorten verwerkingselementen in dezelfde architectuur worden opgenomen.

Hoewel systeemarchitecten kunnen genieten van het aantal beschikbare opties om het vermogen, de prestaties en het gebied te verbeteren, blijkt de uitdaging om functionaliteit te programmeren en alles samen te laten werken een grote uitdaging te worden. Het omvat meerdere programmeertools, modellen en benaderingen van verschillende IP-providers.

"In elk soort edge-inferentieproduct, of het nu een Nest-camera is, een camera in een autotoepassing of zelfs een laptop, zullen er in principe drie soorten functionele software zijn, grotendeels afkomstig van drie verschillende soorten ontwikkelaars: datawetenschappers, ingebedde CPU-ontwikkelaars en DSP-ontwikkelaars”, zegt Steve Roddy, chief marketing officer bij kwadraat.

En afhankelijk van waar ze zich in het ontwikkelingsproces bevinden, kunnen hun benaderingen er heel anders uitzien. "De datawetenschappers brengen hun tijd door in Python, trainen voor frameworks en doen dingen op wiskundig abstractieniveau", zei Roddy. "PyTorch is van zeer hoog niveau, geabstraheerd, geïnterpreteerd, met niet veel aandacht voor de efficiëntie van de implementatie, omdat het enige waar ze om geven functies in wiskunde en nauwkeurigheid in modellen, enz. Zijn. Wat daaruit voortkomt, zijn PyTorch-modellen, ONNX-code , en Python-code, die is ingebed in het PyTorch-model. Embedded developers zijn een heel ander persoonlijkheidstype. Ze werken met meer traditionele toolsets die de tools van CPU-leveranciers kunnen zijn, of Arm-toolkits, of iets algemeens zoals Microsoft Visual Studio voor C/C++-ontwikkeling. En het maakt niet uit welke CPU het is, je krijgt de versie van de leverancier van een ontwikkelingsstudio voor die specifieke chip, en die komt met vooraf gebouwde dingen zoals RTOS-code en drivercode. Als je een oplossing op chipniveau van een bepaalde leverancier koopt, heeft deze de stuurprogramma's voor de DDR en de PCI-interfaces, enzovoort."

Denk bijvoorbeeld aan applicatieprogrammering voor een iPhone, dat is zeer geabstraheerd. "Er is een ontwikkelaarspakket voor de iPhone-ontwikkelaars, waar nog veel andere software bovenop zit", zei hij. “Maar voor het grootste deel is het iets ingebed. Iemand schrijft C-code, iemand haalt een besturingssysteem binnen, of het nu Zephyr is of Microsoft OS of iets van dien aard. En wat produceren ze? Ze produceren C-code, soms assembleercode, afhankelijk van de kwaliteit van de compiler. De DSP-ontwikkelaar, die ook een algoritme-ontwikkelaar is, is vaak georiënteerd op wiskundigen en gebruikt tools zoals MATLAB of misschien een Visual Studio. Hier worden drie codeniveaus gemaakt. Python-achtige data science-code, DSP, C++ en embedded code.”

Door de lens van een Android-ontwikkelaar, Ronan Naughton, directeur productbeheer, Client Line of Business bij Arm zei: "Een typische software-engineer ontwikkelt misschien een mobiele app voor implementatie op meerdere platforms. In dit geval zullen ze op zoek zijn naar de laagste onderhoudskosten, naadloze draagbaarheid en hoge prestaties die kunnen worden geleverd door de alomtegenwoordigheid van de Arm CPU en ondersteunende toolchains.

In een Android-omgeving maakt programmeren voor CPU de breedst mogelijke keuze aan tools mogelijk.

"Bijvoorbeeld," merkte Naughton op, "een goede vectoriserende compiler zoals LLVM of GCC kan zich richten op meerdere CPU- en OS-doelen. Er is een rijk ecosysteem van bibliotheken voor functiespecifieke taken zoals Arm Compute Library for ML. Als alternatief kunnen ontwikkelaars de Instruction Set Architecture zelf targeten met intrinsieke elementen zoals de Arm C Language Extensions.

Onder dat alles bevindt zich een conventionele architectuur, bestaande uit een NPU, DSP en CPU, met alle stappen die nodig zijn om op de beoogde host-CPU te landen. Alle of de meeste daarvan gebruiken een of andere vorm van runtime-applicatie.

"Als u uw machine learning-code uitvoert, is de CPU actief betrokken bij elke gevolgtrekking, bij elke iteratie, elke passage door die machine learning-grafiek die het geheel orkestreert", merkte Roddy op.

Afb. 1: Tool-/codestroom voor conventionele NPU+DSP+CPU. Bron: Quadric.io

Hoe u DSP's, CPU's en NPU's programmeert, is afhankelijk van toepassingen, use cases, systeemarchitecturen en omgevingen. Dat bepaalt hoe de code kan worden geoptimaliseerd om de beste prestaties voor een bepaalde toepassing of een bepaald gebruiksmodel te bereiken.

"Op een CPU kunnen de meeste compilers code buitengewoon goed optimaliseren, maar bij het programmeren van DSP's of NPU's, vooral om code te parallelliseren, moet er veel werk worden verzet door de software-engineer omdat alle compilers falen", zegt Andy Heinig, afdelingshoofd voor efficiënte elektronica bij Afdeling Engineering of Adaptive Systems van Fraunhofer IIS. “Dit betekent dat hoe meer parallel werk er aan de hardware moet worden gedaan, hoe meer werk er handmatig moet worden gedaan door de software-engineer. En het meeste werk zit in low-level programmeren.”

Hoewel er enige overlap is, zijn er ook enkele fundamentele verschillen tussen deze verschillende verwerkingselementen. "Een CPU is een architectuur voor algemene doeleinden en ondersteunt dus een breed scala aan gebruiksmogelijkheden, besturingssystemen, ontwikkeltools, bibliotheken en vele programmeertalen, van traditionele low-level C tot high-level C++, Python, webapplicaties en Java," zei Guy Ben Haim, productmanager bij Synopsys. "DSP-applicaties draaien meestal op een geoptimaliseerd real-time systeem, dus het programmeren van DSP-processors vereist het gebruik van talen op laag niveau (bijv. grootte optimalisaties. In tegenstelling tot algemene CPU's, maar vergelijkbaar met DSP's, is de NPU-architectuur ook toegewijd aan het versnellen van specifieke taken, in dit geval om AI/ML-toepassingen te versnellen."

Een DSP-architectuur kan gegevens van meerdere sensoren parallel verwerken. En terwijl traditionele CPU- of DSP-programmering afhankelijk is van een programma of een algoritme met een reeks regels om gegevens te verwerken, leert AI van gegevens en verbetert het zijn prestaties in de loop van de tijd.

"AI gebruikt hoogwaardige frameworks zoals PyTorch en TensorFlow om modellen te creëren, trainen en implementeren", legt Ben Haim uit. “Neurale netwerkmodellen zijn geïnspireerd op de architectuur van neuronen in het menselijk brein en bestaan ​​uit wiskundige representaties van een systeem dat voorspellingen kan doen of beslissingen kan nemen op basis van de invoergegevens.”

Er zijn ook andere verschillen. Naast het programmeren met talen op hoog niveau zoals C en C ++, zegt Pulin Desai, groepsdirecteur, productmarketing en management voor Tensilica Vision en AI DSP's bij Cadans, “DSP's en CPU's gebruiken ook verschillende bibliotheken zoals math lib, fp lib. DSP's hebben ook een specifieke lib voor de specifieke vertical die ze mogelijk adresseren om een ​​speciale toepassing uit te voeren. DSP's en CPU's werken ook met hoogwaardige talen zoals OpenCL en Halide, die klanten gebruiken om hun applicaties te ontwikkelen."

NPU-programmering gebeurt in een geheel andere omgeving met behulp van AI-trainingsframeworks. Die genereren op hun beurt neurale netwerkcode in TensorFlow en PyTorch, en het netwerk wordt verder gecompileerd voor de specifieke hardware met behulp van een neurale netwerkcompiler.”

“Neurale netwerken zijn niet 'geprogrammeerd'. Ze zijn getraind'”, zegt Gordon Cooper, productmanager bij Synopsys. “DSP's en CPU's zijn op een traditionelere manier geprogrammeerd. Code is geschreven in C/C++. Dan heb je een IDE en debugger nodig om de code te testen en te bewerken.”

Hoe programmeermodellen werken
Dus voor CPU's en DSP's zullen ontwerpers programmeren in C of C ++, maar ze kunnen een specifieke lib api aanroepen. "Voor visie kan code bijvoorbeeld OpenCV API-oproepen aanroepen", zei Desai.

Fig. 2: Vergelijking van embedded softwareontwikkeling op DSP's/CPU's vs. NPU's. Bron: Cadans

Meestal wordt het werk om de code te optimaliseren met de hand gedaan, zei Heinig van Fraunhofer. “Programmeermodellen op hoog niveau falen vaak als het gaat om het parallel gebruiken van hardware. Maar het is natuurlijk mogelijk om bibliotheken te gebruiken met sterk geoptimaliseerde basisfuncties.”

Het ontwikkelen van een AI-model is heel anders. Er zijn verschillende stappen vereist. "De eerste is identificatie en voorbereiding", zegt Ben Haim van Synopsys. “Na het identificeren van het probleem dat geschikt is om door AI te worden opgelost, is het belangrijk om het juiste model te selecteren en de gegevens te verzamelen die in het proces zullen worden gebruikt. Ten tweede is modeltraining. Het trainen van het model betekent het gebruik van grote hoeveelheden trainingsgegevens om het model te optimaliseren, de prestaties te verbeteren en de nauwkeurigheid te waarborgen. Ten derde is gevolgtrekking. Het AI-model wordt ingezet in een productieomgeving en gebruikt om snelle conclusies, voorspellingen en gevolgtrekkingen te maken op basis van de beschikbare data.”

Er zijn ook andere verschillen. De meeste DSP's zijn vectorprocessors, met een architectuur die is afgestemd op de efficiënte parallelle verwerking van een reeks gegevens. "Om de hardware efficiënt te gebruiken, moeten gegevens worden gevectoriseerd", zegt Markus Willems, senior productmanager bij Synopsys. “Een optimaliserende compiler kan een zekere mate van auto-vectorisatie toepassen wanneer hij uitgaat van scalaire code. Maar voor de overgrote meerderheid van de use-cases is het voor optimale resultaten nodig dat een programmeur de code op een gevectoriseerde manier schrijft, met behulp van speciale vectorgegevenstypen.

Willems suggereerde dat om de volledige kracht van de instructieset te benutten, intrinsiek vaak wordt gebruikt. "Anders dan gewone assemblagecodering, laat een intrinsiek de registertoewijzing over aan de compiler, wat hergebruik en overdraagbaarheid van code mogelijk maakt."

Bovendien begint het ontwerp voor de meeste DSP-algoritmen in MATLAB om de functionele prestaties te analyseren (dwz om te controleren of het algoritme het probleem oplost). Voor een groeiend aantal DSP's is er een direct pad om MATLAB-algoritmen toe te wijzen aan gevectoriseerde DSP-code, met behulp van de MATLAB embedded coder en processorspecifieke DSP-bibliotheken.

Maar om de processor volledig te benutten, zei Heinig dat het noodzakelijk is om hardware en software samen te optimaliseren. “Anders faal je met een oplossing omdat je misschien te laat beseft dat de ontworpen hardware niet goed past bij de probleemspecificatie. Zeker als je steeds meer operaties parallel wilt uitvoeren.”

Voor een SoC-architect begint het met wat de doelmarkt en doeltoepassingen zullen worden, aangezien dat de hardware- en softwarearchitectuur zal aansturen.

"Het is altijd een uitdaging om te kiezen tussen programmeerbaarheid en vaste hardware", legt Desai uit. “Beslissingen worden gedreven door kosten (gebied van de SoC), kracht, prestaties, time-to-market en toekomstbestendigheid. Als u uw doeltoepassing kent en de kracht en het gebied wilt optimaliseren, is vaste hardware het beste. [Een voorbeeld is een H.264-decoder.] Neurale netwerken veranderen voortdurend, dus programmeerbaarheid is een must, maar een architectuur waarbij sommige functies zich in vaste functies bevinden (hardwareversneller, zoals een NPU) en andere in programmeerbare CPU's of DSP's zijn het beste voor AI."

Partitionering van de verwerking
Dit alles wordt ingewikkelder gemaakt omdat verschillende ontwerpers/programmeurs verantwoordelijk kunnen zijn voor de verschillende code.

"We hebben het over inferentietoepassingen, maar we hebben het ook over een systeembedrijf dat een systeem maakt", zei Desai. "En omdat een SoC voor algemeen gebruik is, kunnen er AI-ontwikkelaars zijn die een specifiek neuraal netwerk ontwikkelen om een ​​specifiek probleem op te lossen - bijvoorbeeld een netwerk voor ruisonderdrukking om ruis voor een microfoon te verminderen, een netwerk voor mensendetectie voor beveiligingscamera's, enz. Dit netwerk moet worden geconverteerd naar een code die op de SoC kan worden uitgevoerd, dus je hebt programmeurs die weten hoe ze de tools moeten gebruiken om het neurale netwerk om te zetten in code die kan worden gestart op een SoC met een CPU/DSP/ NPU. Als het echter een real-time toepassing is, hebt u ook systeemsoftware-ingenieurs nodig die weten hoe ze moeten werken met real-time besturingssystemen, systeemsoftware op processorniveau, enz. Er kunnen ook softwareontwikkelaars op hoog niveau zijn die kunnen ontwikkelen een GUI of gebruikersinterface als dit een consumentenapparaat is.”

Voor een NPU zijn er verschillende overwegingen. "Ten eerste moet de NPU ontworpen zijn om AI-workloads te versnellen", zegt Ben Haim. "De AI/NN-workloads bestaan ​​uit deep learning-algoritmen, die zware wiskundige en meerdere matrixvermenigvuldigingen in vele lagen vereisen, en daarom is parallelle architectuur nodig."

Hij legde uit dat een van de belangrijkste kenmerken van een goede NPU het vermogen is om de gegevens te verwerken en de bewerkingen snel te voltooien, waarbij de prestaties worden gemeten in TOPS/MAC's. “De typische halfgeleiderafweging tussen vermogen/prestatie/gebied (kosten) is ook zeer relevant in het geval van NPU-ontwerp. Voor autonoom autogebruik is de latentie van de NPU van cruciaal belang, vooral wanneer het een kwestie van leven of dood is om te beslissen wanneer je op de rem van de auto moet trappen. Dat hangt ook samen met de ontwerpoverwegingen voor functionele veiligheid. Ontwerpteams moeten ook overwegen dat het ontwerp van de NPU voldoet aan de veiligheidseisen.”

Een andere belangrijke overweging voor programmeurs zijn de ontwikkel- en programmeertools.

“Het is niet genoeg om een ​​geweldige NPU te bouwen zonder de juiste softwareontwikkelingstools die in staat zijn om eenvoudig de NN/AI-modellen uit populaire AI-frameworks te importeren, te compileren, te optimaliseren en automatisch te profiteren van de NPU-architectuur, inclusief het geheugenontwerp. overwegingen', zei hij. “Het is ook belangrijk om een ​​manier te bieden om de nauwkeurigheid van het model te controleren, evenals simulatietools, zodat programmeurs software kunnen ontwikkelen en verifiëren lang voordat de hardware bestaat. Dit is een belangrijke overweging voor de time-to-market.”

Kuiper was het daarmee eens. “NPU's lijken meer op aangepaste versnellers dan een DSP, of vooral een GPU of CPU, die volledig flexibel zijn. Je zou er misschien niet voor kiezen om een ​​NPU toe te voegen, tenzij je gedurende een aanzienlijke tijd een sterke behoefte hebt aan NN-prestaties. We hebben klanten die maar een klein beetje AI nodig hebben, een vector-DSP gebruiken voor de DSP-prestaties en deze opnieuw configureren om AI te verwerken wanneer dat nodig is, om maximale flexibiliteit van hun onroerend goed te garanderen. Dit is prima, maar zal niet zo energie- of gebiedsefficiënt zijn als een speciale NPU.”

Ten slotte komen er programmeeruitdagingen bij het proberen te bepalen welke subset van de grafiek op de NPU past en welke niet. [Zie linkerkant van figuur 1, hierboven]

"Als dat niet het geval is, moet het ergens anders worden uitgevoerd, dus moet de code worden gesplitst", zei Roddy van Quadric. “Daarnaast is er een secundaire opdrachtstroomgenerator of gekoppelde lijstgenerator die in het geheugen wordt opgeslagen, en de NPU weet genoeg om zijn opdrachten op te halen. Hoewel dit deel vrij eenvoudig is, hoe zit het dan met alle bits die niet op het systeem draaien? Waar moeten die operators draaien? Is er al een efficiënte implementatie van die machine learning-operator? Zo ja, is het hier op de DSP, of is het op de CPU als het niet bestaat? Iemand moet daar een nieuwe versie van maken. U doet dit op een DSP omdat u wilt dat deze zeer goed presteert. Nu moet je dat coderen op de DSP, en veel DSP's missen goede tools, vooral degene die speciaal zijn gebouwd voor machine learning. Algemene versies van DSP's - audio-DSP's of eenvoudige DSP's voor algemene doeleinden - kunnen twee MAC- of quad-MAC-dingen hebben. Het soort DSP's dat is gebouwd voor machine learning zal zeer brede DSP's zijn. Extra brede DSP's kunnen een goed doelwit zijn voor zeer brede activeringen en normalisaties en het soort dingen dat gebeurt in datawetenschap, maar ze zijn nieuw en hebben daarom mogelijk geen solide compilers.

Conclusie
In het verleden waren deze programmeerwerelden aparte disciplines. Maar naarmate AI-computing steeds meer wordt opgenomen in en op apparaten, en naarmate systemen steeds heterogener worden, zullen softwareontwikkelaars zich in ieder geval veel meer bewust moeten zijn van wat er op andere gebieden gebeurt.

Uiteindelijk zou dit de driver kunnen worden voor een enkele hardware-/software-architectuur waarmee technische teams complexe C++-code kunnen schrijven en uitvoeren zonder tussen twee of drie soorten processors te hoeven partitioneren. Maar er moet tussen nu en dan veel werk verzet worden wil dit gebeuren. En het is niet helemaal duidelijk, gezien de snelheid waarmee AI- en hardware-architecturen evolueren, of die architectuur nog steeds relevant zal zijn tegen de tijd dat ze klaar is.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• EVM Financiën. Uniforme interface voor gedecentraliseerde financiën. Toegang hier.
• Quantum Media Groep. IR/PR versterkt. Toegang hier.
• PlatoAiStream. Web3 gegevensintelligentie. Kennis versterkt. Toegang hier.
• Bron: https://semiengineering.com/programming-processors-in-heterogeneous-architectures/