Difference between revisions of "Detailed studies"
(→Replacement Chain) |
(→Introduction) |
||
| Line 8: | Line 8: | ||
=== Introduction === | === 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. | 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: | Lo scopo principale è quello di testare tutti i casi in cui si verifica un replacement L2, come descritto in figura: | ||
Revision as of 17:36, 25 September 2017
This page contains all the experience from the user that have worked on nu+ architecture and want to share all the acquired experiences
Contents
- 1 Fused multiply-add inside the microarchitecture
- 2 Replacement L2
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.
