Värdecache-kodning
Strömförbrukningen blir allt viktigare för både inbyggda , mobila datorer och högpresterande system. Off-chip databuss förbrukar en betydande del av systemets ström. Det observeras att off-chip-databussen förbrukar mellan 9,8 % och 23,2 % av den totala effekt som förbrukas av systemet beroende på systemet. Så en minskning av strömförbrukningen för off-chip-databussen skulle minska den totala strömförbrukningen.
Introduktion
Off-chip-bussar är associerade med högre kapacitansvärden interna nodkapacitanser och därför är tekniker för att minimera omkoppling vid extern adress och databussar, även på bekostnad av en liten ökning av omkoppling vid interna kapacitanser, ganska användbara. Effektförbrukning från chip kan reduceras genom åtminstone dessa två tekniker: genom att minska antalet busslinjer som aktiveras under dataöverföring och genom att minska antalet bitövergångar på de aktiva busslinjerna. En blandning av båda dessa tekniker ger optimalt resultat. Värdecache-kodning är ett schema som används för att minska strömförbrukningen i off-chip-databussen. I detta schema används cache på båda sidor av databussen för att minska den dynamiska effektförlusten på databussar utanför chipet. Dessa cacher underhålls så att deras innehåll är detsamma hela tiden.
Schema Detaljer
I det här protokollet använder vi en liten cache (kallad värdecache, eller VC för kort) på varje sida av off-chip-databussen. Dessa värdecacher håller reda på de datavärden som nyligen har sänts över bussen. Posterna i dessa cachar är konstruerade på ett sådant sätt att innehållet i båda värdecacharna är detsamma hela tiden. avsändarens värdecache ( om det är minne eller cache). Om så är fallet sänder vi endast indexet för datan (dvs dess värdecacheadress eller index) istället för det faktiska datavärdet och den andra sidan (mottagaren) kan bestämma datavärdet genom att använda detta index och dess värdecache . För att överföra data i värdecachen med användning av endast 1-bits växlingsaktivitet, är storleken på värdecachen begränsad till databussens bredd. Det vill säga, med en 32-bitars buss kan VC:n bara ha 32 poster. Eftersom värdecachen som används av vårt kraftprotokoll är mycket små, är bredden på indexvärdet mycket mindre än bredden på det faktiska datavärdet. Följaktligen behöver färre off-chip-busslinjer aktiveras för överföring. Vårt tillvägagångssätt försöker uppnå det första alternativet genom att utnyttja lokaliteten för datavärdena som kommuniceras över off-chip-databussen. Men när bredden på datan (som behöver överföras) har minskat, kan vi också förvänta oss en minskning (i allmänhet) av den genomsnittliga bitväxlingsaktiviteten per överföring. Dessutom kan denna omkopplingsaktivitet reduceras ytterligare genom att använda välkända busskodningsscheman i samband med vår strategi
Cachekonsistens
Mottagarsidan kör samma placerings- och ersättningspolicy för VC som avsändaren. Således kopieras värdet av datan som sänds över bussen i mottagaren VC på samma indexplats, som i sändaren VC. Vi använder en extra kontrollbit för att indikera om data som skickas över bussen är ordagrant data eller ett index till VC. En minnesskrivaktivitet hanteras på liknande sätt.
Exempel
Vi antar att värdena 100 och 200 initialt inte finns i VC. Under transaktion #1 skickas A från minnet till cachen. Den begärda dataposten, lagrad på någon adress (säg adress X i minnet) har ett värde 100. Minnesstyrenheten söker efter VC:n efter värdet 100 och detekterar en miss. Därför skickas värdet 100 över off-chip-databussen. Dessutom, enligt vårt effektprotokoll, lagras värdet 100 på samma plats (säg 5) av VC:erna för både källan och destinationen. För transaktion #2 minnesstyrenheten efter värdet 200, kan inte hitta värdet i VC:n och upprepar stegen som beskrivits ovan. Vid denna tidpunkt innehåller värdecachen i båda ändarna datavärdena 100 och 200. I transaktion #3 finner minnesstyrenheten att ett värde 100 måste skickas för att betjäna en läsbegäran (av samma minnesplats som tidigare, eller av en annan minnesplats som har samma värde). Men notera att värdet 100 redan finns i VC:n för avsändaren på plats 5 som ett resultat av transaktion #1. Därför, istället för att skicka värdet 100, skickar minnesstyrenheten bara indexvärdet 5. Mottagaren, å andra sidan, hämtar värdet av den faktiska datan (100 i detta fall) från plats 5 i dess VC. Slutligen, i transaktion #4, vill vi skicka dataposten D som har ett värde 200 till minnet (dvs en skrivbegäran). Men värdet 200 är redan cachelagrat i båda VC:erna som ett resultat av transaktion #2 från minne till cache. Följaktligen används indexet till den cachade kopian (närvarande i VC) av värdet 200 för att slutföra transaktion #4 men i motsatt riktning. Denna sista transaktion visar att data som placerats i VC under en transaktion i en riktning kan återanvändas (från VC) under en transaktion i omvänd riktning.
Ersättningspolicy
LRU används som ersättningspolicy i båda cacharna. Den implementeras med hjälp av referensbitar och en n-bitars tidsstämpel för varje värde som lagras i cachen. När ett värde visas i ingången sätts referensbiten. Med regelbundna intervall skiftas referensbiten rätt till högordningens bitposition för n-bitars tidsstämpel vilket gör att alla bitar i tidsstämpeln också skiftas åt höger och att den lägsta ordningens bit i tidsstämpeln förkastas. Till exempel betyder tidsstämpel 000 att detta värde inte visades under de tre senaste tidsintervallen, tidsstämpel 100 betyder att det just sågs i det senaste intervallet, och tidsstämpeln 000 med referensbitar betyder att det påträffas i den aktuella tidsluckan. Operation som nämns ovan utförs på alla poster i båda cacharna med alla referensbitar återställda. Tidsstämpeln behåller således historiken för värdeförekomster för de senaste n tidsperioderna. När en post krävs och ett värde ska vräkas, är den post som väljs den som har minst tidsstämpel och tydlig referensbit. Det nya värdet läggs in med en ny referensbit och tidsstämpel (alla 0:or) i denna valda post.
Typ av värdecache
Efter att ha beskrivit protokollet kommer vi nu att se två metoder för att underhålla cache:
- Båda cacharna kan initieras med hjälp av en fast uppsättning värden beroende på hur ofta värdena har förekommit i föregående körning.
-
En föränderlig uppsättning frekventa värden kan bibehållas medan programmet körs. Sålunda anpassar sig innehållet i de frekventa värdetabellerna till förändringar i de frekventa värdena för olika delar av exekveringen. Fördelen med att fylla cache med ett fast värde är att kodarna inte behöver ändra innehållet i tabellen dynamiskt, vilket minskar runtime overhead. Det kräver dock att värdena är kända i förväg och olika program behöver olika värden. Den andra metoden, å andra sidan, behöver inte a priori information om datavärden och gör inte åtskillnad mellan olika program. Med dessa funktioner betalar vi priset för
identifiera de vanliga värdena i farten.
Annan applikation
Protokollet vi diskuterade användes på buss vars ena ände är on-chip cache och andra änden var off-chip minne , det är möjligt att anpassa vår strategi för att fungera med en off-chip L2 cache också. Dessutom kan strömprotokollet också användas för att minska växlingsaktiviteten mellan on-chip L1-cache och on-chip L2-cache (även om resultaten inte skulle vara lika bra som de med off-chip-bussen). Faktum är att vår strategi kan användas mellan två valfria kommunicerande enheter i systemet (med VC-stöd). Vidare är vi inte begränsade av punkt-till-punkt-konfigurationer. Det vill säga, vårt tillvägagångssätt kan fås att fungera i en miljö där flera enheter kommunicerar över en delad (strömkrävande) databuss. Uppenbarligen skulle vi bland annat i det här fallet behöva en koherensmekanism (vars diskussion ligger utanför detta dokuments räckvidd). En nackdel med vår strategi är det extra utrymme som behövs för två värdecacher (en on-chip och den andra off-chip). I det här dokumentet presenterar vi inte en detaljerad studie av kretsutrymmeskonsekvenserna av vårt tillvägagångssätt. Som kommer att presenteras i avsnittet med experimentella resultat, genererar även en liten VC (128 poster) någorlunda bra energibeteende; så vi kan förvänta oss att utrymmet på grund av vår optimering inte kommer att vara överdrivet stort.