Stroom is een alomtegenwoordig probleem, en het is onmogelijk om het energieverbruik van een systeem te optimaliseren zonder het systeem als geheel te beschouwen. Er zijn enorme stappen gezet in de optimalisatie van een hardware-implementatie, maar dat is niet langer voldoende. Het volledige systeem moet worden geoptimaliseerd.

Hieraan zijn verreikende implicaties verbonden, waarvan sommige de weg naar domeinspecifiek computergebruik bepalen. Shift-left speelt een rol, maar belangrijker nog: het betekent dat alle partijen die een rol spelen in het totale energieverbruik voor een gedefinieerde taak moeten samenwerken om dat doel te bereiken.

Energie is hard op weg een eersteklas overweging te worden. “Nu energie-efficiëntie een cruciaal aandachtspunt wordt in alle computerdomeinen, wordt architecten vaak gevraagd rekening te houden met de energiekosten van algoritmen voor zowel hardware- als softwareontwerp”, zegt Guillaume Boillet, senior directeur productmanagement en strategische marketing voor slagader. “De focus verschuift van het optimaliseren uitsluitend voor rekenefficiëntie (snelheid, doorvoer, latentie) naar ook het optimaliseren voor energie-efficiëntie (joules per bewerking). Dit vereist dat we rekening houden met factoren zoals het aantal geheugentoegangen, de parallelliseerbaarheid van de berekeningen en het gebruik van gespecialiseerde hardwareversnellers die voor bepaalde taken een energiezuinigere berekening kunnen bieden.”

Dit verschuift de focus van hardware-implementatie naar architecturale analyse van zowel de hardware als de software. “Tijdens de latere fasen van de ontwerpstroom nemen de mogelijkheden voor optimalisatie af”, zegt William Ruby, productmanagementdirecteur bij de EDA Group of Synopsys. “Je hebt misschien meer mogelijkheden voor automatische optimalisatie, maar je bent beperkt tot een kleiner percentage verbetering. Als we kijken naar de curve voor potentiële besparingen (zie figuur 1), is deze geen vloeiende curve van architectuur naar afronding. Er is een keerpunt bij synthese. Voordat het ontwerp wordt omgezet in een implementatie, heb je veel meer vrijheidsgraden, maar na dit keerpunt neemt het drastisch af.”

Fig.1: Mogelijkheden voor energiebesparing tijdens de ontwerpfase. Bron: Synopsys

De grote barrière is dat macht vóór het keerpunt activiteitsafhankelijk wordt, en dat maakt automatische optimalisatie een stuk moeilijker. “Tijdens de ontwikkeling van RTL kunnen dynamische vectorgestuurde controles worden gebruikt om verspilling aan het licht te brengen en logische herstructureringen, clock-gating, operator-gating en andere technieken uit te voeren om deze te verminderen”, zegt Qazi Ahmed, hoofdproductmanager bij Siemens EDA. “Het is ook belangrijk om te begrijpen dat macht gebruiksgevoelig is en moet worden geprofileerd met daadwerkelijke softwaregestuurde werklasten om er zeker van te zijn dat alle mogelijke scenario’s worden gedekt. Dit geldt vooral in de context van de volledige SoC, waar het vermogensbereik compleet anders zou kunnen zijn dan wat synthetische vectorgestuurde analyses op IP-niveau zouden kunnen aantonen.”

“Er zal meer planning, profilering en optimalisatie vooraf nodig zijn”, zegt Tim Kogel, hoofdingenieur voor virtuele prototyping bij Synopsys.

Kogel wees op verschillende niveaus die moeten worden aangepakt:

• Op macro-architectuurniveau, voor analyse van grote afwegingen en selectie van specifieke verwerkingselementen;
• Op micro-architectuurniveau, om de instructieset en uitvoeringseenheden voor de doeltoepassing te optimaliseren;
• Op algoritmisch niveau: het selecteren en optimaliseren van algoritmen voor rekenefficiëntie en geheugentoegang, en
• Op softwareniveau feedback geven aan ontwikkelaars over hoe ze hun software kunnen optimaliseren op het gebied van stroom en energie.

“Dit vereist kracht- en energiebewuste tools voor virtuele prototyping en softwareontwikkeling om de gegevens te genereren, van waaruit de hardware- en software-implementatie kan worden geoptimaliseerd”, merkte hij op.

