Detailed studies

This page contains all the experience from the user that have worked on nu+ architecture and want to share all the acquired experiences

Fused multiply-add inside the microarchitecture

Vincenzo

Replacement L2

Introduction

In questo Capitolo si intende mostrare come si svolge la Replacement Chain relativamente alla cache L2, osservando come il Directory Controller evolve per gestire l’occorrenza di tale casistica. Lo scopo principale è quello di testare tutti i casi in cui si verifica un replacement L2, come descritto in figura:

Memory in Directory Controller

Per poter comprendere al meglio come funziona il meccanismo di replacement è necessario in primis valutare come è strutturata la cache amministrata dal Directory Controller. La seguente descrizione rappresenta la configurazione utilizzata per tutti gli esperimenti. Come possiamo osservare dalla figura la cache è costituita da quattro way e 64 set, ogni way contiene al proprio interno un tag e un dato (64 bit).

Gli indirizzi gestiti sono di 32 bit e sono organizzati come descritto in figura:

Ogni directory controller può quindi gestire un numero limitato di indirizzi, ad esempio la Tile 0 può gestire gli indirizzi da 0x00000000 a 0x3fffffff, la Tile 1 da 0x4000000 a 0x7fffffff, e così via. Negli esperimenti trattati vengono utilizzate quattro Tile.

Replacement Chain

Per poter causare un replacement è necessario riempire tutte e quattro le way relative ad un determinato set: all’atto dell’inserimento di una nuova entry nello stesso set viene realizzato il replacement. Per una questione di semplicità è necessario scrivere il codice da eseguire direttamente in Assembly all’interno dei kernel utilizzati, per avere un maggiore controllo sulle operazioni effettuate e sugli indirizzi di memoria utilizzati. L’operazione di replacement è gestita in maniera tale da rimpiazzare direttamente la entry LRU senza invalidare la linea di cache su cui effettuare il replacement, demandando le operazioni di invalidazione (verso i cache controller) ad una successiva fase. Per poter stabilire che si sta verificando un replacement è necessario osservare il segnale do replacement. Tale segnale è alto solo se

do replacement = dc2 message valid && ((allocate cache | | update cache) && !deallocate cache) && !is replacement && !dc2 message cache hit && dc2 message cache valid;

quindi se il dc2 ha processato una richiesta diversa da un replacement e che non causi la deallocazione di una linea di cache, se non si è verificato un hit all’interno della cache allora sarà necessario eseguire un replacement. A seguito dell’asserzione del segnale do replacement si scatena l’enqueue della richiesta di replacement all’interno della relativa coda attraverso il segnale dc3 replacement enqueue, inserendo in tale coda anche il contenuto della linea di cache su cui effettuare il replacement:

dc3_replacement_enqueue                    	= dc2_message_valid && do_replacement;
assign dc3_replacement_request.source          = dc2_message_source,
dc3_replacement_request.memory_address.tag  	= dc2_message_cache_tag,
dc3_replacement_request.memory_address.index  	= dc2_message_address.index,
dc3_replacement_request.memory_address.offset 	= 0,
dc3_replacement_request.data                 	= dc2_message_cache_data,
dc3_replacement_request.state                 	= dc2_message_cache_state,
dc3_replacement_request.sharers_list          	= dc2_message_cache_sharers_list,
dc3_replacement_request.owner                 	= dc2_message_cache_owner;

Si tenga conto che dc2 message address.index contiene l’indice dell’LRU prelevato dallo stadio 2. Così come descritto all’interno della documentazione del Directory Controller, lo Stage 1 contiene uno scheduler a priorità fissa che comporta la processazione con massima priorità delle replacement request se la condizione can issue replacement request è verificata. Oltre ai soliti segnali lo Stage 1 trasmette allo Stage 2 i segnali:

dc1 replacement state <= output replacement state;
dc1 replacement sharers list <= output replacement sharers list;
dc1 replacement owner <= output replacement owner;

Tali segnali vengono inoltrati dallo Stage 2 allo Stage 3. Nello Stato 3, in cui avviene l’effettiva processazione della richiesta, viene effettuato il replacement, così come definito all’interno della Protocol ROM a seconda dello stato in cui ci si trova.

Replacement di una linea nello Stato M

Per poter testare il replacement di un blocco nello stato M e valutare i segnali principali descritti nella relativa documentazione, per quanto rigurda il Directory Controller, è stato costruito il seguente kernel:

if(tile_id==0){	
 asm( 	
  "moveih s20, 0x0000"
  "moveil s20, 0x0000"
  "store32 s21, (s20)"
		
  "moveil s20, 0x1000"
  "store32 s21, (s20)"
  
  "moveil s20, 0x2000"
  "store32 s21, (s20)"	
 );
}else if(tile_id==1){
 asm( 	
  "moveih s20, 0x0000"
  "moveil s20, 0x4000"
  "store32 s21, (s20)"
  
  "moveil s20, 0x8000"
  "store32 s21, (s20)"
 );
}

In questo caso la Tile 0 esegue tre store e la Tile 1 ne esegue 2. Per poter distinguere le diverse richieste si osservi il segnale dc1 message valid in figura, tale segnale è asserito quando lo scheduler a priorità fissa preleva una delle richieste dalla rispettiva coda.

Come si può evincere dalla simulazione i messaggi vengono processati dal Directory Controller nel seguente ordine:

• 1. store della Tile 1 all’indirizzo 0x00004000
• 2. store della Tile 0 all’indirizzo 0x00000000
• 3. store della Tile 1 all’indirizzo 0x00008000
• 4. store della Tile 0 all’indirizzo 0x00001000
• 5. store della Tile 0 all’indirizzo 0x00002000

Le richieste sono state effettuate in modo tale da appartenere allo stesso set, così da scatenare il replacement.