Verso la metà degli anni '90 AMD, compresa ormai la propria importanza nel mercato consumer, decise di portare la battaglia con Intel su un nuovo livello, quello delle Workstation e dei Server Low End (a 2 o 4 processori). Per fare questo, però, avrebbe necessitato di una nuova architettura, ma soprattutto di un nuovo Bus (fino ad allora aveva utilizzato il vecchio Socket 7, aggiornato al Super 7, con annesso Bus PCI). Intel si era già portata avanti, sostituendo gli elementari Front Side Bus fino ad allora utilizzati, con il Bus GTL, acquistandone la licenza dalla Fairchild. Con il Pentium III fu poi migliorato (GTL+) così che potesse operare fino a 133 MHz, e con i Pentium 4 passò all'AGTL+. AMD allo stesso modo, per risparmiare tempo e denaro, acquistò la licenza del Bus EV6 da DEC per la propria architettura K7.
Con il passare degli anni, comunque, ci si accorse che entrambi questi FSB sarebbero risultati inadeguati per sistemi a 4 o più processori (in particolare i FSB basati su GTL), quindi sia AMD sia Intel decisero di realizzarne uno nuovo, adatto alle proprie esigenze. Intel portò all'estremo il disegno classico, realizzando il Quad Pumped Bus, così da limitare i difetti di bandwidth dell'AGTL+. AMD, al contrario, decise di cambiare completamente strada, realizzando l'HyperTransport. Più avanti descriveremo in cosa differiscono.
Quello che ora mi preme sottolineare è come, al tempo, l'HyperTransport fin da subito catturò l'attenzione delle più grandi grandi aziende e Università. Ci fu una vera e propria corsa per far parte dell'HyperTransport Consortium. Questo, alla fine, contò oltre cento partner, tra i quali possiamo citare Cisco, nVidia, IBM, Altera, HP, Xilinx, Broadcom, SiS, VIA, Oracle, Cray e la Chinese Academy of Sciences. Chiunque facesse parte di questo consorzio avrebbe potuto usufruire gratuitamente dell'HyperTransport.
Vi era una sola regola. Tutti avrebbero dovuto contribuire al suo miglioramento, ed ogni innovazione sarebbe stata a disposizione di tutti. Lo stesso principio del mondo GNU/Linux e dell'Open Source in generale, ma applicato ad una tecnologia hardware.
Quando AMD si mise a studiare l'erede del processore K6, in quel di Sunnyvale giunsero diversi ingegneri provenienti direttamente da DEC, l'azienda produttrice dei fantastici processori Alpha. A guidare questo piccolo gruppo di ingegneri c'erano Dirk Meyer e Jim Keller. Correva l'anno 1996.
Jerry Sanders, CEO di AMD, nel biennio 1995-1996 decise di smettere di rincorrere Intel: avrebbe voluto superarla tecnologicamente. Per far questo spinse sull'acceleratore sia nello sviluppo di nuovi processi produttivi (giunse ai 180nm prima di Intel, e con un nodo migliore), ma soprattutto investì nello sviluppo di architetture avveniristiche. Meyer e Keller avrebbero dovuto guidare AMD nello sviluppo di quest'ultime.
Common Clock
Source Synchronous Clock
Poiché AMD, nei piani di Sanders, si sarebbe dovuta inserire nell'altamente remunerativo settore delle CPU per Server Enterprise, gli ex ingegneri della DEC avrebbero dovuto creare un ecosistema hardware non solo migliore rispetto a quello Intel, ma anche più economico. Una sfida che molti ritenevano impossibile.
Meyer e Keller per sviluppare l'HyperTransport presero come base il Bus EV6, utilizzato come FSB di sistema per l'architettura K7. L'EV6 fu sviluppato da DEC per i propri processori Alpha, ed inizialmente era stato pensato per un impiego prettamente Enterprise. AMD lo portò nel mercato consumer.
Fino a quel tempo le configurazioni multi CPU x86 di Intel utilizzavano un Bus condiviso. Ciò significava che tutte le CPU in un sistema multi socket trasferivano e ricevevano i dati da un unico canale bidirezionale, e che la bandwitdh non sarebbe aumentata all'aumentare del numero di CPU, rimanendo costante. Questo aveva tre difetti, principalmente. Il primo di tipo tecnico. Poiché questo scambio dati era gestito dal chipset, nel caso vi fosse stata la saturazione della banda dati sarebbero aumentate notevolmente le latenze. Lo smistamento dei dati avrebbe portato le CPU a dover interrompere frequentemente il lavoro, in attesa di nuovi dati. Secondo problema, era la bassa bandwidth del Bus GTL+ tra CPU e NorthBridge, pari al massimo a 1066 MB/s nei sistemi Pentium III. In un sistema multi socket era facilmente saturabile, e quindi si sarebbe incontrata spessissimo la situazione descritta al punto uno. Terzo problema, era il costo di disegno delle schede madri. L'implementazione del Bus GTL+ nel PCB delle schede madri era molto costoso. Da un articolo di Anandtech: "Saturation of the 100MHz GTL+ bus happens most frequently in high-end workstations and servers, and is especially easy to point out in multiprocessor systems. The GTL+ bus is a shared bus, meaning that regardless of how many processors you have present in your system, they must all share the same 800MB/s of bandwidth. This is part of the reason that adding more than two processors to an Intel Xeon server begins to give you diminishing returns, and it is also part of the reason that many companies pursue multiple dual processor servers versus a handful of quad processor servers".
Diagramma Bus EV6
Il Bus EV6 limitò in parte questi problemi. Le CPU, in un sistema multi socket, erano collegate singolarmente al North Bridge tramite un canale esclusivo, ed ogni canale aveva una Bandwidth teorica pari a 1.6 GB/s (con Bus a 200 MHz). Questo permetteva alle CPU di comunicare in maniera esclusiva con il NB, evitando eventuali colli di bottiglia, ed al contempo abbassando notevolmente le latenze. La comunicazione tra NB e periferiche, per il momento, sarebbe avvenuta ancora attraverso il Bus PCI (AGP, nel caso delle GPU).
Specificità del BUS EV6 è la presenza di un Bus bidirezionale a 72 Bit, dove i dati in uscita ed i dati in entrata viaggiano su due canali fisicamente distinti, mentre la frequenza, limitata tra i 200 MHz e i 400 MHz (con una banda compresa tra gli 1.6 e 3.2 GB/s), consente la realizzazione di schede madri meno costose rispetto a quelle tradizionali. Il trasferimento del clock, inoltre, avviene contemporaneamente allo scambio dati (Source Synchronous Clock), diminuendo così le latenze ed aumentando l'efficienza: la lettura e la scrittura dei dati avvengono contemporaneamente. Il Bus utilizzato da Intel (prima il GTL+, poi l'AGTL+/QuadPumped) era invece basato sul sistema Common Clock: i dati vengono inviati a tutti i dispositivi, ed ognuno li elabora quando ne ha possibilità, aumentando così i problemi relativi alla latenza.
Negli anni seguenti Intel, per mitigare questo svantaggio, aumentò notevolmente la frequenza del Quad Pumped Bus durante l'evoluzione dei Pentium 4, raggiungendo infine gli 800 MHz (200MHz x4), così da aumentare la frequenza cui i dati venivano letti o scritti. AMD, al contrario, poté competere con un Bus di soli 400 MHz (200 MHz x2). Anche per questo le schede madri Socket A costavano meno di quelle Socket 478: il PCB era di più facile disegno e produzione.
Con il progetto SladgeHammer (K8), che avrebbe dovuto prendere il posto di K7, Meyer e Keller passarono ad uno step successivo. Legare con un Bus di tipo Source Synchronous Clock tutte le periferiche. Questo avrebbe permesso di realizzare sistemi multi CPU ancora più efficienti ed economici.
L'HyperTransport è stato creato per ridurre considerevolmente i colli di bottiglia dovuti a Bus antiquati, incapaci ormai di stare dietro alle CPU più recenti. Quando il progetto relativo all'HT fu deciso (seconda metà degli anni '90), vi erano già in commercio processori con una frequenza superiore ai 700 MHz, i quali però dovevano limitarsi ad un FSB di 133 MHz, a causa dei Bus PCI (66MHz) e AGP (100 MHz). Un FSB più elevato avrebbe portato pochi vantaggi se rapportati al costo di implementazione.
HyperTransport, grazie alla propria scalabilità, all'essere una connessione seriale (point-to-point) e non parallela, avrebbe provveduto a superare queste limitazioni, soprattutto nei settori embedded ed enterprise. L'idea era semplice.
Prima di tutto lo si sarebbe reso compatibile con tutti i Bus di I/O fino ad allora esistenti, così da garantirne la massima espansione commerciale. Per questo motivo l'HT sarebbe stato modulare. Il canale di comunicazione avrebbe potuto operare (inizialmente) in un range di frequenza tra i 200 e gli 800 MHz, mentre l'ampiezza di canale sarebbe stata a scelta tra i 2 e i 32 Bit (meno Bit erano necessari, meno sarebbe costato il disegno di quel canale sulla scheda madre). In questo modo sarebbe stato possibile utilizzare l'HT con tutti i Bus esistenti. Ad esempio, un Bus HT a 16 Bit operante a 800 MHz avrebbe potuto garantire una banda bidirezionale di 25.6 Gb/s, in grado di reggere il traffico dati di due controller Ethernet di classe Gigabit (10 Gb/s ognuno). Questo avrebbe eliminato completamente il collo di bottiglia dei Bus PCI (133 MB/s) e PCI-X (1064 MB/s), non solo più lenti, ma anche molto più costosi da implementare sul PCB delle schede madri.
"HyperTransport System Architecture", di Don Anderson e Jay Trodden
Non solo poteva garantire una minore latenza, ed una maggiore banda dati, ma l'HT poteva gestire un maggior numero di periferiche contemporaneamente. Il Bus PCI-X poteva gestire una periferica, il Bus PCI quattro contemporaneamente. L'HT, grazie al tunneling1, ne poteva gestire fino a 31, senza la necessità di un NorthBridge! Le uniche periferiche che sarebbero dovute passare attraverso il SouthBridge sarebbero state quelle di massa (EIDE e SATA), Audio e USB. CPU, memoria Ram, Scheda Video, CTRL SCSI e schede di rete avrebbero potuto comunicare tra loro attraverso un canale velocissimo e a bassissima latenza.
Network World, Luglio 2001
Grazie all'HyperTransport AMD non solo avrebbe avuto un Bus capace di far comunicare in maniera diretta e veloce le CPU in un sistema Multi Socket, ma avrebbe permesso un traffico dati diretto e veloce anche tra le CPU e le periferiche di quel sistema, senza che fosse necessario riscrivere il software. HyperTransport era infatti perfettamente retrocompatibile.
Il tutto a costi ridicolosamente bassi: essendo un sistema point-to-point, il disegno delle schede madri poté essere semplificato, diminuendone i costi di produzione. Una caratteristica che in ambito embedded e server è molto ricercata, a causa delle economie di scala.
1- Con "Tunneling" ci si riferisce alla possibilità di utilizzare il Bus HT per collegare tra loro due o più CTRL, a cascata. Un esempio è riportato nello schema qui sotto, relativo al chipset HT-2100 di Broadcom, in comunicazione con il CTRL HT-1100 (SouthBridge).
L'HyperTransport fu apprezzato fin da subito anche da chi, alla luce del sole, lo denigrava, come Intel. Sottobanco, invece, era studiato.
Non è un caso che Intel ed nVidia, per realizzare la prima XBoX, decisero di utilizzarlo. Poiché nVidia faceva parte dell'HyperTransport Consortium, Microsoft poté utilizzarlo senza pagare un centesimo di royalties. NorthBridge, SouthBridge e GPU, tutti prodotti da nVidia, erano collegati tramite l'HT, con tutti i vantaggi del caso: maggiore bandwitdh, minori latenze, minor costo del PCB della scheda madre dell'XBoX. Per collegare NorthBridge e CPU fu utilizzato il Bus AGTL+ di Intel, ma questo non creò problemi, in quanto tutto il resto era connesso tramite l'HyperTransport.
"Hacking the Xbox: An Introduction to Reverse Engineering", di Andrew Huang
Apple ed IBM utilizzarono il Bus HT per realizzare i Mac basati su architettura Power (G5), IBM lo utilizzò per realizzare i Server basati su Power 6 e 7, mentre Oracle lo utilizzò con le CPU Sparc T3 e T4. Cisco utilizzò l'HT nei propri Router.
Nel corso degli anni l'HT è stato continuamente aggiornato, ed oggi è giunto alla versione 3.1 (2008). Nonostante siano passati oltre 10 anni dall'introduzione, AMD continua ad utilizzarlo con i processori basati sull'architettura a moduli (CMT). Anche Oracle ed IBM non lo hanno sostituito, e con l'introduzione delle nuove architetture Sparc T5 e Power 7+ è ancora lì, a fare il suo sporco lavoro. L'HT è utilizzato ancora abbondantemente in ambito embedded, per le macchine industriali, grazie alla propria economicità e semplicità. Certo, in alcuni ambiti comincia a mostrare i segni del tempo, come ad esempio nei sistemi a 16 o più processori. Cray, azienda statunitense leader nella realizzazione dei supercomputer, ha smesso di utilizzare le CPU Opteron non perché inadeguate, ma perché il bus HT non garantisce latenze abbastanza basse. Agli Opteron e all'HT sono stati preferite le CPU Xeon di Intel, dotate di Bus QuickPath Interconnect (QPI), ma di questo parleremo nel prossimo paragrafo.
Nonostante questo problema nel gestire le latenze in sistemi tanto articolati, è sicuro che l'HT rimarrà in giro ancora per molto tempo, soprattutto grazie alla propria ampiezza di banda, oggi non pienamente sfruttata. L'HyperTransport, infatti, viene utilizzato principalmente con Bus ampio 16 Bit (12,8 GB/s) nei sistemi attuali, quando sarebbe già disponibile per l'impiego in versione a 32 Bit (25,6 GB/s). In ambito Embedded, consumer o nei Server a basso costo l'HT avrà ancora un futuro decisamente roseo.
Quando il bus HyperTransport (HT) fu mostrato al mondo da AMD nel 2001, Intel non perse tempo nel denigrarlo, direttamente dall'Intel Developer Forum che si svolse il medesimo anno. A parlarne fu niente meno che Louis Burns, allora General Manager della casa di Santa Clara. Il dirigente Intel affermò che l'HyperTransport “doesn't have the legs for the next 10 years”.
Intel restò allo stesso tempo meravigliata e allarmata dall'HyperTransport, una tecnologia che avrebbe potuto dare ad AMD un notevole vantaggio, soprattutto in ambito Server (come effettivamente fu con le prime versioni delle CPU Opteron). Lo stesso Burns affermò: “We looked inside our own Hub Link architecture and we've looked at a number of other architectures, including HyperTransport, to try to understand whether they had the scalability, the flexibility, the true performance characteristics to become an industry-standard I/O architecture for the next 10 years”.
PC Mag, Maggio 2001
Intel non aveva nulla da contrapporre all'HT, quindi dovette combatterlo con quello che aveva a disposizione: il reparto marketing. David Rich, General Manager presso API NetWorks, circa nello stesso periodo fece chiarezza affermando quanto segue: “We think that Intel's been surprised and taken unawares that HyperTransport has got the support that it has. In the IDF speech, they tried to pigeonhole HyperTransport as a simple physical interface: How many gigabits per second can you get over wire? But that's not all that HyperTransport is.It defines a physical standard but also defines a whole protocol that defines compatibility with PCI”.
L'HyperTransport, nella propria semplicità, ha cambiato radicalmente il mondo dell'informatica contemporanea, ed ha permesso di realizzare sistemi con 4 o più processori senza alzare eccessivamente i costi di progettazione. Non è un caso che Intel, in seguito, abbia preso ispirazione dal Bus di AMD, affinandolo, per realizzare il Bus QuickPath Interconnect (QPI) nell'era post Core, iniziata con l'architettura Nehalem. Anche grazie al QPI Intel è tornata regina incontrastata dei sistemi Multi CPU.
Si può osservare la notevole somiglianza tra il QPI (2008) di Intel, e l'HT (2001) di AMD
Sempre L'HyperTransport fu di stimolo per la realizzazione del Bus PCI-Express (2004) da parte del consorzio formato, inizialmente, da Intel, IBM, HP e Dell. Un Bus seriale (Point-to-Point), modulare e poco costoso da implementare.
Sebbene ormai abbia fatto il suo tempo, l'HyperTransport ha aperto la strada per AMD ad un nuovo modo di approcciarsi al mercato, e con successo: quello Open. Oggi, Rory Read, ricordando tale esperienza, ha richiamato a sé uno dei fautori dell'HyperTransport, Jim Keller, ed ha dato vita alla Fondazione HSA. L'obiettivo è il medesimo: offrire una piattaforma Open attraverso cui poter realizzare un ecosistema più efficiente di quello attuale. Ma questa volta non solo Hardware, anche Software.
Al pari di 13 anni fa ancora una volta Intel ha deciso di non collaborare, e a questa si è aggiunta nVidia. Nel 2001 la casa del camaleonte non aveva nessun interesse per non farne parte, in quanto era una produttrice di chipset e GPU. Far parte del Consorzio sarebbe stato solo un vantaggio (l'XBoX ne è un esempio). Oggi, avendo un proprio ecosistema di nome CUDA, nVidia teme la Fondazione HSA.
Dieci anni fa l'HyperTransport Consortium, appoggiato da tutte le maggiori aziende hardware, vinse nonostante l'opposizione di Intel. La situazione oggi si ripete con la Fondazione HSA. Riuscirà a risultare vincente, nel lungo periodo?