Software-toewijzing
Beslissen wat er in de software moet staan, is een vroege taak. "Wil ik een DSP-kern hebben om de CPU te ontlasten?" vraagt ​​Ruby van Synopsys. “Wat voor invloed heeft dat op mijn energieverbruik? Wil ik een hardwareversneller implementeren, of wil ik al deze functies softwarematig uitvoeren? De energiekosten van software die op de CPU draait, zijn niet nul.”

Nu systemen steeds meer door hun software worden gedefinieerd, moet daar de aandacht voor energie beginnen. “Software is een sleutelelement als het gaat om het besparen van energie en het verbeteren van de prestaties”, zegt Vincent Risson, senior principal CPU-architect bij Arm. “Rekenintensieve applicaties profiteren vaak aanzienlijk van applicatie-optimalisatie. Dit kan zowel statisch zijn in termen van sterk afgestemde bibliotheken, als dynamische raamwerken waarmee rekenkracht kan worden gericht op de meest optimale verwerkingsengine. Mobiele apparaten zijn bijvoorbeeld gestandaardiseerd op een CPU-systeemarchitectuur die applicatieprocessors verschillende rekenprestaties biedt, terwijl ze voldoen aan een gemeenschappelijke ISA en configuratie. Hierdoor kunnen applicaties dynamisch worden gemigreerd naar de processors die optimaal zijn voor de efficiëntie. Mechanismen die zorgen voor introspectie en veelzijdigheid, die worden geboden door de combinatie van zowel software als heterogene hardware, zullen in de toekomst mogelijkheden bieden voor verbeterde efficiëntie.”

Er is vaak meer dan één klasse processor waarop software kan draaien. “We kunnen kiezen, op basis van de soorten workloads die we zien, waar een bepaalde applicatie moet draaien”, zegt Jeff Wilcox, fellow en design engineering group CTO voor client SoC-architecturen bij Intel. “Als het de behoeften van een kleinere kern overtreft, kunnen grotere kernen worden opgestart. Er is telemetrie en karakterisering van de werklast om te proberen erachter te komen waar dingen moeten worden uitgevoerd om het meest energie-efficiënt te zijn. Veel van de werklasten die we nu zien, zijn anders. Zelfs als het symmetrische agenten zijn die aan dezelfde werklast werken, hebben ze onderlinge afhankelijkheden. Steeds meer workloads vereisen asymmetrische agents, waar we GPU's, NPU's en IPU's beschikbaar hebben, en waar dit soort workloads samenwerken met de CPU. Dat is veel moeilijker te optimaliseren. We zijn op het punt gekomen waarop we de haken hebben om de prestatie- en krachtuitdagingen te kunnen begrijpen, maar we zijn nog steeds bezig met het bouwen van de tools om echt te begrijpen hoe we deze volledig kunnen verwerken en optimaliseren.

De moeilijkheid hier is dat de architectuur van de werklast afhankelijk kan zijn van de architectuur van de hardware. “Er zijn veel ontwikkelingen op het gebied van AI, en niet alleen de grootte van het model is belangrijk”, zegt Renxin Xia, vice-president hardware bij Untether AI. “Het is net zo belangrijk hoe de modellen worden gebouwd, en of ze op een energie-efficiënte manier worden gebouwd. Dat is moeilijker te beantwoorden omdat het architectuurafhankelijk is. De energiekosten van een algoritme dat op een GPU draait, kunnen heel anders zijn dan de energiekosten van dat algoritme dat op een geheugen draait in de computerarchitectuur.”

Focus op software
De algemene consensus is dat dit allemaal niet mogelijk is zonder meer hardware-software-samenwerking. “Gezamenlijke ontwikkeling van hardware en software is nodig om deze stapsgewijze functieverbeteringen te bewerkstelligen”, zegt Sailesh Kottapalli, senior fellow bij Intel's datacenterafdeling. “Alleen al proberen om het transparant te doen in hardware bereikt zijn grenzen. Kijk eens wat er gebeurt op het gebied van AI. Als hardware het enige element zou zijn, zouden we de enorme vooruitgang die we nu zien niet zien. Veel daarvan zijn algoritmische verbeteringen. Als u met software-algoritmen de padlengte verkleint, kunt u hetzelfde resultaat bereiken met minder instructies en minder softwarewerk. Soms, als je daar duidelijkheid over krijgt, kunnen we erachter komen dat er voor die algoritmen een nieuwe optimale instructieset is, een nieuwe micro-architectuur, en dan kun je dat verder optimaliseren in hardware.”

