Per quanto riguarda il processo produttivo con cui GlobalFoundries realizza Trinity, nulla è cambiato rispetto al precedente Llano per cui ritroviamo la litografia a 32 nm. Tuttavia i core Piledriver e le GPU Northern Islands contengono più transistor, per cui AMD si è trovata davanti a una prima, grande sfida, ossia riuscire a integrare tutto ciò in un die che non fosse eccessivamente più grande rispetto al precedente. Sfida che può dirsi vinta, in quanto la superficie di Trinity è ora di 246 mm² contro i precedenti 228 mm²: un incremento del 7 % a fronte però di un aumento prestazionale ben più consistente, pari a circa il 50% in più sia per CPU che GPU, un traguardo non da poco, che fa ben sperare AMD, che conta di riuscire con Trinity a sostenere meglio il confronto con i nuovi processori Intel Ivy Bridge rispetto a quanto sia riuscita a fare Llano al confronto di Sandy Bridge.
Se infatti le prestazioni legate alla GPU integrata erano in entrambi i casi molto superiori a quelle ottenibili con le soluzioni concorrenti, altrettanto non si poteva dire per Llano quando invece si andavano a comparare le prestazioni legate alla sola CPU. Con Piledriver comunque AMD ha lavorato in maniera evolutiva rispetto al precedente Bulldozer, migliorandone tutte le caratteristiche ma senza rivoluzionarlo. Se guardiamo infatti il diagramma a blocchi, l'architettura fondamentale è rimasta immutata. Come in Bulldozer infatti troviamo ancora la stessa struttura, con due integer unit, ciascuna con la propria cache L1, il proprio scheduler e le proprie unità di esecuzione. Condivisa tra le due integer unit cìè poi un'unità di calcolo in virgola mobile. Ogni modulo così formato è visto dal sistema operativo come se fossero due core, ma ovviamente il risultato non è lo stesso che se si avessero due core tradizionali.
La situazione, così descritta, può però sembrare peggiore di quanto non sia in realtà. Si tratta infatti semplicemente di approcci differenti. Poiché è molto raro che si raggiungano picchi di utilizzo delle risorse hardware così elevati, AMD ha semplicemente preferito ottimizzare l'uso di risorse più limitate, mentre Intel ha sempre optato per soluzioni più "muscolari", aumentando a dismisura la quantità dei transistor e le strutture di calcolo. Inoltre AMD è in parte costretta a questa soluzione per restare fedele alle proprie scelte architetturali. Limitando le unità a virgola mobile della porzione x86 delle proprie APU infatti lascia più spazio alle strutture della GPU dedicate allo stesso scopo, che svolgono però in maniera decisamente più efficace, proprio per la loro natura intrinseca, dato l'alto parallelismo di queste architetture.
Seppure, come detto, lo schema fondamentale di Piledriver non sia cambiato rispetto a quello di Bulldozer, buona parte dell'intervento di perfezionamento dell'architettura effettuato dagli ingegneri di AMD ha riguardato la sua efficienza energetica. Il risultato è che Piledriver consuma in media il 10% in meno del suo predecessore, con picchi massimi del 20% sotto alcuni carichi di lavoro.
Altri miglioramenti sostanziali hanno riguardato il prefetching e l'algoritmo di branch prediction. Queste modifiche sono opportunamente supportate da una cache L2 più efficiente e da una cache L1 TLB (Translation Look-aside Buffer) di maggiori dimensioni. Al tempo stesso sono state ottimizzate le unità di scheduling sia per le unità di calcolo sugli interi che in virgola mobile e le SLF (Store-to-Load Forwarding), mentre la Icache, ossia la finestra che contiene le istruzioni, è ora più ampia. Infine sono state introdotte nuove istruzioni come le FMA3 o le F16C, necessarie per competere sullo stesso livello con l'ISA di Haswell.
All'interno di uno schema eterogeneo come quello adottato da AMD per le proprie APU, acquista importanza determinante il modo in cui le varie parti sono interconnesse fra loro. Con l'architettura HSA (Heterogeneous System Architecture), AMD si pone l'obiettivo di fondere in un unico design gli elementi di CPU, GPU e northbridge, stampandoli poi su un unico pezzo di silicio. Al momento siamo ancora lontani da questo traguardo tuttavia le diverse componenti possono già ora accedere a determinati spazi di memoria che contengono istruzioni condivisibili. Il Fusion Controller Link consente alla GPU di accedere allo spazio di memoria dedicato ai processi condivisi con la CPU e a quest'ultima di accedere al framebuffer della prima. FCL ha un'ampiezza di 128 bit in ciascuna direzione.
AMD Radeon Memory Bus invece consente alla GPU di accedere al northbridge e quindi alla memoria di sistema ed ha un'ampiezza di 256 bit per ciascuna direzione per ogni canale. Infine troviamo IOMMU v2 che permette l'accesso diretto da parte di un'eventuale GPU dedicata allo spazio di memoria virtuale dei core del processore. Con Llano infatti era necessario in questo caso prelevare i dati dall'hard disk, copiarli nella memoria di sistema, trasferirli nella porzione della memoria della CPU accessibile anche alla GPU e infine copiarli nel frame buffer di quest'ultima. Grazie invece a IOMMU v2 i dati, una volta giunti nella memoria della CPU, possono essere letti direttamente dalla GPU, saltando così diversi passaggi intermedi, con un conseguente aumento delle prestazioni che può essere facilmente intuito.
Il controller di memoria, dal canto suo, è di tipo dual channel a 64 bit per canale, con supporto alle DDR3 fino a 1866 MHz per quanto riguarda le APU per PC fissi e 1600 MHz per quelle destinate al segmento dei notebook. Inoltre anche le memorie a basso consumo LVDDR3 da 1.35 V o ULVDDR3 con voltaggio a 1.25 V sono ora compatibili. Il nuovo controller inoltre supporta fino a 32 GB di memoria per la versione destinata ai notebook e 64 GB per quella indirizzata ai PC desktop.
