&EMBEDDED SYSTEM består i regel av processorer som utför domänspecifika program. Mycket av deras funktionalitet är implementerad i programvara, som körs på en eller flera processorer, vilket endast lämnar de högpresterande funktioner som genomförs i hårdvara. De flesta typiska inbyggda system (t.ex. TV-apparater, mobiltelefoner och MP3-spelare) kör multimedia- eller telekomapplikationer som uppvisar dynamiskt beteende, och kostnaderna för att utföra dem (t.ex. antalet cykler och energi) beror på indata. Dessutom är dessa applikationer ofta implementeras som en huvudslinga, kallas slingan av intresse, som utförs om och om igen, läsning, bearbetning, och skriva ut enskilda ström objekt (se figur 1). Ett ström objekt kan vara lite tillhörande en komprimerad bitström som representerar ett kodat videoklipp, eller det kan vara en makroblock, videoram, ljudprov, eller nätverkspaket. Vanligtvis måste dessa applikationer leverera ett givet dataflöde (antal objekt per sekund), vilket innebär en tidsbegränsning för varje loop iteration. Läsdelen av intresseslingan tar ett strömobjekt från inmatningsströmmen och separerar det till ett huvud och objektets data. Processdelen består av flera kärnor. Skrivdelen skickar de bearbetade uppgifterna till utdataenheter, såsom en skärm eller högtalare, och sparar programmets interna tillstånd för vidare användning; till exempel, i en videoavkodare, kan den tidigare avkodade ramen vara nödvändig för att avkoda den aktuella ramen. Dynamiken som finns i moderna applikationer leder till användning av olika kärnor för varje ström objekt, beroende på objekttyp. De åtgärder som utförs i en viss loop iteration utgör programmets interna driftsläge. I den här artikeln beskriver vi en metod som ger ett systematiskt sätt att upptäcka och utnyttja, vid designtid och körtid, de olika interna driftlägen. Det faktum att applikationer har olika interna driftlägen har hittills inte utnyttjats fullt ut i designen av inbyggda system. Vår strategi kombinerar en statisk analys och profilering av systemet vid designtidpunkten med information som samlas in vid drifttidpunkten om systemets miljö. Genom att känna till ett systems möjliga driftlägen och information om resursförbrukningen vid designtidpunkten är det möjligt att fatta specifika och aggressiva designbeslut för varje driftläge vid olika konstruktionssteg. För att undvika komplexa problem samlar vi de driftlägen som är nära relaterade till varandra ur ett resursförbrukningsperspektiv i tillämpningsscenarier, och som skiljer de verkligt olika driftlägen via olika scenarier. Det är då möjligt att få fram en snabbare eller lägre energiimplementering (t.ex. genom att använda olika källkodsoptimeringar per scenario) eller en bättre uppskattning av nödvändiga resurser (t.ex. antalet beräkningscykler eller bandbredd). Detta leder till ett mindre, billigare och mer energieffektivt system som kan ge den önskade prestandan. En designmetod för att hantera allt mer dynamiska systemapplikationer i realtid kan hjälpa utvecklare att hantera stränga system- och marknadskrav. Denna metod grupperar en ansökans driftlägen i tillämpningsscenarier och beskriver hur man integrerar dem i den övergripande designprocessen. En automatiserad scenariobaserad designbana minskar energiförbrukningen för ett strömmande program som körs på en enda processorplattform via dynamisk spänning och frekvensskalning.  Scenariobaserad design har länge använts inom områden som människa-datorinteraktion och objektorienterad programvaruteknik. 1 I dessa fall, i en tidig fas av utvecklingsprocessen, scenarier konkret beskriva ett systems framtida användning. Dessutom ser de ut som berättande beskrivningar av tänkta användningsepisoder eller som Unified Modeling Language (UML) användningsfall diagram som räknar upp, från ett funktionellt och timing perspektiv, alla möjliga användaråtgärder och systemreaktioner som krävs för att uppfylla en föreslagen systemfunktionalitet. Dessa användningsscenarion karakteriserar systemet ur användarperspektivet. I det inbäddade systemområdet användes de i både hård- och programvarudesign. Denna artikel koncentrerar sig på tillämpningsscenarier, som vi härleds från systemets beteende. Dessa scenarier är en påvisbar uppsättning av ett programs driftlägen som är tillräckligt lika i ett flerdimensionellt resursbaserat kostnadsutrymme (såsom körcykler, minnesanvändning eller källkod). De minskar systemkostnaderna genom att utnyttja information om vad som kan hända i körtid för att fatta bättre designbeslut. Medan användningsfallsscenarier klassificerar applikationens beteende efter de olika sätt som det kan användas på, klassificerar applikationsscenarier det ur ett resursanvändningsperspektiv. Forskare från IMEC var de första som identifierade och utnyttjade dessa typer av scenarier. Kostnadsutrymmet definieras över ett specifikt problems intressedimensioner. Till exempel kan vi vara intresserade av driftlägen som delar samma källkod eller som kör i samma antal CPU cykler. För att vi ska kunna utnyttja dessa lägen måste de vara detekterbara i applikationen, helst så snart applikationen börjar köras i ett av dem. Eftersom definitionen av ett applikationsscenario är mycket allmän, måste vi skräddarsy det efter det specifika designproblemet till exempel, applikationsbeteendet för en viss typ av indata. 3 Figur 2 visar en designbana med användningsfall och tillämpningsscenarier. Det utgår från en produktidé, där intressenterna definierar produktens funktionalitet som användningsfallsscenarier. (De berörda parterna är personer, enheter eller organisationer som har en direkt andel i det slutliga systemet; de kan vara systemägare, regulatorer, utvecklare, användare eller utvecklare.) Dessa scenarier kännetecknar systemet ur ett användarperspektiv och fungerar som ingångar till en designprocess som inkluderar både programvara och hårdvarukomponenter. För att optimera systemets design, detektion och användning av tillämpningsscenarier öka denna bana (bottengrå låda i figur 2). När ansökan är kodad, dess scenarier relaterade till resursutnyttjande är semiautomatiskt extraheras, och de beaktas för de beslut som fattas under följande faser av systemdesign. De uppsättningar användningsfall och tillämpningsscenarier är inte nödvändigtvis osammanhängande. Ett eller flera användningsfallsscenarier skulle kunna slås samman i ett tillämpningsscenario, ett användningsscenario skulle kunna delas upp i flera tillämpningsscenarier, eller flera tillämpningsscenarier skulle kunna korsa flera användningsfallsscenarier. Som en fallstudie, anser vi utformningen av en portabel MP3-spelare som en USB (Universal Serial Bus) pinne. Vid första anblicken verkar det finnas två huvudsakliga användningsfall: spelaren är ansluten till datorn, och musikfiler överförs mellan dem, och spelaren används för att lyssna på musik. Men vi kan dela upp dessa scenarier i mer detaljerade användningsfallsscenarier, såsom sångval, spel eller snabbframkallning för det senare scenariot. Låt oss se på spelscenariot. Ur ett programvaruperspektiv kan vi dela upp detta användningsfall i två 582 olika tillämpningsscenarier: mono- och stereolägen. Genom att utnyttja dessa scenarier kan vi öka batteriets livslängd eftersom monoläge kräver mindre datorkraft. Därför kan vi använda en lägre matningsspänning samtidigt som vi fortfarande uppfyller avkodningens tidsbegränsningar. Metoden för att införa tillämpningsscenarier i den nuvarande konstruktionsbanan för inbäddade system har tre steg (se figur 3 ): 1. Identifiering. Hur klassificeras ansökan i scenarier? 2. Utgångspunkten är följande: Förutsägare eller detektorer. Vilket scenario tillhör en särskild upprepning av intressekretsen? 3. Vad är det som händer? Utnyttjande. Vad kan vi göra för att optimera systemet när det körs i ett visst scenario? Dessa steg påverkas av det konstruktionssammanhang i vilket de tillämpas, men är ändå allmänna. Steg 1 Scenario identifiering börjar från den ursprungliga applikationen och identifierar sina olika driftlägen. Dessa transportsätt resursanvändning (i kostnadsrymden av intresse) kännetecknas, och de med liknande behov är grupperade i ett tillämpningsscenario. De metoder som används för att identifiera scenarierna kan delas in i tre kategorier: analys, profilering och hybrid. Oberoende av metoden ska uppsättningen av de identifierade användningsscenarierna omfatta alla möjliga användningssätt. I en analysmetod analyseras applikationsstrukturen statiskt för att identifiera liknande driftlägen. Denna metod är restriktiv eftersom den inte automatiskt kan samla in information om hur applikationen verkligen används och hur den beter sig på runtime-till exempel, vilket scenario som oftast används på runtime. Programmets verkliga körtid beteende kan fångas med hjälp av en profileringsmetod, men i detta fall är det svårare att härleda scenario prediktorer än det är i det analytiska fallet; i allmänhet kan inte alla scenarier identifieras, eftersom profilering kanske inte täcker alla möjliga, distinkta driftlägen. För att lösa detta problem, måste vi överväga en backup scenario, som väljs vid körtid när programmet körs i ett driftläge som inte visas under profilering. En hybridmetod kombinerar fördelarna med de två tidigare metoderna och är det mest kraftfulla sättet att fastställa scenarier. Särskilt för profilerings- och hybridmetoder kan en explosion av antalet driftlägen inträffa under identifieringen. I detta fall är det nödvändigt att fatta beslut med hjälp av partiell information, tillämpa identifiering av driftläge och klusterering samtidigt. En avvägning bör göras mellan hur många olika scenarier och driftlägen som kan hanteras under identifieringsprocessen och hur korrekt identifieringen är. Det optimala antalet scenarier beror på många faktorer, inklusive deras avsedda användning. Förutom bottom-up-metoden, som först identifierar en stor uppsättning av applikationens driftlägen och därefter försöker kombinera dem baserat på likhet, finns det också en top-down-strategi. Detta tillvägagångssätt betraktar inledningsvis tillämpningen som ett enda scenario och delar sedan upp varje scenario på ett rekursivt sätt på grundval av skillnaderna mellan de driftlägen som den omfattar. De två tillvägagångssätten är inte i grunden olika; de är bara olika sätt att genomföra scenariot identifiering. För MP3 fallstudie, kan vi titta på ett sätt att minska en sekventiell streaming ansökans energiförbrukning genom att utnyttja dynamisk spänning och frekvensskalning (DVFS) i moderna processorer. För hårda realtidsbegränsningar använder vi en statisk analys för driftläge och scenarioidentifiering, förstärkt med en profileringsmetod för att välja de vanligaste scenarierna som visas under systemanvändning. För mjuka realtidsbegränsningar, är profilering grunden för identifiering eftersom det kan ge den mest korrekta bilden av systemutnyttjande. För att samla in intern applikationsinformation (t.ex. applikationsstruktur eller variabler) kombinerar vi dock profilering med statisk analys. Steg 2 Runtime scenario detektor eller prediktor härledning är det steg som avgör vilket scenario ansökan körs i vid en viss tidpunkt. Vi kan antingen upptäcka en ansökans nuvarande scenario på grundval av redan känd information (t.ex. variabla värden) eller förutsäga den med ett visst självförtroende. Påvisande kan ses som förutsägelse med 100% förtroende. Vid runtime, när en förändring i scenariot där programmet körs förutses, systemet växlar från det nuvarande scenariot till det nya, aktivera optimeringar för detta nya scenario. Det finns olika sätt att implementera prediktorer, såsom statiska kontra runtime adaptiv eller centraliserad kontra distribuerad. Oberoende av prediktorimplementationen kan vi använda följande information: runtime application intern information såsom variabelvärden och exekverad kod (t.ex. ett grundläggande block som endast visas i ett scenario); statistisk information som erhålls genom profilering eller från applikationsdesignern (t.ex. hur ofta ett scenario kan visas vid runtime); en probabilistisk scenario övergångsmodell såsom en Markov kedja; och en historia av aktiva scenarier i den aktuella körningen. Förutsägare kan vara av två typer: & Reactive. Endast information som redan har beräknats av programmet används. & Proaktiv. En del av applikationens kontrollflöde som följer prediktorn kopieras eller extraheras i prediktorns källkod. Det senare möjliggör ett tidigt beslutsfattande. Det finns en avvägning mellan mängden kod duplicerad och hur tidigt i genomförandet det aktuella tillämpningsscenariot kan förutses. Vanligtvis, ju tidigare desto bättre, men förutsägelsen overhead måste vara begränsad. För MP3-fallet studien exempel, kan vi överväga hur man härleda reaktiva centraliserade prediktorer med hjälp av tillämpningsvariabler som inte ändrar sina värden för en hel iteration av slingan av intresse, under både mjuka och hårda realtid begränsningar. Den plats där prediktorn kan infogas i applikationens källkod beror på de berörda variablerna och på var uppgifter om dessa variabler förekommer i loopkroppen. För hårda realtidsbegränsningar, extraherade vi prediktorn med hjälp av statisk analys, så det är i själva verket en statisk detektor. För mjuka realtidsbegränsningar använde vi den information som samlats in via profilering för att härleda prediktorn. För att garantera nödvändig systemkvalitet använde vi en kalibreringsmekanism som hjälper prediktorn att lära sig i farten, vilket gör den till en runtime-adaptive prediktor. Steg 3 Scenario utnyttjande använder scenarier för att optimera en design genom att tillämpa mer aggressiva optimeringar för varje scenario. Eftersom detta steg i hög grad beror på vad designern vill uppnå, undersöker vi flera papper som använder applikationsscenarier (ofta utan att uttryckligen definiera eller identifiera konceptet). Yang m.fl. Först identifierade man uttryckligen tillämpningsscenariot och använde det för att förbättra kartläggningen av dynamiska tillämpningar på en plattform med flera processorer. 2 Annat arbete tillämpar detta koncept flera gånger på ett ad hoc- sätt, med tonvikt på utnyttjande av scenarier, mestadels ignorera (automatisk) identifiering och förutsägelse. Sasanka, Hughes och Adve koncentrerade sig på att spara energi för en sekventiell tillämpning. 4 Den riktade arkitekturen har en enda processor med omkonfigurerbara komponenter (såsom antal och typ av funktionsenheter), och dess matningsspänning kan ändras. För varje manuellt identifierat scenario väljs den mest energieffektiva arkitekturkonfigurationen som fortfarande uppfyller tidsbegränsningarna. Det är oklart hur scenarier förutses i körtid. En förlängning tar hänsyn till två samtidiga resurser för scenariokarakterisering. 5 Det söker efter den mest energieffektiva konfigurationen för kodning video på en mobil plattform, utforska kompromissen mellan beräkning och komprimering effektivitet. Nyligen har forskare också använt scenarier inom ramen för ramen för geometrisk-slinga-omvandling för att utvidga räckvidden för den geometriska modellens tillämplighet. 6 Detta arbete kombinerar profilering med den geometriska modellen för att hitta optimala scenarier för globala minnesoptimeringar. Tanken är liknande hyperblock schemaläggning, men på en mycket grövre nivå. Författarna upptäcker systematiskt driftlägen på grundval av profilering, och sedan grupperar de dem i scenarier på grundval av en avvägning mellan antalet minnesåtkomster och ökningen av kodstorleken. I samband med multitask applikationer, Lee, Yoo, och Choi också undersökt med hjälp av tillämpningsscenarier för att minska den energi som förbrukas av en multitask ansökan kartlagt på en spänningsskalning-aware processor. 7 Murali m.fl. Karaktärisera scenarier efter olika kommunikationskrav (t.ex. bandbredd och latens) och trafikmönster. 8 De presenterar en metod för att kartlägga applikationskommunikation till en nätverks-on-chip arkitektur, som uppfyller konstruktionsbegränsningarna i varje enskilt scenario. Forskare har också använt scenarier för att förbättra operativsystemet. Mamagkakis, Soudris och Catthoor presenterade ett sätt att optimera dynamisk minnesallokering för IPv4-skiktet i ett trådlöst IEEE 802.11b-nätverksprogram. 9 Deras metod använder olika tilldelningsalgoritmer för olika scenarier, identifiera dessa scenarier på grundval av de möjliga nätverkspaketstorlekar. Det mesta av det arbete vi har nämnt hittills betonar scenarioexploatering för en viss applikation, inte för en klass av tillämpningar, och går inte in i detalj på identifiering och förutsägelse, som är viktiga ämnen i vårt arbete. De olika klasserna av inbyggda system (hård kontra mjuk realtid) och designproblem som optimeras leder till flera möjliga kriterier som vi kan använda för scenarioklassificering. Med tanke på hur scenarioomkopplare körs vid drifttid kan två huvudscenariokategorier övervägas: dataflöde och händelsedrivning. Dataflödesdrivna scenarier karakteriserar olika utförda åtgärder i ett program som väljs vid körning baserat på indataegenskaperna (t.ex. typ av strömmande objekt). Vanligtvis har varje scenario sin egen tillämpning inom applikationens källkod. Händelsedrivna scenarier väljs vid drifttidpunkten på grundval av händelser utanför programmet, t.ex. användarförfrågningar eller systemstatusändringar (t.ex. batterinivå). De karakteriserar vanligtvis olika kvalitetsnivåer för samma funktionalitet (eller kvalitetsscenarier), som kan implementeras som olika algoritmer eller kvalitetsparametrar i samma algoritm. De två typerna av scenarier kan bilda en hierarki. För olika kvalitetsnivåer kan ett dataflödesdrivet scenario kräva olika mängder resurser för samma tillämpningskod. De runtime switchs som uppstår mellan scenarier är differentierade av den tolerabla mängden biverkningar. Vanligtvis, i dataflödesdrivna scenarier, biverkningar är oacceptabla, medan i händelsedrivna scenarier, olika potentiella biverkningar kan vara godtagbara. Till exempel kan en övergång mellan kvalitetsscenarier i en TV visas som en bildformat förändring (från 4:3 till 16:9), med en godtagbar bieffekt av bild flimring under systemomkonfigurering. Men när TV-mottagaren byter från ett dataflödesdrivet scenario till ett annat, är inga biverkningar som synligt påverkar bilden acceptabla. Eftersom designmetoder för enskilda och multitask-system fokuserar på olika aspekter, kan scenarier också klassificeras som intratask-scenarier, som förekommer inom en sekventiell del av en applikation (dvs. en uppgift) och intertask-scenarier för multitask-tillämpningar. Denna klassificering är också hierarkisk. Vanligtvis är scenariot där ett multitask-program körs härledd från de scenarier där varje applikationsuppgift för närvarande körs. Dataflödesdrivna intratask- och intertaskscenarier är begreppsmässigt desamma från resursanvändnings- och runtime-switching-perspektiv, men de har olika effekter på intratask- och intertask-delarna av designflödet, och de utnyttjas vanligtvis på olika sätt. Slutligen, scenarioanvändning skiljer sig åt för mjuka och hårda realtidssystem. Inte alla metoder som vi har presenterat för varje steg i metoden kan alltid tillämpas. Till exempel, för hårda realtidssystem, kan scenarioidentifiering endast använda statisk analys, och endast detektorer kan användas för att identifiera det aktuella scenariot vid körtid. Men för mjuka realtidssystem kan vi använda prediktorer och statistisk information från profilerare. För MP3-studien koncentrerar vi oss på intrataskdatadrivna scenarier, både under mjuka och hårda realtidsbegränsningar. Eftersom varje scenario karakteriserar avkodningen av en ljudprovtyp, och en ström innehåller olika urvalstyper, ser vi till att det inte finns några biverkningar under bytet. Vi har utvecklat en automatisk scenariobaserad bana för ett specifikt designproblem: identifiering, förutsägelse och utnyttjande av tillämpningsscenarier för att minska den energi som förbrukas av en singletask strömmande applikation som körs på en DVFS-medveten processor. DVFS är en effektiv energibesparande teknik som innebär att en processors frekvens och spänning varierar vid körtiden beroende på bearbetningsbehov. De flesta algoritmer som är integrerade i våra verktyg är generella, och de kan användas för olika problem. Vår bana fungerar för både hårda och mjuka realtidsbegränsningar. Det börjar från en ansökan skriven i C, eftersom C är det språk som används mest för att skriva inbäddade system programvara. Banan genererar den slutliga energi-medvetet genomförande i C också. Våra numeriska resultat hänvisar till energiförbrukningen hos en Intel XScale PXA255-processor, mätt med hjälp av XTREM-simulatorn. 10 Vi anser att processorn frekvens (f CLK ) kan ställas in diskret inom processorns driftsområde i 1-MHz steg. Matningsspänningen (V DD ) anpassas i enlighet därmed: där V T 5 0,3 V och konstant k 5 208,3 beräknas för V DD 5 1,5 V och f CLK 5 200 MHz. Vi övervägde en frekvens och spänning övergång overhead t switch 5 70 ms, under vilken processorn stannar igång. Den energi som förbrukas under denna övergång är 4 mJ. När processorn inte används växlar den till ett tomgångstillstånd inom en cykel, och den förbrukar en tomgångseffekt på 63 mW. Denna situation uppstår om avkodningen av ett strömmande objekt kräver mindre beräkningscykler än beräknat. För vår utvärdering, ansåg vi ett riktmärke bestående av en slumpmässigt utvald uppsättning av 20 stereo och 10 monoströmmar eftersom stereo låtar oftare lyssnar på än mono låtar. Svårt i realtid. Vår bana kan generera olika energibesparande implementationer, från en rent statisk till en implementation som använder en finkornig DVFS-medveten schemaläggare. Figur 4 visar en jämförelse. Eftersom hårda realtidssystem kräver en konservativ design, utvecklade vi en metod och ett verktyg som använder en statisk analys av applikationens källkod för att identifiera och utnyttja scenarier för att minska överskattningen i det värsta möjliga antalet utförandecykler (WCEC) jämfört med befintliga metoder. 11 I scenarierna inkorporerade korrelationer som skiljer mellan källkodsdelar som aldrig utför tillsammans i samma iteration av slingan av intresse och de som kan. För att undvika en explosion i antalet upptäckta scenarier, vårt verktyg extraherar korrelationer med hjälp av endast information om de automatiskt upptäckta tillämpningsparametrar med stor inverkan på genomförandetiden. För MP3-dekodern minskades det uppskattade WCEC-värdet för hela applikationen, vilket är det maximala värdet mellan de som erhållits för varje scenario, med 9,3 %. I hårda realtidssystem kan inga deadlines missas, och processorn måste utföra åtminstone WCECs per avkodningsperiod för ett ljudprov. Således kan processorn frekvensen sänkas med 9,3%, vilket sparar 19% i energiförbrukning när avkodning vår audio-stream riktmärke. Genom att utnyttja de olika WCEC för varje scenario kan vi ytterligare minska energin. Vår bana kan generera en proaktiv prediktor som fungerar som en DVFS-medveten grovkornig schemaläggare. Denna schemaläggare väljer processorn frekvens och matningsspänning nivå en gång per loop iteration. För vårt riktmärke var energiminskningen 29 procent jämfört med referensgenomförandet. Vår bana kan också öka scenarier i en finkornig schemaläggare som ändrar processorfrekvensen flera gånger under en iteration av slingan av intresse. Genom att kombinera scenarier med en toppmodern finkornig DVFS-medveten schemaläggare för hårda realtidssystem, 3 minskade vi den genomsnittliga energin med 12% jämfört med att bara använda den finkorniga DVFS-medvetna schemaläggaren, och med 35% jämfört med den ursprungliga referensen. Finkornig DVFS ger bättre resultat än grovkornig DVFS om tiden för frekvensväxling är tillräckligt liten i förhållande till perioden för applikationsslingan av intresse. För större bytestider, finkornig DVFS är ogenomförbar eller grovkornig DVFS överträffar den. Mjukt i realtid. För mjuka realtidssystem är en viss deadline miss ratio acceptabelt, så att använda en konservativ bana leder till ett överdimensionerat system. Därför förfinade vi vår bana för att även överväga information som samlats in genom profilering av ansökan. I ett tidigare arbete, 12 beskrev vi en metod och ett verktygsflöde som automatiskt kan upptäcka de viktigaste tillämpningsparametrarna för att definiera och dynamiskt förutsäga scenarier i mjuka realtidssystem. Resultaten av att tillämpa denna bana till MP3-fallet sammanfattas i figur 5. Banan infogar tre komponenter i applikationens källkod (se figur 6 ): en prediktor, en kopplingsmekanism, och en körtid kalibreringsmekanism. Den tredje komponenten finns inte i det svåra realtidsfallet, och det är en mekanism som justerar prediktorn för att hålla missförhållandet under en given tröskel. Denna mekanism är nödvändig eftersom det är svårt, eller nästan omöjligt, att under profilering täcka alla möjliga driftlägen där ett system kan köras. Denna mekanism hjälper prediktorn att lära sig vid körning om nyupptäckta driftlägen. Med hjälp av den genererade koden minskas den genomsnittliga energi som förbrukas av MP3-dekodern med 16 % jämfört med referensen utan scenarier, för ett uppmätt missförhållande på aldrig mer än ett ljudprov per 6 minuter (0,08 %). Jämfört med den maximala energiminskningen som kan uppnås (se Oracle i figur 5 ), har vi nått ca 50% av den teoretiskt möjliga 587 minskningen. Vi planerar att ytterligare minska energiförbrukningen genom att utveckla en mer intelligent kalibreringsmekanism. För denna kärna utförde vi samma experiment som för MP3-dekodern. Under hårda realtidsbegränsningar sparade vi upp till 69 procent med en grovkornig schemaläggare och upp till 75 procent med en finkornig schemaläggare, jämfört med referensgenomförandet. I det mjuka realtidssammanhanget var besparingarna upp till 16 %, vilket motsvarar cirka 50 % av den teoretiskt möjliga minskningen.
Gheorghita m.fl. I de föreslagna tillämpningsscenarierna som ska användas med energistyrning.
Application Scenarios in Streaming-Oriented Embedded System Design
{'venue': '2006 International Symposium on System-on-Chip', 'journal': '2006 International Symposium on System-on-Chip', 'mag_field_of_study': ['Computer Science']}