Front-End condiviso
Come abbiamo scritto l'instruction fetch e gli stadi di decodifica di Bulldozer sono condivisi tra entrambi i core. AMD usa un multi-threading intervallato per monitorare l'ID del thread di ogni istruzione in circolo, decidere quale thread ha più bisogno che il lavoro sia completato ed eseguire un'operazione per conto di quel thread. È in grado di passare a una base per ciclo per far sì che i progressi avanzino su entrambi i thread.
AMD disaccoppia il branch target predictor dall'instruction fetch, quindi la sua esecuzione può essere prioritaria e indipendente da eventuali intoppi della pipeline delle istruzioni. La cosa più importante, secondo AMD, è che disaccoppiare questi componenti abilita una funzione chiamata prediction-directed instruction prefetch, caratterizzata da un livello elevata di accuratezza ed efficienza energetica.
Il branch prediction è guidato dal branch target buffer (BTB) L1 a 512 voci ed L2 a 5000 voci. Questa pipeline è responsabile della previsione e del riempimento degli indirizzi "futuri", e ha anche la funzione di mantenere la coda il più piena possibile. Ci sono attualmente due code - una per ogni thread - che assicurano che ci sia sempre lavoro da fare. La coda delle istruzioni (instruction fetch pipeline) poi "pesca" gli indirizzi dalle previsioni (prediction queue) ottenute in questo modo.
Questi indirizzi entrano nella cache delle istruzioni a due vie di 64 KB della pipeline fetch. Questa cache è condivisa tra entrambi i thread (i thread competono dinamicamente per accedervi). Successivamente la fetch queue di Bulldozer inserisce istruzioni x86 in una pipeline di decodifica composta da quattro decoder x86 che, a loro volta, inviano fino a quattro operazioni per ciclo verso gli scheduler.
Clicca per ingrandire
Quando appare una voce mancante nella cache delle istruzioni previste (miss) si attiva una richiesta verso la cache L2, e se necessario alla memoria di sistema. Questo comporta un grande aumento di latenza. Così, mentre la richiesta viaggia, pesca altri indirizzi nella prediction queue, e ne verifica l'attendibilità - verificando cioè se c'è un hit oppure un miss. Se saranno ancora dei "miss", una successiva richiesta è inviata a L2 quando la prima istruzione torna indietro, sovrapponendo le richieste di istruzioni miss.
Due core integer
Dal front-end, le operazioni decodificate fanno la loro strada verso uno dei due core integer indipendenti, dove sono eseguite completamente out-of-order. I due core sono ognuno equipaggiato con due unità di esecuzione e due unità di generazione indirizzi.
Clicca per ingrandire
Ogni core inoltre ha una propria cache dati L1 da 16 KB way-predicted. Entrambi i core includono anche un translation lookaside buffer (TLB) dati L1 a 32 voci, spalleggiato da un TBL L2 a 1024 voci e otto vie logico (cioè non fisico) e condiviso. Infine ognuno dei due core integer usa unità di carico/archiviazione out of order capaci di sostenere due carichi/cicli a 128 bit o un ciclo/archiviazione a 128 bit.