Het vereist een grote verandering in de softwareontwikkelingsstromen. “In het verleden werden architecturen en softwarestromen geoptimaliseerd voor productiviteit, dat wil zeggen processors voor algemene doeleinden die waren geprogrammeerd met talen van hoog niveau, waarbij gebruik werd gemaakt van de snelste en goedkoopste softwaretools”, zegt Kogel van Synopsys. “De algemene richting was om zoveel mogelijk flexibiliteit en productiviteit te bieden, en alleen zoveel te optimaliseren als absoluut noodzakelijk. Dit moet worden omgedraaid naar het bieden van slechts zoveel flexibiliteit als nodig is, en anders gebruik maken van specifieke implementaties.”

Voor veel softwarefuncties is geheugentoegang de grootste energieverbruiker. “Een softwarefunctie kan op verschillende manieren worden geïmplementeerd, en dat resulteert in verschillende instructiestromen met verschillende vermogens- en energieprofielen”, zegt Ruby van Synopsys. “Je moet zwaardere kosten toekennen aan de instructies voor geheugentoegang. Je moet voorzichtig zijn met hoe je dingen modelleert. Ook al is het alleen maar de CPU, je moet de energiekosten modelleren in de systeemcontext.”

In de toekomst kan de nauwkeurigheid van de resultaten ook een factor zijn die kan helpen bij de optimalisatie. “Aanzienlijke energiebesparingen kunnen worden behaald door software te optimaliseren om de beschikbare hardwarebronnen beter te gebruiken”, zegt Boillet van Arteris. “Dit omvat compileroptimalisaties, coderefactoring om de rekencomplexiteit te verminderen, en algoritmen die specifiek zijn ontworpen om energiezuinig te zijn. Dit laatste kan worden bereikt met benaderende rekenkracht voor toepassingen die een zekere mate van onnauwkeurigheid kunnen tolereren, zoals multimediaverwerking, machinaal leren en analyse van sensorgegevens.”

Analyse
Het begint allemaal met analyse. “We kunnen een virtueel model van het systeem maken”, zegt Ruby. “Dan kunnen we use cases definiëren, wat in deze context eigenlijk een opeenvolging van bedieningsmodi van het ontwerp is. Dat is nog geen software. Je hebt het systeem beschreven als een verzameling modellen, zowel prestatiemodellen als krachtmodellen. En het geeft u een vermogensprofiel op basis van deze modellen en de use case die u heeft gedefinieerd. Het volgende alternatief is een soortgelijk type virtuele systeembeschrijving. Nu voert u daar een daadwerkelijke softwarewerklast tegen uit. Als je nog dieper gaat, als je meer zichtbaarheid wilt, fijnere details, kun je de RTL-beschrijving van het ontwerp nemen, misschien is het nog niet definitief, misschien is het nog vroeg, maar zolang het vooral wiebelt, kun je het erop zetten een emulator en voer het echte werk uit. Zodra u dat doet, genereert de emulator een activiteitendatabase. Er bestaan ​​emulatiegerichte vermogensanalysemogelijkheden die een grote hoeveelheid gegevens en honderden miljoenen klokcycli aan werklastgegevens kunnen verwerken en een vermogensprofiel kunnen genereren. Er is een spectrum aan dingen die gedaan kunnen worden.”

In sommige gevallen is dat misschien niet lang genoeg. “Het grootste deel van onze thermische analyses is gebaseerd op gesloten-lusanalyse, gebaseerd op siliciumgegevens, en niet op pre-siliciumsimulatie vanwege de vereiste spoorlengtes en de hoeveelheid tijd die nodig is voor de analyse”, zegt Kottapalli van Intel. “Er is geen manier waarop we zo lang kunnen simuleren om een ​​realistisch thermisch profiel vast te stellen. We gebruiken profielgegevens van silicium, met behulp van verschillende soorten werklasten en sporen, en vervolgens analyseren we welke oplossingen we moeten bouwen.”

Het is gemakkelijker als de tijdsbestekken korter zijn. “Fundamentele architectonische beslissingen moeten worden overwogen met een soort machtsvisie in gedachten”, zegt Ruby. “Je hebt een abstracter model van een hoger niveau nodig van alle delen van je systeem, inclusief alle verwerkingskernen en het geheugensubsysteem, want hoe dat is georganiseerd is echt heel belangrijk. Hoeveel geheugen is er werkelijk nodig? Dit zijn fundamentele architecturale beslissingen. U moet over een aantal vermogensgegevens beschikken die aan deze componenten zijn gekoppeld. Hoeveel stroom verbruikt de CPU onder deze specifieke werklast of die specifieke werklast? Hoe zit het met de DSP-kern, de hardware, het geheugen, het netwerk op de chip – hoeveel verbruiken ze allemaal bij het uitvoeren van elke bewerking? Die zijn nodig om fundamentele architecturale beslissingen te nemen.”

Er zijn veel nieuwe energiegerelateerde hulpmiddelen nodig. “Hoewel er EDA-tools bestaan ​​voor het omgaan met snelle transiënten met een hoge vermogensdichtheid, zijn er nog veel andere uitdagingen”, zegt Wilcox van Intel. “Sommige van de andere uitdagingen zijn het kijken naar de langere tijdconstante dynamiek, of hoe dingen in de SoC kunnen worden beheerd. Ik heb niet zoveel gezien in de EDA-ruimte dat daarbij helpt. We gebruiken meer tools van eigen bodem om die mogelijkheden te proberen op te bouwen.”

Hoewel er voor de hardwarekant van deze architecturale afwegingen tools zijn ontwikkeld, bestaan ​​er tegenwoordig maar weinig tools die aan de softwarekant kunnen helpen. “We hebben onze software-ingenieurs nodig om zo snel mogelijk de juiste code te produceren”, zegt Ruby. “Wat volgens mij echt nodig is, is een soort begeleidende technologie voor de softwareontwikkelaar. Net zoals we RTL-energieanalysetools voor de hardware hebben, hebben softwareontwikkelingssystemen een soort energieprofiler nodig die hen vertelt hoeveel stroom en energie deze code verbruikt. Omdat we nu in het tijdperk van AI leven, zou het cool zijn om AI-technologie de code te laten analyseren. Je krijgt een schatting van het energieverbruik en sommige AI-technologie zegt misschien: als je je code op deze manier herstructureert, kun je veel energie besparen.”

Conclusie
De hardwarewereld stuit op muren die verband houden met kracht en energie. Thermische grenzen en zorgen groeien binnen die gemeenschap. Zonder er rekening mee te houden, kan de hardwarefunctionaliteit niet groeien. Maar deze hebben nog niet het niveau bereikt dat het problemen op systeemniveau zijn. Totdat alle partijen die bijdragen aan het energieverbruik in dezelfde ruimte zitten en het systeem energiezuinig ontwerpen, zullen we geen echte oplossingen voor het probleem zien.

Er zit ook een tweede kant aan. Alle mensen die de tools produceren die deze mensen gebruiken, moeten ook in dezelfde ruimte komen en stromen ontwikkelen die iedereen in staat stellen succesvol te zijn. Hoewel er enige vooruitgang is geboekt tussen de EDA- en de systeemwereld bij het oplossen van enkele van de thermische uitdagingen, is er minder vooruitgang op architectonisch niveau en vrijwel geen vooruitgang tussen de hardware- en softwarewereld. Virtuele prototypes die zich concentreren op functionaliteit zijn niet voldoende. Ze moeten worden uitgebreid tot systeemvermogen en energie, en dat kan niet worden gedaan zonder dat de compilerontwikkelaars erbij betrokken worden. Er ligt een kans binnen domeinspecifiek computergebruik, omdat deze mensen als gevolg van deze problemen een nieuwe richting inslaan op het gebied van hardware, en het kan voor hen belangrijk genoeg zijn om vooruitgang te boeken op de aangrenzende gebieden. Maar het lijkt allemaal nog een lange tijd in de toekomst te blijven.

Gerelateerd lezen
De stijgende prijs van stroom in chips
Meer gegevens vereisen een snellere verwerking, wat tot een hele reeks problemen leidt, die niet allemaal voor de hand liggend of zelfs oplosbaar zijn.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://semiengineering.com/optimizing-energy-at-the-system-level/