SPARC Architecture Overview

SPARC
Architecture
Overview
Politecnico di Milano Polo Regionale di Como
Sistemi Embedded
Autore:
Aldo Puglisi 674641 [email: [email protected]]
Docente: Prof. Carlo Brandolese
Indice
Introduzione ........................................................................................................................... 3
1.0 Scalable Processor ARChitecture ......................................................................... 4
1.1 Le origini ....................................................................................................................... 5
1.2 Processori SPARC ..................................................................................................... 5
1.2.1 Integer Unit (IU) .............................................................................................. 5
1.2.2 Floating-point Unit (FPU)............................................................................. 6
1.2.3 Coprocessor (CP).............................................................................................. 6
1.3 Istruzioni ...................................................................................................................... 7
1.3.1 Esecuzione ........................................................................................................... 7
1.3.2 Formato ................................................................................................................. 7
1.3.3 Categorie............................................................................................................... 8
1.4 Modello di Memoria ............................................................................................... 11
1.5 Traps ............................................................................................................................. 13
1.5.1 Categorie di Traps .......................................................................................... 13
1.6 Cambiamenti da SPARC-V8 a SPARC-V9 .................................................... 13
2.0 Implementazioni......................................................................................................... 15
2.1 UltraSPARC ................................................................................................................ 16
2.1.1 UltraSPARC I/II .............................................................................................. 16
2.1.2 UltraSPARC III................................................................................................. 24
2.1.3 UltraSPARC IV .................................................................................................. 32
2.1.4 Visual Instruction Set (VIS) ..................................................................... 35
2.2 LEON.............................................................................................................................. 37
2.3 Altre Soluzioni.......................................................................................................... 38
2.3.1 Super SPARC ..................................................................................................... 38
2.3.2 Sun SPARC.......................................................................................................... 38
2.3.3 Micro SPARC...................................................................................................... 38
2.3.4 Hyper SPARC..................................................................................................... 38
3.0 Conclusioni e Sviluppi Futuri................................................................................ 39
4.0 Riferimenti ..................................................................................................................... 40
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 2 di 40
Introduzione
SPARC (acronimo che sta per "Scalable Processor ARChitecture") è una Instruction
Set Architecture (ISA) creata da Sun Microsystem e mantenuta da SPARC
International [1], un consorzio di produttori di computer, il cui scopo è quello di
creare, aggiornare e mantenere uno standard di riferimento aperto (open standard).
Dunque, SPARC, nelle sue tre versioni 7, 8 e 9, non è un preciso chip, ma una
specifica di architettura che chiunque, sotto licenza di SPARC International, può
implementare.
SPARC si basa su Reduced Instruction Set Architecture (RISC). Questa tipologia di
processori hanno una unità di controllo cablata molto semplice e riservano molto
spazio per i registri interni: una CPU RISC ha di solito da un minimo di un centinaio ad
alcune migliaia di registri interni generici, organizzati in un file di registri. Il tipico set
di istruzioni RISC è molto piccolo, circa sessanta o settanta istruzioni molto elementari
(logiche, aritmetiche e istruzioni di trasferimento memoria-registro e registroregistro): hanno tutte lo stesso formato e la stessa lunghezza, e tutte o quasi vengono
eseguite in un solo ciclo di clock. Sono presenti solo un numero ristretto di metodi di
indirizzamento. Il fatto di avere un formato unico di istruzione permette di strutturare
l'unità di controllo come una pipeline, cioè una “catena di montaggio” a più stadi:
questa innovazione ha il grosso vantaggio di ridurre il critical path interno alla CPU e
consente ai RISC di raggiungere frequenze di clock più alte rispetto agli analoghi
CISC.
La complessità nei RISC si sposta dall'hardware al software: un compilatore che
genera codice per CPU RISC deve affrontare un duro lavoro per generare codice
compatto ed efficiente, che in ogni caso sarà più grande ed occuperà più memoria
dell'equivalente per CISC.
In questa analisi vedremo come i concetti tipici della strutturazione RISC di una
macchina convenzionale sono stati messi in pratica per la definizione e realizzazione
dell'architettura SPARC.
Lo scopo è quello di analizzare le caratteristiche principali dell’architettura SPARC,
focalizzando l’attenzione sulle principali unità funzionali e sulle diverse
implementazioni presenti sul mercato.
In particolare, nel Primo Capitolo descriveremo brevemente l’architettura SPARC,
fornendo gli elementi essenziali per comprendere le caratteristiche dello standard:
verranno descritte le principali unità funzionali, le istruzioni, la memoria, e le trap.
Nel Secondo Capitolo analizzeremo le principali implementazioni presenti sul mercato.
In particolare focalizzeremo la nostra attenzione sulla famiglia UltraSPARC sviluppata
da Sun Microsystem [2], in quanto sembra essere il progetto più attivo negli ultimi
anni per quanto riguarda lo sviluppo di SPARC. In seguito analizzeremo revemente
anche altre soluzioni come: LEON, Super SPARC, Hyper SPARC, ecc..
Infine, nell’ultimo Capitolo concluderemo l’approfondimento con le considerazioni e gli
sviluppi futuri.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 3 di 40
1.0 Scalable Processor ARChitecture
In questo Capitolo esamineremo le principali caratteristiche dell’Architettura SPARC,
focalizzando l’attenzione sulle principali unità che compongono un processore
conforme allo standard, sulla memoria e sul formato delle istruzioni. Inoltre al termine
del Capitolo, analizzeremo le differenze tra le versioni SPARC-V8 e SPARC-V9.
Come precedentemente sottolineato, lo scopo del capitolo non è quella di dare una
descrizione esaustiva delle caratteristiche dell’architettura, ma è quello di fornire gli
elementi necessari per comprendere le proprietà delle diverse implementazioni.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 4 di 40
1.1 Le origini
La prima versione dello standard SPARC venne introdotta da Sun Microsystems nel
1985, riprendendo ed estendendo la struttura dei processori sperimentali RISC-1,
RISC-2 e SOAR, proposti dal gruppo di ricercatori guidati dal professor Patterson
presso la University of California a Berkeley. In seguito (1989), nacque il consorzio
SPARC International, con il compito di mantenere e sviluppare nel tempo lo standard
Scalable Processor ARChitecture.
Come precedentemente anticipato, SPARC International sviluppò tre versioni
dell’architettura: SPARC-V7, SPARC-V8 e SPARC-V9.
La versione SPARC-V7 è ormai parecchio obsoleta, e verrà tralasciata per brevità.
Verranno invece prese in considerazione le altre due versioni dello standard,
focalizzando l’attenzione sull’ultima versione, ovvero SPARC-V9 a 64-bit.
1.2 Processori SPARC
I processori SPARC sono composti logicamente da una integer unit (UI), una floating
point unit (FPU), ed opzionalmente da un coprocessore (CP), ognuno con i propri
registri. Questa organizzazione permette implementazioni con la massima concorrenza
tra l’esecuzione delle istruzioni intere, di floating point, e coprocessore. I registri interi
sono a 64-bit; i registri floating-point sono da 32, 64, 128-bit. Gli operandi delle
istruzioni sono generalmente a registro singolo, doppio, quadruplo, o costanti.
Il processore può lavorare in due modi: user o supervisore. In modo supervisore, il
processore può eseguire qualsiasi tipo di istruzione, incluse le istruzioni privilegiate
(supervisor-only). In user mode, un tentativo di eseguire una istruzione privilegiata
causa una trap da parte del software supervisore. I programmi “User application” sono
programmi eseguiti quando il processore è in user mode.
Nei prossimi paragrafi analizzeremo brevemente le caratteristiche delle unità logiche
sopra elencate, ovvero integer unit (IU), floating-point unit (FPU)e coprocessor unit
(CP).
1.2.1 Integer Unit (IU)
L’Integer Unit (IU) contiene i registri general-purpose e controlla la totalità delle
operazioni del processore. La UI esegue le istruzioni in aritmetica intera e computa gli
indirizzi di memoria per le istruzioni di load e store. Inoltre, essa mantiene il program
counter e controlla l’esecuzione delle istruzioni per Floating Point Unit (FPU) e
Coprocessor (CP).
Una implementazione della IU può contenere da 64 a 528 registri r a 32-bit generalpurpose. Questo corrisponde ad un raggruppamento dei registri in 8 registri r globali,
8 registri r globali alternati, più uno stack circolare da 3 a 32 gruppi da 16 registri
ognuno, conosciuti come register windows.
Siccome il numero di register windows presenti (NWINDOWS) è dipendente
dall’implementazione, anche il numero totale di registri è dipendente
dall’implementazione. Il termine “Scalable” in SPARC, deriva proprio dal fatto che la
specifica non vincola il numero totale di registri che un’implementazione deve avere.
Attualmente, un'istruzione può accedere agli 8 registri globali (o gli 8 globali alternati)
e ad una register window nei registri r. Una 24-register window comprende un set di
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 5 di 40
16 registri – diviso in 8 registri in e 8 registri local – insieme con 8 registri in di un
register set adiacente, indirizzabile dalla finestra corrente come suoi registri di uscita
out. E’ importante notare che diversamente ai registri di in, locali e out, i registri
globali non fanno parte di alcuna register window. I registri globali sono un insieme di
otto registri con scopo globale, come il set dei registri delle architetture di processori
più tradizionali.
La finestra corrente è specificata dal campo current window pointer (CWP) nel
processor state register (PSR). Window overflow e underflow sono rilevati tramite il
registro window invalid mask (WIM), che è controllato dal software di supervisore. Il
numero attuale di finestre in una implementazione SPARC-V9 è invisibile ai programmi
user-application.
Ogni volta che la IU accede una istruzione dalla memoria o dei dati, essa allega
all’indirizzo un address space identifier, o ASI (si veda più avanti).
1.2.2 Floating-point Unit (FPU)
La FPU contiene 32 registri floating-point a 32-bit (precisione singola), 32 registri
floating-point a 64-bit (precisione doppia), 16 registri floating-point a 128-bit
(precisione quadrupla), alcuni di essi sovrapposti. I 32 registri a precisione singola, la
metà inferiore dei registri a precisione doppia e la metà inferiore dei registri a
precisione quadrupla si sovrappongono tra loro. La metà superiore dei registri a
precisione doppia e la metà superiore di quelli a precisione quadrupla si
sovrappongono tra di loro, ma non sovrappongono nessun dei registri a precisione
singola. Dunque, i registri floating-point possono gestire un massimo di 32 valori a
precisione singola, 32 a precisione doppia, o 16 a precisione quadrupla.
Le istruzioni load/store di Floating-point sono usate per muovere i dati tra FPU e
memoria. Gli indirizzi di memoria sono computati da IU. Le istruzioni Floating-Point
operate (FPop) eseguono operazioni aritmetiche floating-point e confronti.
Il floating-point instruction set ed il formato dei dati a 32-bit e 64-bit sono conformi
allo Standard for Binary Floating-Point Arithmetic, IEEE Std 754-1985. Tuttavia,
SPARC non richiede che tutti gli aspetti dello standard siano implementati in
hardware. Una implementazione può indicare che una istruzione floating point non
produce un corretto risultato IEEE Std 754-1985 generando una speciale eccezione
floating-point unfinished o unimplemented. I software devono necessariamente
emulare qualsiasi funzionalità non presente in hardware.
Se la FPU non è presente, o se non è abilitata (il bit enable floating point (EF) nel PSR
è 0), un tentativo di eseguire una istruzione floating point genera una trap
fp_disabled. In entrambi i casi, i software devono:
•
•
Abilitare la FPU e rieseguire l’istruzione, oppure
Emulare l’istruzione che ha lanciato la trap
1.2.3 Coprocessor (CP)
L’instruction set include il supporto per un coprocessore singolo dipendente
dall’implementazione. Il coprocessore ha il suo set di registri. Le istruzioni di
load/store del coprocessore sono utilizzate per muovere i dati tra i registri del
coprocessore e la memoria. Per ogni floating point load/store nell’instruction set, c’è
un analoga istruzione load/store del coprocessore.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 6 di 40
Se un CP non è presente, o non è abilitato (il bit enable_coprocessor (EC) nel PSR è
0), una istruzione di coprocessore genera una trap cp_disabled.
1.3 Istruzioni
Le istruzioni sono accedute dal processore nella memoria e sono eseguite, annullate o
causano il lancio di una trap. Le istruzioni sono codificate in quattro formati principali
e partizionate in categorie.
1.3.1 Esecuzione
L’istruzione alla locazione di memoria specificata dal program counter è prelevata ed
eseguita. L’esecuzione dell’istruzione può modificare lo stato visibile dal processore
e/o dalla memoria. Come side-effect dell’esecuzione, nuovi valori sono assegnati al
program counter (PC) ed al next progrm counter (nPC).
Un’istruzione può generare un’eccezione se essa incontra una condizione che rende
impossibile la normale esecuzione. Una tale eccezione può a sua volta generare una
trap. Altri eventi possono generare una trap (si veda la sezione 1.5 “Traps ” per
ulteriori dettagli).
Se non avviene una trap e l’istruzioni non è di tipo control transfer, il next program
counter (nPC) è copiato nel PC e nPC è incrementato di 4 (ignorando eventuali
overflow). Se l’istruzione è control transfer, il next program counter (nPC) è copiato
nel PC e l’indirizzo target è scritto in nPC.
1.3.2 Formato
Le istruzioni sono codificate in 4 formati a 32-bit principali ed altri formati minori. La
Figura 1.1 riporta un esempio per ognuno dei quattro formati definiti in SPARC-V9
(per ulteriori dettagli si veda [1]).
Figura 1.1 - Esempio per ognuno dei quattro formati definiti in SPARC-V9
I principali campi delle istruzioni sono:
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 7 di 40
op: codifica il formato dell’istruzione
disp: spostamento PC-relative (ad esempio per una branch o call)
rd: Questo campo a 5-bit è l'indirizzo del registro/i di destinazione (o sorgente)
per una istruzione di load, aritmetica, o di store.
imm: è una costante
rs: è l’indirizzo del primo/secondo operando sorgente del registro/i
i: selziona il secondo operando per una istruzione aritmetica intera o load/store.
cc: specifica il codici di condizione da usare nell’istruzione
1.3.3 Categorie
Le istruzioni possono esser raggruppate in sei categorie base:
1.
2.
3.
4.
5.
6.
Accesso alla Memoria
Arithmetic/logical/shift
Control transfer
Read/write control register
Floating-point operate
Coprocessor operate
Nelle prossime sezioni analizzeremo le categorie sopra elencate.
1.3.3.1 Accesso alla Memoria
Le istruzione di Load/Store e le operazioni atomiche, CASX, SWAP e LDSTUB, sono le
uniche istruzioni che accedono la memoria. Esse usano due registri r o un registro r ed
valore immediato per computare un indirizzo di memoria a 64-bit, byte-aligned. IU
appende una ASI a questo indirizzo.
Il campo di destinazione dell’istruzione di load/store specifica uno o due registri r,
oppure uno, due, o quattro registri f, che forniscono dati per una store o li ricevono
per una load.
Le istruzioni di load e store intere supportano accessi a byte, mezze parole (16-bit),
parole (32-bit), doppie parole (64-bit).
Le istruzioni di load e store di floating-point supportano accessi alla memoria per
parole e doppie parole e quadruple parole.
CAS, SWAP e LDSTUB sono istruzioni di accesso alla memoria speciali usate per la
sincronizzazione e l’aggiornamento della memoria da parte di processi concorrenti.
1.3.3.1.1 Memory Alignment Restrictions
Esistono le seguenti restrizioni di allineamento: gli accessi a mezze parole devono
essere allineati su 2-byte; gli accessi a parole devono essere allineati su 4-byte;
accessi doppie parole devono essere allineati su 8-byte; e quantità a quattro parole
dovrebbero devono allineati su 16-byte. Un indirizzo impropriamente allineato in una
istruzione di load o store causa una trap.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 8 di 40
1.3.3.1.2 Addressing Conventions
La memoria è una collezione di locazioni accessibile dalle istruzioni di load e store.
Ogni locazione, ovvero un indirizzo, è una tupla che consiste Address Space Identifier
(ASI) a 8-bit e un byte-address offeset a 64-bit nell’address space specificato.
Gli scopi per cui il processore fornisce un address space identifier (ASI) sono diversi,
ovvero:
•
•
•
Per identificare a quale dei vari distinti address space l’address offset a 64-bit è
riferito
Per specificare l’indirizzo di un control register interno al processore, cache, o
memory management hardware
Per fornire controlli di accesso addizionali ed altre informazioni
SPARC-V9 usa per default big-endian byte order: l’indirizzo di una quadrupla parola,
doppia parola, parola o mezza parola è l’indirizzo del suo byte più significativo.
Aumentare l’indirizzo generalmente significa diminuire il significato dell’unità che deve
essere acceduta. Tutte le istruzioni accedute sono eseguite usando big-endian byte
order. SPARC-V9 supporta inoltre little-endian byte order solo per accessi ai dati:
l’indirizzo di una quadrupla parola, doppia parola, parola o mezza parola è l’indirizzo
del suo byte meno significativo.
1.3.3.1.3 Load/Store Alternate
Le istruzioni di load e store forniscono un valore implicito di Address Space Identifier
(ASI) a 8-bit. Le istruzioni di load/store alternate invece possono contenere
esplicitamente un ASI per load/store di accesso ai dati. L’accesso ad alternate spaces
0016..7F16 è ristretto, e l’accesso ad alternate spaces 8016..FF16 è non ristretto. Alcune
delle ASI sono disponibili per usi dipendenti dall’implementazione. Il software
supervisore può usare le ASI dipendenti dall’implementazione per accedere a registri
speciali, quali MMU, cache control, registri di stato del processore ed altri valori
dipendenti dal sistema o dal processore.
Lo spazio di indirizzamento alternato è inoltre fornito di istruzioni atomiche di accesso
alla memoria, LDSTUB, SWAP e CASX.
1.3.3.1.4 Separate I and D Memories
La maggior parte delle specifiche in questo elaborato sono scritte come se le istruzioni
di store scrivano nella stessa memoria da cui le istruzioni sono accedute. Tuttavia, una
implementazione può esplicitamente partizionare istruzioni e dati in memoria
istruzioni e memoria dati indipendenti, chiamata comunemente architettura "Harvard"
o "split I & D cache".
1.3.3.1.5 Input/Output
SPARC-V9 assume che i registri di input/output siano acceduti tramite istruzioni
load/store alternate, istruzioni load/store normali, istruzioni di coprocessore, o
istruzioni read/write dipendenti dallo state register (RDASR, WRASR). Nel caso di
istruzioni load/store alternate, i registri di I/O possono essere acceduti solo dal
supervisore.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 9 di 40
La possibilità di accedere alle locazioni di input/output (I/O) da parte di codice non
privilegiato, i contenuti e gli indirizzi dei registri di I/O, sono dipendenti
dall’implementazione.
1.3.3.1.6 Memory Syncronization
Per la sincronizzazione delle operazioni di memoria sono utilizzate fondamentalmente
due istruzioni: FLUSH e MEM-BAR.
1.3.3.2 Arithmetical/Logical/Shift
Le istruzioni Arithmetical/Logical/Shift eseguono operazioni aritmetiche, operazioni in
aritmetiche tagged, logiche e di shift. Queste istruzioni computano il risultato che è
funzione dei due operandi sorgenti; il risultato è scritto in un registro di destinazione,
o è scartato
Le istruzioni di shift sono utilizzate per muovere il contenuto di un registro r a sinistra
o a destra di una data distanza. La distanza di shift può essere specificata con una
costante nell’istruzione o dal contenuto di un registro r.
L’istruzione di moltiplicazione intera effettua una operazione 64 x 64 à 64-bit. Le
istruzioni di divisione intera effettuano operazioni 64 ÷ 64 à 64-bit. In aggiunta, per
compatibilità con SPARC-V8, le istruzioni di moltiplicazione 32 x 32 à 64-bit, divisione
64 ÷ 32 à 64-bit sono incluse. La divisione per zero causa una trap. Ci sono versioni
delle istruzioni di moltiplicazione e divisione che impostano condition code.
Le istruzioni in aritmetica tagged assumono che i due bit meno significativi degli
operandi siano di tipo tag.
1.3.3.3 Control Transfer
Le istruzioni di control-transfer (CTI) includono PC-relative branch e chiamate, salti
indiretti a registri, e trap condizionate. La maggior parte delle istruzioni controltransfer sono ritardate, (delayed control-transfer instructions – DCTI), ovvero
l’istruzione immediatamente seguente ad una istruzione di control-transfer nella
sequenza logica è eseguita prima che il control transfer all'indirizzo target sia
completato. Si noti che l’istruzione che segue l’istruzione di control-transfer nella
sequenza logica non è necessariamente l’istruzione che segue nella memoria.
L’istruzione seguente ad un delayed control-transfer è chiamata delay-instruction. Un
bit in una delayed control trasfer instruction (annul bit) può causare l’annullamento
della delay instruction (ovvero, annullare il suo effetto) se il branch non è preso (o nel
caso “branch always”, se il branch è preso)
La specifica SPARC-V8 afferma che le delay instruction sono sempre prese, anche se
annullate, e che una istruzione annullata non può causare una trap. SPARC-V9 non
richiede che la delay instruction sia presa se essa è stata annullata.
Le istruzioni di branch e CALL usano spostamenti PC-relative. Le istruzioni di jump and
link (JMPL) e le istruzioni di return (RETURN) usano un register-indirect target
address. Esse computano il loro indirizzi target come la somma dei due registri r, o la
somma di un registro r e 13-bit signed immediate value.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 10 di 40
1.3.3.4 State Register Access
Le istruzioni read/write del registro di stato leggono e scrivono il contenuto dei registri
di stato visibili dal software non privilegiato (Y, CCR, ASI, PC, TICK, e FPRS).
Le istruzioni read/write privilegiate di registro leggono e scrivono il contenuto dei
registri di stato visibile solo al software privilegiato (TPC, TNPC, TSTATE, TT, TICK,
TBA, PSTATE, TL, PIL, CWP, CANSAVE, CANRESTORE, CLEANWIN, OTHERWIN,
WSTATE, FPQ, e VER).
Ci sono inoltre istruzioni read/write che il software può utilizzare per leggere e
scrivere registri particolari dipendenti dall’implementazione.
1.3.3.5 Floating-Point/Coprocessor Operate
Le istruzioni Floating-point operate (FPop) eseguono tutti i calcoli in floating point;
sono istruzioni register-to-register che operano sui registri floating-point. Come le
istruzioni arithmetic/logical/shift, FPop computa un risultato che è funzione di uno o
due operandi sorgente.
Le istruzioni Floating-point operate (FPop) effettuano tutti i calcoli di virgola mobile.
Sono istruzioni di inter-registro che funzionano sui registri di virgola mobile. Come le
istruzioni di arithmetic/logical/shift, il calcolo di una FPop un da risultato che è una
funzione di uno o due operandi sorgente.
Le istruzioni Coprocessor operate (CPop) sono definite dall’eventuale coprocessore.
1.3.3.6 Conditional Move
Le istruzioni conditional move copiano un valore da un registro sorgente ad un
registro destinazione, in maniera dipendente da una condizione intera o floating-point
o sul contenuto di un detrminato registro. Queste istruzioni migliorano le performance
riducendo il numero di branch.
1.3.3.7 Register Window Management
Queste istruzioni sono utilizzate per gestire la register window. SAVE e RESTORE sono
non-privilegiate e causano ed inducono ad un push o pop della register window.
FLUSHW è non-privilegiata e causa il flush in memoria di tutte le finestre eccetto
quella corrente. SAVED e RESTORED sono usate dal software privilegiato per
concludere una window spill o riempire il trap handler.
1.4 Modello di Memoria
Il modello di memoria di SPARC definisce la semantica delle operazioni di memoria.
La semantica dell'insieme delle istruzioni richiede che load e store sembrino eseguite
nell'ordine in cui compaiono nel flusso dinamico di controllo del programma. L’ordine
attuale in cui esse sono processate dalla memoria può essere differente. Lo scopo dei
memory models è specificare quali vincoli eventualmente esistono nell’ordine delle
operazioni della memoria.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 11 di 40
I memory models si applicano sia a sistemi uni-processore che a sistemi multiprocessore a memoria condivisa. Memory models formali sono necessari per definire
precisamente le interazioni tra processori multipli ed dispositivi di input/output nelle
configurazioni a memoria condivisa. Programmare multiprocessori a memoria
condivisa richiede una comprensione dettagliata del modello attivo di memoria e la
capacità di specificare le operazioni di memoria ad un basso livello per sviluppare i
programmi che possono coordinare in modo sicuro ed attendibilmente le loro attività.
L’architettura SPARC-V9 è un modello che specifica il comportamento osservabile dal
software su sistemi SPARC-V9. Di conseguenza, l'accesso alla memoria può essere
implementato in diversi modi, purchè il comportamento osservato da software sia
conforme a quello dei modelli.
L’architettura SPARC-V9 definisce tre differenti memory models: Total Store Order
(TSO), Partial Store Order (PSO), e Relaxed Memory Order (RMO). Tutti i processori
SPARC-V9 devono fornire Total Store Order per garantire la compatibilità con SPARCV8. Il supporto dei modelli RMO e PSO è dipendente dall’implementazione.
La Figura 1.2 mostra le relazioni tra i diversi memory model di SPARC-V9, dal meno
restrittivo al più restrittivo. Programmi scritti su un modello funzioneranno
correttamente su ogni modello incluso.
Figura 1.2 – Memory Model dal meno restrittivo (RMO) al più restrittivo (TSO)
SPARC-V9 fornisce memory models multipli cosicchè:
•
•
Le implementazioni possono schedulare le operazioni della memoria per avere
alte prestazioni
I programmatori possono creare primitive di sincronizzazione usando la
memoria condivisa
Non esiste un modello preferenziale per SPARC-V9. I programmi scritti in RMO
lavoreranno anche in PSO e TSO. I programmi scritti in PSO lavoreranno anche in
TSO. I programmi scritti per un modello debole, quale RMO, possono essere eseguiti
più rapidamente, ma possono anche richiedere istruzioni supplementari per la
sincronizzazione.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 12 di 40
1.5 Traps
Una trap, ovvero un interrupt interno, è un trasferimento di controllo vettorizzato al
software privilegiato attraverso una speciale tabella che può contenere le prime otto
istruzioni di ogni trap handler. L’indirizzo base della tabella è stabilito dal software in
un registro di stato (il registro Trap Base Address, TBA). Lo spostamento all'interno
della tabella è codificato dal numero tipo di trap e dal livello di trap. Metà della tabella
è riservata per le trap hardware; un quarto per software trap generate dalle istruzioni
trap (Tcc); l’ultimo quarto è riservato per espansioni future dell’architettura.
Una trap può essere causata da una eccezione indotta da una istruzione, o da una
richiesta esterna di interrupt non direttamente relativa ad un'istruzione particolare.
Prima di eseguire l’istruzione, l’IU controlla se esistono eccezioni e richieste di
interrupt. Se sono presenti, IU seleziona quella con priorità superiore e lancia la trap
corrispondente.
1.5.1 Categorie di Traps
Una eccezione o una richiesta di interrupt possono causare tre categorie di trap:
precise, deferred o interrupting.
Una precise trap è indotta da una particolare istruzione ed occorre prima che lo stato
del programma sia modificato dall’istruzione che ha causato la trap.
Una deferred trap è anch’essa indotta da una particolare istruzione, ma diversamente
da precise trap, essa può accadere dopo che lo stato del programma sia cambiato
dall’esecuzione di una o più istruzioni che seguono l’istruzione che ha causato la trap.
Una deferred trap può accadere una o più istruzioni dopo che la l’istruzione che ha
causato la trap è stata eseguita.
Una interrupting trap può essere causata da una richiesta di interrupt esterna
direttamente relazionata ad una particolare istruzione, o può essere dovuta da
eccezione causata da una particolare istruzione precedentemente eseguita.
interrupting trap non è ne una precise trap ne una deferred trap.
implementazione non deve necessariamente fornire la condizione sufficiente
emulare un'istruzione che ha causato una interrupting trap.
non
una
Una
Una
per
SPARC definisce un default trap model, che deve essere presente in tutte le
implementazioni.
1.6 Cambiamenti da SPARC-V8 a SPARC-V9
SPARC-V9 è complementare all'architettura SPARC-V8.
Applicazioni software scritte per microprocessori a 32-bit SPARC-V8 possono essere
eseguite, senza modifiche, su sistemi SPARC-V9.
I cambiamenti alla architettura SPARC-V9 rispetto a SPARC-V8 risiedono in sei aree
principali (per una elenco completo delle modifiche si veda [3]):
•
Trap Model
o Invece di supportare un solo livello di trap, sono supportati quattro o più
livelli
o Molte trap non modificano CWP
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 13 di 40
•
Data Formats
o Sono stati aggiunti data format per interi estesi (64-bit)
•
Registri
o Eliminati: Processor State Register (PSR), Trap Base Register, Windows
Invalid Mask (WIM)
o Estesi da 32-bit a 64-bit: Tutti i registri interi, tutti i registri di stato
(FSR, PC, nPC, Y)
o Il contenuto dei seguenti registri è cambiato:
§ Floating-Point State Register (FSR): i bit fcc1, fcc2, e fcc3
(additional floating-point condition code) sono stati aggiunti ed il
registo è stato esteso a 64-bit
o Registri aggiunti:
§ Sedici registri floating-point a doppia precisione
§ Floting Point State Register (FPSR)
§ ASI: ASI Register
§ PSTATE: Processor State Register
•
Alternate Address Space Access
In SPARC-V8, l'accesso a tutto l’alternate address space è privilegiato. In
SPARC-V9, le load e le store a ASIs 0016..7f16 sono privilegiati; quelli a ASIs
8016..ff16 sono non privilegiati.
•
Instruction Set
Tutti i cambiamenti all’instruction set sono stati fatti cosicchè le applicazioni
software scritte per SPARC-V8 potessero essere eseguite senza modifiche su un
processore SPARC-V9. Le applicazione software scritte per SPARC-V8 non
dovrebbe neppure rilevare che le relative istruzioni ora processano valori a 64bit. La definizione di alcune istruzioni è stata estesa o modificata per lavorare
con il modello a 64-bit.
•
Memory Model
SPARC-V9 definisce un nuovo modello di memoria denominato Relaxed Memory
Order (RMO). Questo modello molto debole, permette alle CPU di schedulare gli
accessi alla memoria quali load e store in qualsiasi ordine, finchè il programma
computa la risposta corretta. Quindi, l’hardware può istantaneamente sistemare
i conflitti nell'ordine più efficiente, portando ad operazioni di memoria molto più
veloci ed a performance migliori.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 14 di 40
2.0 Implementazioni
In questo Capitolo descriveremo le principali implementazioni dell’architettura SPARC.
In primo luogo esamineremo la famiglia di processori UltraSPARC sviluppata da Sun
Microsystem in collaborazione con Texas Instrument.
E’ importante sottolineare che UltraSPARC sembra essere il progetto più attivo
nell’ambito dello sviluppo di processori compatibili con l’architettura SPARC. Per
questo motivo dedicheremo ampio spazio ad UltraSPARC piuttosto che ad altre
soluzioni.
In seguito analizzeremo brevemente LEON, soluzione fornita da Gaisler Research in
collaborazione con l’Ente Spaziale Europeo (ESA).
Concluderemo il Capitolo con una breve rassegna di altre soluzioni conformi allo
standard SPARC, ma ormai obsolete.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 15 di 40
2.1 UltraSPARC
La famiglia di processori UltraSPARC è basata sull'architettura SPARC-V9 a 64-bit e,
come precedentemente anticipato, è stata progettata (e sviluppata) da Sun
Microsystem in collaborazione con Texas Instrument.
Essa è costituita da quattro modelli di processori: UltraSPARC I, UltraSPARC II,
UltraSPARC III e UltraSPARC IV.
Nelle prossime sezioni analizzeremo le principali caratteristiche di questi
microprocessori ed alla fine della sezione analizzeremo brevemente Visual Instruction
Set (VIS), ovvero un’estensione all’instruction set di UltraSPARC per operazioni
grafiche complesse.
2.1.1 UltraSPARC I/II
In questa sezione esamineremo i processori superscalari UltraSPARC I/II. Benchè
obsolete, queste soluzioni forniscono le basi per le implementazioni attuali fornite da
Sun Microsystem, ovvero i processori UltraSPARC III e UltraSPARC IV.
2.1.1.1 Unità Funzionali
La figura 2.1 mostra un diagramma a blocchi semplificato che identifica le maggiori
unità funzionali che compongono UltraSPARC I/II:
1. Front end – La Prefetch / Dispatch Unit (PDU) effettuate il prefetch delle
istruzioni basandosi sul meccanismo di dynamic branch prediction e su un
campo successivo. Effettuando la predizione accuratamente (tipicamente il 90%
delle predizioni sono corrette), il front end può fornire quattro istruzioni per
ciclo
al
blocco
di
esecuzione
centrale.
2. Integer Execution Unit (IEU) – Effettua tutte le operazioni aritmetico
logiche. La IEU incorpora un 3D register file che supporta sette read port e tre
write
port.
3. Floating Point / Graphics Unit (FGU) – Integra cinque unità funzionali ed un
register file composto da 32 registri a 64-bit. I sommatori, moltiplicatori e
divisori in virgola mobile effettuano tutte le operazioni in floating point, ed
inoltre sono potenziati dall’aggiunta di operazioni grafiche di somma e
moltiplicazione per effettuare partitioner integer operation richieste da VIS.
4. Load Store Unit (LSU) – Esegue tutte le istruzioni che trasferiscono dati tra la
gerarchie di memoria ed i due register file in IEU e FGU. La Data Cache (DCache), Load Buffer, Store Buffer, e Data Memory Management Unit DMMU
sono
incluse
in
questa
unità.
5. External Cache (E-Cache) – Serve le “miss” dell’Instruction Cache (I-Cache)
del front end di UltraSPARC e della D-Cache della LSU.
Nelle prossime sezioni analizzeremo le diverse componenti sopra elencate.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 16 di 40
Figura 2.1 – Diagramma a Blocchi semplificato per UltraSPARC I/II
2.1.1.2 Il Front End di UltraSPARC I/II
La Figura 2.2 mostra il front end di UltraSPARC I/II. Come precedentemente
anticipato la componente principale di del front end di UltraSPARC è la PDU
(Prefetch/Dispatch Unit).
Figura 2.2 – Front end UltraSPARC I/II
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 17 di 40
L’Instruction cache (I-Cache) è una cache di 16 Kbyte di tipo set-associativo a due
vie, con blocchi di 32 byte; è fisicamente indicizzata e contiene tag fisici. Per
indirizzarla sono necessari, grazie all'algoritmo di predizione, solo i bit di indice (13
bit, che corrispondono alla dimensione minima della pagina). E' in grado di ritornare
fino a 4 istruzioni da una linea che contiene 8 istruzioni.
A. Integer Execution Unit (IEU)
L’Integer Execution Unit (IEU), mostrata in Figura 2.3, effettua computazioni intere
per tutte le operazioni aritmetico/logiche.
Due ALU formano la parte principale dell’IEU, insieme ad un moltiplicatore e divisore a
cicli multipli per gli interi. Sono disponibili otto finestre dei registri e quattro insiemi di
registri globali (normali, alternati, MMU e interrupt globali), oltre ai registri di trap.
L’unità di moltiplicazione ha una latenza tipica di otto cicli di clock, mentre quella di
divisione ha una latenza di 67 cicli di clock per una divisione 64bit x 64bit.
Figura 2.3 – Integer Execution Unit
B. Floating Point / Graphics Unit (FGU)
La Floating Point / Graphics Unit (FGU), mostrata in Figura 2.4, integra cinque unità
funzionali ed un Register File 32-registri x 64-bit. I sommatori, moltiplicatori e divisori
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 18 di 40
in virgola mobile effettuano tutte le operazioni in floating point, ed inoltre sono stati
potenziati dall’aggiunta di operazioni grafiche di somma e moltiplicazione (necessarie
per VIS).
Figura 2.4 – Floating Point e Graphics Unit
La separazione fra le unità di esecuzione nella FPU permette a UltraSPARC I/II di
eseguire due istruzioni FP per ciclo di clock. I dati sorgente e i risultati sono
immagazzinati in un registro a 32 ingressi, dove ogni ingresso può contenere un
valore a 32 o a 64 bit. La maggior parte delle istruzioni sono completamente in
pipeline (throughput di una per ciclo), hanno una latenza di tre e non sono influenzate
dalla precisione degli operandi (cioè la latenza è la stessa sia in singola che in doppia
precisione). La divisione e la radice quadrata non sono in pipeline, e necessitano di 12
cicli (singola precisione) e 22 cicli (doppia precisione), ma non provocano lo stallo del
processore: altre istruzioni che seguono possono essere caricate, eseguite e ritirate
prima che la divisione finisca. Viene mantenuto un preciso modello delle eccezioni,
tramite la sincronizzazione della pipeline FP e di quella intera, e predicendo le trap per
operazioni a lunga latenza.
UltraSPARC I/II introduce un insieme di istruzioni grafiche che forniscono un veloce
supporto hardware per l'elaborazione di immagini 2D e 3D, video e audio. Sono
presenti le operazioni di somma, confronto e booleane, sia a 16 che a 32 bit, e la
moltiplicazione a 8 e a 16 bit; sono supportate le operazioni di distanza fra pixel,
allineamento dei dati, impacchettamento ed unione, tutte eseguite in un singolo ciclo
di clock.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 19 di 40
C. Load/Store Unit (LSU)
La Load/Store Unit (LSU) esegue tutte le istruzioni che trasferiscono dati tra la
gerarchia di memoria e Register files (Interi e Floating-point/Graphics). La LSU include
Data Cache, Load Buffer, Store Buffer, ed è strettamente accoppiata con l’extenal
cache di secondo livello.
La Figura 2.5 mostra un diagramma funzionale della Load/Store Unit.
- Data Cache
E' una cache di 16 Kbyte di tipo write-through direttamente mappato, con due
sottoblocchi da 16 byte per linea; è indicizzata virtualmente mentre il tag è fisico.
L'array di tag è di tipo dual-ported, in modo che l'update dei tag dovuto al
riempimento delle linee non collida con la lettura dei tag dovuta ai caricamenti.
- Load Buffer
Il load buffer può eliminare gli stalli causati dalle miss della D-Cache, ed altre tipologie
di conflitti. Il load buffer è organizzato come una coda circolare. Ogni load è accodata
con una indicazione di hit o miss nella D-Cache. Questa informazione è tracciata per
tutta la durata dell’operazione, anche in presenza di snoops.
Figura 2.5 – Load/Store Unit
- Store Buffer
Lo Store Buffer a otto ingressi (ogni ingresso rappresenta un riferimento a 64bit ed il
relativo indirizzo corrispondente) fornisce un hoding place temporaneo per le
operazioni di store fino a che esse possano essere dichiarate completate e la D-Cache
e/o la E-Cache siano disponibili. L’aggiornamento della E-Cache è un processo a due
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 20 di 40
fasi. Per prima cosa, i tag della E-Cache sono controllati per verificare la presenza di
hit/miss; poi, la avviene E-Cache write. Gli accessi a E-Cache tag e data RAM sono
disaccoppiati, cosicchè il controllo di un tag può avvenire in parallelo con una E-Cache
Data write di una vecchia store, mantenendo cosi un throughput di una store per
clock. Inoltre, store consecutive alla stessa E-Cache line (64B) tipicamente richiedono
solo un singolo controllo del tag, minimizzando cosi le transazioni di tag check.
- Data Memory Management Unit (DMMU)
L'MMU si occupa della mappatura tra i 44 bit dell'indirizzo virtuale e i 41 bit
dell'indirizzo fisico; ciò è realizzato attraverso due TLB a 64 ingressi, uno per le
istruzioni e uno per i dati, entrambi completamente associativi. UltraSPARC II fornisce
un supporto hardware per una strategia di miss dei TLB basata sul software. Sono
supportate dimensioni di pagina di 8, 64, 512 e 4096 Kbyte.
D. External Cache
La cache esterna è usata per servire le miss della I-Cache nel front end di UltraSPARC
I/II e nella D-Cache di LSU. Essa è una implementazione SRAM fisicamente indicizzata
e fisicamente etichettata. La line size è di 64bytes. Le dimensioni della E-Cache sono
dipendenti dal modello del microprocessore (da 512KB a 4MB per UltraSPARC I e da
da 512KB a 16MB per UltraSPARC II). Un buffer di scrittura interno ritardato
minimizza le penalità Write After Read (WAR). La latenza addizionale per una internal
cache miss e E-Cache hit è della durata di sei cicli (tre interni e tre esterni). Le letture
possono essere completate ogni ciclo. UltraSPARC I/II non differenzia burst read e due
read successive; i segnali usati per una lettura singola sono semplicemente replicati
per ogni lettura sequenziale. Le letture sono pienamente parallelizzate cosi da
mantenere un pieno rendimento.
Anche le scritture possono essere completate ogni ciclo. La penalità write-after-read
totale è di due cicli. Non c’è una penalità read-after-read (RAW).
E. System Interface
La Figura 2.6 mostra un sottosistema UltraSPARC I/II completo, composto dal
processore UltraSPARC I/II, componenti SRAM sincroni per la External Cache tag e
data e due chip UltraSPARC I/II Data Buffer (UDB).
Figura 2.6 – UltraSPARC I/II System Interface
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 21 di 40
Le UDB servono per isolare elettricamente le interazioni tra la CPU e la E-Cache dal
bus di sistema ed operano alla frequenza di clock del sistema, la quale può essere sia
metà che un terzo del clock del processore. In totale le UDB hanno un buffer di lettura
da 64byte, due buffer di scrittura da 64byte, e un copyback buffer da 64byte.
Le transazioni di sistema sono packet-based, indirizzi e trasferimento di dati sono
eventi disgiunti. Un bus di indirizzi da 36bit è utilizzato per trasportare two-cycle
request packets che iniziano una transazione. Questo bus può inoltre essere condiviso
da altri tre master, in aggiunta ad un controllore di sistema centralizzato.
L’Arbitration è distribuita. Ogni master sul bus di indirizzamento ha la stessa logica e
vede tutte le rechieste al bus. Esistono cinque potenziali richieste: quattro potenziali
master più una da un controllore di sistema ad alta priorità. L’Arbitration è roundrobin con un effetto di isteresi per ridurre la latenza per l’ultimo master.
2.1.1.3 Pipeline
Le funzioni effettuate da IEU, LSU e FGU sono implementate in una pipeline duale a
nove stadi. La maggior parte delle istruzioni passano all’interno della pipeline in nove
stadi esatti. Le istruzioni sono considerate terminate dopo che sono passate attraverso
l’ultimo stadio (W), dopo il quale, i cambiamenti sono irreversibili. La Figura 2.7
mostra un diagramma degli stadi della pipeline integer e floating-point. Tre stadi
addizionali sono aggiunti alla pipeline intera per renderla simmetrica rispetto a quella
floating-point. Questo semplifica la sincronizzazione di pipeline, la gestione delle
eccezioni, ed elimina la necessità di implementare una coda floating-point.
Le istruzioni di floating-point con una latenza superiore a tre (ad es. divisione e radice
quadrata) si comportano in modo diverso rispetto alle altre istruzioni, nel senso che la
pipe è “estesa” quando l’istruzione raggiunge la fase N1. Le operazioni di memoria
possono procedere in maniera asincrona con la pipeline in modo tale da supportare
latenze più lunghe rispetto la latenza della data cache on-chip.
Figura 2.7 – La pipeline a nove stadi duale di UltraSPARC I/II
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 22 di 40
2.1.1.4 Descrizione delle fasi della pipeline
Fase 1: Fetch (F)
In questa fase le istruzioni sono prelevate dall’Instruction Cache (I-Cache) e piazzate
nell’Instruction Buffer, da dove saranno selezionate per l’esecuzione. Al massimo
vengono prelevate quattro istruzioni alla volta, assieme alle informazioni di branch
prediction, l’indirizzo target predetto di una branch, ed il predicted set del target.
Fase 2: Decode (D)
In questa fase le istruzioni che hanno effettuato il fetch sono precodificate ed inviate
all’Instruction Buffer. I bit precodificati generati durante questa fase accompagnano
l’istruzione durante il suo soggiorno nell’Instruction Buffer. Nel raggiungere la fase
successiva (dove risiede la logica di raggruppamento), questi bit accelerano la
decodifica parallela fino a quattro istruzioni.
Mentre si sta riempiendo, l’Instruction Buffer presenta anche fino a quattro istruzioni
alla fase successiva. Una coppia di puntatori gestiscono l’Instruction Buffer,
assicurando che la maggioranza delle istruzioni siano presentate in ordine alla fase
successiva.
Fase 3: Grouping (G)
In questa fase, il task principale è raggruppare e spedire un massimo di quattro
istruzioni valide in un ciclo. Essa riceve un massimo di quattro istruzioni dalla Prefetch
and Dispatch Unit (PDU), controlla l’Integer Core Register File (ICRF), ed inoltra dati
validi ad ogni unità funzionale.
Fase 4: Execution (E)
In questa fase, i dati dall’integer register file sono processati da due ALU intere
durante il ciclo attuale (se il gruppo di istruzioni include operazioni ALU). I risultati
sono computati e sono disponibili per le altre istruzioni in ogni ciclo successivo.
L’indirizzo virtuale di una operazione di memoria è calcolato in questa fase in parallelo
con la computazione dell’ALU.
Nella pipe Floatinf-point/Graphics, questa fase corrisponde al Register (R) Stage della
FGU. Il floating-point register file è acceduto durante il ciclo attuale, le istruzioni sono
ulteriormente decodificate e la FGU control unit seleziona le esclusioni adeguate per le
istruzioni correnti.
Fase 5: Cache Access (C)
In questa fase, gli indirizzi virtuali delle operazioni di memoria calcolate nella Fase 4
(Execution) sono inviate al tag RAM per determinare se l’accesso (di tipo load o store)
è un hit o una miss nella D-Cache. In una operazione parallela, l’indirizzo virtuale è
inviato alla data MMU per essere trasformato in un indirizzo fisico.
Le operazioni della ALU eseguite nella Fase 4 (Execution) generano codici di
condizione nella Fase 5 (Cache Access). I codici di condizione sono inviati alla PDU, la
quale effettua controlli per determinare se un branch condizionato nel gruppo è stato
correttamente predetto. Se il branch è stato mal predetto (mispredicted), le ultime
istruzioni nella pipe sono ripulite, e viene effettuato il fetch delle istruzioni corrette.
Nella Floating-point/Graphics pipe, questo corrisponde alla Fase X1. Le istruzioni
cominciano la loro esecuzione durante questa fase. Inoltre le istruzioni di latenza uno,
durante la Fase X1 terminano la loro esecuzione.
Fase 6: N1 Stage
In questa fase, è determinato un data cache miss/hit o un TLB miss/hit. Se è rilevata
una TLB miss, viene lanciata una trap e la traduzione di indirizzo è ottenuta da una
procedura del software. L’indirizzo fisico di una store è inviata allo Store Buffer
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 23 di 40
durante questa fase. Per evitare stalli nella pipeline quando i dati di una store non
sono disponibili immediatamente, gli indirizzi delle store e i dati sono disaccoppiati e
inviati separatamente allo Store Buffer.
Nella Floating-point/Graphics pipe, questa è la seconda fase di esecuzione (X2) dove
l’esecuzione continua per la maggior parte delle istruzioni.
Fase 7: N2 Stage
In questa fase, l’Integer Pipe essenzialmente attende il completamento della Floatingpoint/Graphics pipe. La maggior parte delle istruzioni floating-point nella Floatingpoint/Graphics pipe finiscono l’esecuzione durante questa fase. Dopo N2, i dati
possono essere bypassati da altri stadi o rediretti alla porzione di dati dello Store
Buffer.
Fase 8: N3 Stage
In questa fase, Integer e Floating Point/Graphics pipes convergono per risolvere le
trap.
Fase 9: Write (W)
In questa fase, tutti i risultati (interi e floating-point) sono scritti sul register files.
Tutte le azioni effettuate durante questa fase sono irreversibili. Dopo questa fase le
istruzioni sono considerate terminate.
2.1.2 UltraSPARC III
Sun cominciò lo sviluppo di sistemi basati su processori superscalari UltraSPARC III
nel 2000. La prima versione di UltraSPARC III fu prodotta inizialmente da Texas
Instrument (TI) con tecnologia 0.18µ con metal layer di alluminio (Al). Implementato
in questa tecnologia, UltraSPARC III opera ad una frequenza tra 600MHz e 750MHz.
Nel 2001, UltraSPARC III fu aggiornato usando la nuova tecnologia sviluppata da TI,
ovvero 0.15µ con metal layer di rame (Cu). Implementato in questa nuova ed
avanzata tecnologia, UltraSPARC III opera ad una frequenza tra 900MHz e 1050MHz.
Nel 2002, UltraSPARC III Cu fu aggiornato all’ultima generation technology, ovvero
0.13µ, raggiungendo una frequenza operativa massima di 1200MHz.
Lo scopo del processore UltraSPARC III è quello di migliorare le real performance e di
venir incontro alle esigenze di sistemi enterprise per un elevato livello di RAS
(Reliability Availability Serviceability), facendo leva sulle precedenti versioni del
processore.
Nelle sezioni seguenti analizzeremo le caratteristiche
raggungimento degli obiettivi sopra elencati.
che
hanno
portato
al
2.1.2.1 Caratteristiche per migliorare Real Performance
Le caratteristiche di design di UltraSPARC III intendono migliorare in maniera specifica
le real performance espresse da questo processore in ambienti di rete enterprise.
In particolare i progettisti hanno lavorato per riuscire ad avere:
•
•
•
•
Elevato picco del rate di uscita delle istruzioni
Pipelining per alti clock rate
Migliore schema per gestire decisioni di branch
Riduzione dei colli di bottiglia nella memoria
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 24 di 40
•
Nuove istruzioni per accelerare task di computazione specifici
2.1.2.1.1 Picco del rate di uscita delle istruzioni
Come le precedenti generazioni di UltraSPARC, UltraSPARC III mantiene un
sostanziale rate di uscita di 4 istruzioni in ogni ciclo di clock (il massimo numero di
istruzioni che possono essere prelevate dalla cache in un ciclo di clock). In attesa che
un’appropriata unità di esecuzione diventi disponibile, possono essere accodate un
massimo 16 fetched instructions, ovvero istruzioni per le quali è già stato eseguito il
fetch.
Ci sono sei unità di esecuzione parallele: 2 ALU intere (identiche), 1 unità di branch, 1
unità di load/store, e due unità di floating-point (1 per operazioni di
somma/sottrazione e un’altra per moltiplicazione/divisione).
2.1.2.1.2 Pipelining per alti clock rate
Per realizzare alti clock rate, la nuova pipeline di esecuzione di UltraSPARC III è
segmentata in 14 fasi separate. Come conseguenza, questo design della pipeline è in
grado di scalare da una frequenza iniziale 600MHz alla frequenza corrente di 1200MHz
per raggiungere 1500MHz nelle prossime generazioni.
2.1.2.1.3 Gestione delle branch
UltraSPARC III implementa un meccanismo avanzato di branch prediction basato su
4KB di stored branch history che predice accuratamente se un branch sarà preso o no
circa il 95% delle volte. Predizioni errate hanno una penalità di 7 cicli, richiesti per
effettuare il back up, eseguire nuovamete il fetch della istruzione, e ripartire.
Tuttavia, UltraSPARC III mitiga l’impatto di misprediction occasionali, riducendo la
pena generale di branch misprediction a circa 4,5 cicli, grazie all’uso di una coda
speciale Branch Miss.
2.1.2.1.4 Eliminazione di colli di bottiglia della memoria
UltraSPARC III incorpora un approfondito e sistematico attacco a problemi di
performance relativi alla memoria, partendo dal design stesso della gerarchia di
memoria, e considerando di latenza di memoria (tempo di accesso) e banda.
- Organizzazione della memoria
Come gli altri processori a 64bit, UltraSPARC III permette ai programmi di operare
con un enorme spazio di indirizzamento di 16 quintillion (1018) di bytes, 4 billion (109)
di volte di più dei 4 gigabyte di indirizzamento limite dei processori a 32bit. Inoltre,
per i dispositivi off-chip, esso fornisce 43bit di address data – sufficienti per indirizzare
8 trillion byte (8 TeraBytes) di memoria fisica.
Un comprensivo assalto ai problemi relativi alle performance della memoria comincia
con una efficiente gerarchia di memoria, in grado di shiftare sistematicamente le
istruzioni ed i dati necessari per le computazioni il più possibile “vicino” alla CPU, e
gestire essi per quanto è necessario. In aggiunta alla memoria principale, UltraSPARC
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 25 di 40
III supporta due livelli di cache memory. Il primo livello (L1) consiste in quattro cache
separate, due grandi e due piccole. Il secondo livello (L2) consiste in una singola
cache grande.
Le due grandi cache L1 tengono le istruzioni ed i dati rispettivamente. Le due piccole
cache L1 sono una prefetch cache, principalmente usate da istruzioni di load per
gestire dati floating-point, ed una write cache, che serve per ridurre notevolmente
l’ammontare della banda di immagazzinaggio richiesta.
Tutte e quattro le cache L1 sono on-chip.
La grande cache L2 è una cache di istruzione e dati unificata. I contenuti della cache
L2 sono immagazzinati off-chip (nella SRAM), ma gli L2 address tags sono tenuti onchip per un accesso più veloce. La Figura 2.8 mostra l’organizzazione della memoria di
un sistema UltraSPARC III e la performance strategy associata.
Figura 2.8 – Gerarchia di Memoria di UltraSPARC III Cu
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 26 di 40
On-Chip Memory Management Units: La MMU contiene due TLB (Traslation Lookside
Buffer) che sono acceduti in parallelo durante l’address lookup: un TLB piccolo con a
16 ingressi, ed un TLB grande a 128 ingressi. La data MMU in UltraSPARC III Cu
contiene tre TLB che sono accedute in parallelo: una TLB piccola con 16 ingressi e due
TLB identiche con 512 ingressi (ogni TLB gestisce un indirizzo virtuale, l’indirizzo fisico
corrispondente, e altre page protection associate).
On-Chip L1 Data e Instruction Caches: Le cache L1 di dati ed istruzioni usano
entrambe una Sum-Address Memory (SAM) per il calcolo degli indirizzi, un tecnica che
combina due calcoli separati in uno. La data cache utilizza inoltre micro tags per
immagazzinare indici virtuali ad 8-bit. Entrembe le tecniche sopra elencate servono
per accelerare gli accessi alla cache.
On-Chip Instruction Prefetch Buffer: Questo piccolo buffer è usato quando una miss
nella cache L1 delle istruzioni ha un hit nei primi 32byte di una linea a 64byte o
sottoblocco nella cache L2. In questo caso, i primi 32bytes della linea sono riempiti
nella I-cache, e i secondi 32byte (necessari se il processo continua sequenzialmente)
sono salvate nell’IPB.
On-Chip L2 Cache Controller: Il cache L2 Controller supporta una larga cache da 8MB
esterna, come pure una piccola dalle dimensioni di 1MB e 4MB (per sistemi che
necessitano meno performance o per ottimizzare i costi)
On-Chip Prefetch Cache: Questa piccola cache da 2KB è acceduta in parallelo con la
data cache L1 per load floating-point. I dati possono essere piazzati in questa cache
dalle miss floating-point, o prefetch software o hardware. La prefetch cache fornisce
un punto di gestione on-chip per dati off-chip che possono prelevati prima del loro
uso.
On-Chip Write Cache: Il primo vantaggio offerto da questa piccola cache da 2KB è la
capacità di preservare banda. Nella sezione Memory Bandwidth approfondiremo
ulteriormente questo aspetto.
On-Chip Main Memory Controller: La Memory Control Unit on-chip (MCU) fornisce un
supporto built-in per chip SRAM da 133MHz. In base al numero ed alla densità dei chip
SRAM usati, la dimensione della memoria principale può variare da un minimo di
128MB ad un massimo di 16GB. La MCU fornisce segnali di controllo solo sulla
memoria, tutto il traffico risultante finisce attraverso il system data bus, controllato
dal system interface unit (si veda di seguito).
On-Chip System Interface Controller: Il System Interface Unit (SIU) on-chip
implementa tutta la logica necessaria per supportare protocolli efficienti per la
gestione dei traffico su bus e coerenza della cache.
La Tabella 2.1 mostra i dettagli riguardo i vari elementi del memory system di
UltraSPARC elencato sotto.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 27 di 40
STORAGE
BLOCK
LOCATED
LATENCY
(CYCLES)
SIZE
SETASSOCIATION
LINE
LENGTH
(BYTES)
WRITE POLICY
I-TLBs (2)
on-chip
2
16 ingressi
28 ingressi
fully
2-way
N/A
N/A
-
D-TLBs (3)
on-chip
2
16 ingressi
512 ingressi
512 ingressi
fully
2-way
2-way
N/A
N/A
N/A
-
L1 I-cache
on-chip
2
32 KB
4-way
32
write-invalidate
L1 D-cache
on-chip
2
64 KB
4-way
32
write-through
no write-allocate
on-chip
circa 5
1 line
N/A
32
N/A
on-chip
2
2 KB
4-way
64
write-invalidate
on-chip
varie
8 entry
N/A
N/A
N/A
Write Cache
on-chip
varie
2 KB
4-way
64
write-back
write-allocate
L2 Address
Tags
on-chip
2
90 KB
N/A
N/A
N/A
L2 Cache
off-chip
circa 19
8 MB
2-way
512
write-back
write-allocate
Main
Memory
off-chip
molti
fino a 16GB
N/A
N/A
N/A
I Prefetch
Buffer
Prefetch
Cache
Store
Queue
Tabella 2.1 - Instruction, Data, and Address Storage in UltraSPARC III Cu
- Latenza della Memoria
Un secondo fattore critico nell’evitare colli di bottiglia della memoria è la latenza,
misurata in numero di cicli di clock CPU necessari per accedere alla memoria.
UltraSPARC III paga considerevole attenzione per ridurre la latenza di memoria il più
possibile ad ogni livello della gerarchia di memoria.
Vediamo di seguito in dettaglio le latenze delle diverse componenti.
On-Chip L1 Data Cache: UltraSPARC III mantiene un accesso veloce (2 cicli) a tutte le
cache on-chip. Questo significa che penalità di latenza per accedere un dato trovato
nella data cache L1 può essere evitato inserendo una istruzione tra l’istruzione di load
e l’istruzione che utilizza i dati caricati.
On-Chip L1 Instruction Cache: Siccome UltraSPARC III può eseguire fino a quattro
nuove istruzioni ad ogni ciclo di clock, l’instruction cache L1 (come le altre cache onchip) usa una tecnica chiamata wave pipelining per abilitare il lancio dell’indirizzo del
prossimo gruppo di quattro istruzioni prima che il gruppo precedente sia ricevuto.
Il risultato è un rifornimento costante dei motori di esecuzione di UltraSPARC III ogni
ciclo di clock.
On-Chip Address Tags for L2 Cache: UltraSPARC III integra nella CPU non solo i
controllori per le cache L2 off-chip ma anche gli address tag per le cache L2. L’abilità
di elaborare gli address tag alla velocità del CPU clock accelera il calcolo delle hit/miss.
Off-Chip L2 Cache Data: La cache esterna può operare a diverse velocità multiple del
clock del processore, permettendo alle SRAM di essere selezionate sia per
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 28 di 40
performance che per bassi costi. Usando SRAM a 300MHz ad alte performance, nel
caso migliore la latenza della cache L2 per un processore UltraSPARC III a 1200MHz è
circa 19 cicli di clock. Dopo aver ricevuto informazioni su indirizzo, una L2 cache a
300MHz trasporta i dati richiesti da una CPU a 1200MHz ad un rate di 32 byte ogni 4
cicli di clock della CPU.
On-Chip Memory Controller: Integrando la MCU nella CPU riduce il tempo necessario
per accedere la memoria di circa il 30% (rispetto ad un memory controller off-chip).
Speculative Execution of Loads: Per contribuire a gestire la latenza causata
prelevando item dalla memoria, UltraSPARC III fornisce la capacità di eseguire load
speculativamente, ad esempio lanciandole prima, fuori sequenza.
Per items nella memoria principale, tuttavia, molti cicli di CPU trascorreranno tra il
tempo in cui un item è richiesto ed il tempo in cui è ricevuto. Per supportare
speculazione qui, UltraSPARC fornisce istruzioni di load speciali ad uso dei compilatori,
che hanno la grande overview richiesta per la pianificare l’acquisizione di dati lontani
in anticipo al loro uso.
Software Prefetching: Anche i compilatori possono prendere i dati prima del
necessario pubblicando le istruzioni di “prefetch” esplicite.
- Memory (and I/O) Bandwidth
In aggiunta alla costruzione di gerarchie di memoria che sistematicamente shiftano i
dati necessari e le istruzioni il più vicino possibile alle execution engine
(organizzazione), ed all’abbassamento del numero di clock necessari per accedere
ogni livello della gerarchia di memoria (latenza), un assalto completo ai problemi di
performance relativi alla memoria deve necessariamente aumentare la larghezza di
banda, la quantità di dati che possono essere trasferiti in una data unità di tempo.
La larghezza di banda è una funzione della larghezza di bus (numero di bit che
possono essere trasferiti in parallelo) moltiplicata per la frequenza del bus (tasso a cui
il bus cicla).
1,368-pin CLGA package: UltraSPARC III fa uso di un high pin-count Ceramic Land
Grid Array (CLGA) package, in gran parte per supportare due data bus separati che
ammontano ad una lunghezza di 384-bit (non contando i check ed address bit
associati). La larghezza di banda attraverso questi due bus è di 12.0GB al secondo.
256-bit Data Bus to L2 Cache: Usando SRAM a 300MHz, l’interconnessione alla cache
L2 permette che la CPU trasferisca le informazioni in e out ad un rate di 9.6GB al
secondo (muovendo 32-byte alla volta, 300 milioni di volte la secondo).
128-bit Data Bus to System (Memory, I/O, any remote CPUs): Il bus principale di
sistema può essere settato a diverse velocità multiple del clock del processore, fino ad
un massimo di 150MHz (1/8 del tasso di clock di una CPU a 1200MHz). A 150MHz, la
CPU può trasferire dati ed istruzioni da e verso il sistema ad un rate di 2.4GB al
secondo (muovendo 16-byte alla volta, 150 milioni di volte la secondo) – banda a
sufficienza per leggere o scrivere completamente una memoria principale da 16GB in
7.16 secondi.
On-Chip Memory Controller: La MCU può gestire fino a 15 richieste di load/store allo
stesso tempo, con completamento out-of-order.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 29 di 40
8-Entry Store Queue: Questo buffer per operazioni di store serve per disaccoppiare
l’emissione delle store dalla loro esecuzione (allo stesso modo in cui la coda delle
istruzioni disaccoppia il fetch delle istruzioni dalla loro esecuzione). Le store
rimangono in questa coda fino a che non completino un aggiornamento alla Write
cache, permettendo che le store relazionate vengano unite insieme e riducendo
notevolmente le esigenze nei confronti della larghezza di banda esterna.
Write Cache: Questa on-chip cache, benché piccola (2KB), ha un grande impatto sul
traffico di store. La Write cache può unire molte piccole operazioni relazionate in una
operazione più grande, in grado di trarre un vantaggio migliore sul largo data bus alla
cache L2. Il risultato è una riduzione notevole del traffico di write-through da L1,
eliminando fino al 90% delle operazioni separate di store richieste.
Figura 2.9 – Caratteristiche di performance di UltraSPARC III Cu
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 30 di 40
2.1.2.1.5 Accelerare le computazioni con istruzioni speciali
Esistono numerosi task computazionali importanti che coinvolgono l’esecuzione di uno
o più operazioni altamente specializzate, necessarie ad esempio per accelerare
applicazioni multimediali e di rete.
Vediamo qualche esempio.
- Processing Media-centric Code
UltraSPARC I fu il primo processore general-purpose ad includere uno special set di
istruzioni per accelerare applicazioni multimediali e grafiche, chiamate VIS (si veda di
seguito). UltraSPARC III estende l’eredità di UltraSPARC I con nuove istruzioni capaci
ad esempio di estrarre i dati di pixel da una immagine. Ciò ed altri miglioramenti
VISibili garantiscono un nuovo numero di versione, per distinguere la funzionalità di
VIS 2.0 disponibile con UltraSPARC III dalla funzionalità di VIS 1.0 disponibile con le
prime due generazioni dei processori UltraSPARC.
Nel paragrafo 2.1.4 analizzeremo più in dettaglio VIS.
- Processing Scientific Code
Il set di operazioni aritmetiche al cuore di VIS forniscono funzionalità necessarie per
accelerare una larga varietà di algoritmi tecnici tipici della High Performance
Computing (HPC). Ad esempio, VIS 2.0 aggiunge il supporto per l’aritmetica di
intervallo, rendendole molto veloci alcune tipologie di computazioni numeriche.
- Processing Java Code
In aggiunta per migliorare il dynamic branch prediction, UltraSPARC III aggiunge una
istruzione prepare-to-branch, che permette al software di specificare in anticipo la
posizione delle branch target instrucions alla fetch unit, in modo tale che l’indirizzo
possa essere computato in anticipo. Ad esempio nel codice Java, dove un interprete di
byte code potrebbe spendere fino a metà del suo tempo saltando alle nuove
procedure, il miglioramento delle prestazioni è notevole.
- Processing Network-centric Code
Come le precedenti generazioni di UltraSPARC, UltraSPARC III offre blocchi di
istruzioni load/store parallelizzate che permettono di copiare dati da una locazione
nella memoria centrale ad un’altra locazione, senza essere immagazzinati nella cache,
velocizzando dunque il trasferimento di dati.
2.1.2.2 Caratteristiche per migliorare RAS
2.1.2.2.1 Error Detection and Correction (EDC)
Per assicurare l’integrità dei dati salvati, UltraSPARC III fornisce protezioni contro vari
errori che è possibile riscontrare in grandi semiconductor memory arrays. Le due
grandi cache L1 on-chip sono entrambe protette dal controllo di parità, in grado di
rilevare ogni singolo errore su bit dovuti a diverse cause. Se avviene un errore di
parità, la linea errata della cache L1 è marcata come invalida, innescando un ricambio
della linea con dati corretti dalla cache L2 (durante l’accesso successivo).
Le memorie off-chip (la cache L2, includendo il suo address tag on-chip e la memoria
centrale) sono protette da Error Correcting Code (ECC). Questo può rilevare e
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 31 di 40
correggere un singolo bit errato, e rilevare (ma non correggere) due bit errati. I dati
rilevati errati ma non corretti sono segnati come invalidi.
2.1.2.2.2 Diagnostic Bus
UltraSPARC III include uno speciale bus a 8-bit che opera in modo indipendentemente
dal bus principale di sistema. La CPU può caricare il sistema da flash PROM tramite
questo bus, e può accedere periferiche come console seriali. In questo modo il sistema
è configurabile e testabile anche se la maggior parte di esso non è operativa. Durante
il normale funzionamento, il diagnostic bus può essere utilizzato per monitorare la
condizione interna del processore in tempo reale, permettendo sia l'individuazione
tempestiva dei meccanismi di fallimento che la manutenzione proattiva per impedire o
limitare i guasti.
2.1.2.2.3 Error Removal And Recovery
Siccome ogni CPU UltraSPARC III controlla la sua memoria locale, rilevando e
correggendo ogni singolo bit corrotto, la minaccia di un errore di dati che si propaga in
altre CPUs in un sistema MP è eliminata in molti casi.
Dove gli errori non possono essere corretti, la capacità di UltraSPARC III di
contrassegnare i dati come non validi permette almeno che gli errori siano contenuti.
2.1.2.2.4 Lockstepping
UltraSPARC III sostiene lockstepping, o la capacità di due o più CPU di sincronizzare le
operazioni dal reset. Questa caratteristica è usata nei sistemi fault-tolerant, in cui
CPUs multipli calcolano la stessa cosa allo stesso tempo e confrontano i risultati.
2.1.3 UltraSPARC IV
Il processore superscalare UltraSPARC IV è fra i primi processori Chip Multithreading
(CMT) che segue la strategia Sun Throughput Computing ed è pienamente compatibile
con l’Instruction Set Architecture (ISA) SPARC-V9 a 64bit.
Gli odierni processor single-core tradizionali possono processare soltanto un thread
alla volta, spendendo la maggioranza del tempo attendendo i dati dalla memoria.
Chip Multithreading (CMT) si riferisce alla capacità del processore di processare thread
software multipli. Un processore CMT può implementare questo capacità multithread
usando diversi di metodi: Core multipli su un singolo chip (CMP), Thread multipli su
singolo core (SMT) oppure la combinazione di CMP e di SMT.
UltraSPARC IV è un processore dual-thread e supporta fino a 16MB di external level-2
(L2) cache. Ad eccezione di un pin, UltraSPARC IV ha lo stesso footprint di un
processore UltraSPARC III. Questo punto nel design minimizza le modifiche da
apportare alle motherboard e il time-to-market.
L’obiettivo di design primario per il processore UltraSPARC IV è quello di migliorare le
prestazioni di rendimento nelle applicazioni commerciali come database, web server
ed High Performance Technical Computing (HPTC). Le segunti tecniche chiave sono
usate per migliorare le performance del processore UltraSPARC IV:
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 32 di 40
•
Implementare capacità di elaborazione dual-thread
La tecnologia CMT raddoppia le current compute density e riduce la dissipazione
di calore generale, con conseguente risparmio e relativo vantaggio per l’utente
finale.
•
Migliore configurazione della cache Level 2 (L2)
Ogni thread nel processore UltraSPARC IV può accedere gli 8MB della cache L2
a 2-vie, set-associative. La line size della cache L2 è stata cambiata da
512bytes a 128bytes per ridurre il conflitto di dati associati con i sub-blocked
caches.
•
Migliore Floating Point Unit
Una FPU produce elevate performance su diverse tipologie di codice quale ad
esempio quello per l’implementazione della Fast Fourier Trasform (FFT). La FPU
è assistita da hardware addizionale per IEEE 754-1985 exception processing.
•
Migliore write cache
La write cache, usata per ridurre gli usi inefficenti della banda nel cache bus, è
stata migliorata con un algoritmo hashed-index per ridurre la latenza write
cache.
I thread che vengono eseguiti sul processore UltraSPARC IV condividono: indirizzi e
data bus per accedere i dati della cache L2, la Memory Control Unit (MCU) e il Sun
Fireplane Interconnect port. I bus alla cache L2 ed i moduli fisici della SRAM
contenenti le cache L2 sono condivisi. Benchè la cache L2 sia logicamente separata
per ogni thread in esecuzione sul processore UltraSPARC IV, la cache L2 è fisicamente
contenuta in un modulo SRAM.
La Figura 2.10 mostra lo schema a blocchi del processore UltraSPARC IV.
Figura 2.10 – Il processore UltraSPARC IV
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 33 di 40
La Tabella 2.2 elenca miglioramenti in esecuzioni single-thread includendo incrementi
di clock rate e un nuova organizzazione della cache.
Caratteristica
Beneficio
Ogni thread eseguito sul processore UltraSPARC IV
può accedere gli 8MB della cache L2 con 128byte di
line size (2 sub-blocks per line) o 4Mb con 64byte
per line size (no sub-block)
Cache più efficiente su un largo range di
applicazioni
Cache L2 impiega last-recently-used (LRU) eviction
strategy
LRU è una cache eviction policy che porta ad avere
un migliore hit cache, favorendo esecuzioni veloci e
un throughput di sistema migliore
Supporta un elevato system clock divisors
Aumenta il system throughput performance totale
permettendo alti clock multipli di 150MHz
L2 cache address bus error protection
Comporta una elevata affidabilità
Hash-indexing per cache di scrittura
Decrementa i conflitti durante scritture multiple
portando ad avere un elevate banda di store e
performance totali
Hardware addizionale per il processamento delle
eccezioni floating-point IEEE 754-1985
Decrementa l’overhead di sistema permettendo alla
logica hardware del processore di eseguire il
processamento delle eccezioni piuttosto che
inoltrarle al software dek sistema operativo
Software prefetch semantics usata con l’hardware
prefetch cache
Elevate performance in floating-point
Tabella 2.2 – Miglioramenti introdotti nel processore UltraSPARC IV
La Tabella 2.3 elenca i cambiamenti dovuti alla tecnologia CMT implementata nel
processore UltraSPARC IV.
Miglioramenti CMT
Le risorse come i registri MCU, pin, e registri Sun Fireplane sono condivisi cosicchè ogni thread nel
processore sia in grado di accederli.
Nuovi registri sono stati aggiunti per supportare il Modello Sun Standard CMT, permettendo la
compatibilità gli standard di sistema operativo e con tutti i processori CMT di Sun
Registri di processore inizializzati con valori associati con CMT.
Aggiunto un nuovo registro per-thread ASI_CESR_ID. Questo è un thread ID associato con il Sun
Fireplane Interconnected block I/O. Un dispositivo remoto può identificare il thread sorgente di un blocco
di dati
Tabella 2.3 – Miglioramenti dovuti alla tecnologia CMT
Il processore UltraSPARC IV eredita tutte le features di affidabilità, disponibilità e
servizio (RAS - reliability, availability, and serviceability) implementate nel processore
UltraSPARC III con l’aggiunta di L2 cache address bus error protection.
Il data bus tra il processore UltraSPARC III e la cache L2 esterna è protetto con Error
Check/Correction Code (ECC).
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 34 di 40
Il processore dual-thread UltraSPARC IV fa parte della prima generazione di processori
CMT sviluppati da Sun per mid-range e high-end server.
Per i prossimi processori nella famiglia di UltraSPARC IV saranno ulteriormente
migliorate le performance già ottenute dalla prima generazione dei processori
UltraSPARC IV.
2.1.4 Visual Instruction Set (VIS)
La richiesta di grafica avanzata nei processori general-purpose è dovuta alla crescita
di settori molto diversi, come la videoconferenza, la visualizzazione 3D, l'animazione,
la realtà virtuale, le trasmissioni dati. L'UltraSPARC utilizza una potenza di
elaborazione a 64 bit, che fornisce il throughput necessario per la grafica avanzata e
le applicazioni video in tempo reale.
Le estensioni VIS (Visual Instruction Set) al set di istruzioni standard dell'UltraSPARC
permettono il completamento di istruzioni complesse, che tipicamente richiederebbero
dozzine di cicli di clock, in un singolo ciclo. Ciò è ottenuto con operazioni di tipo SIMD
(Single Instruction Multiple Data).
L'UltraSPARC è basato su un'architettura superscalare, con quattro pipeline che
possono eseguire le istruzioni in parallelo. Ci sono due pipeline nell'unità interi e due
in un'unità speciale detta Floating Graphics, che si occupa dell'esecuzione delle
istruzioni
VIS.
Con un'istruzione di somma VIS, quattro operandi a 16 bit vengono caricati in un
registro a 64 bit, e quattro in un altro registro. Quindi, in un singolo ciclo di clock
vengono eseguite quattro operazioni di somma a 16 bit.
Figura 2.11 L'istruzione VIS mul8x16
I campi in cui vengono utilizzate le estensioni VIS sono molti; nei prossimi paragrafi
analizziamo i due più significativi:
•
•
L'accelerazione delle funzioni di networking
La decodifica MPEG2 in tempo reale
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 35 di 40
2.1.6.1 VIS e l'accelerazione delle funzioni di networking
Con il set di istruzioni VIS, i processori UltraSPARC possono muovere dati ed eseguire
i calcoli richiesti dalle routine di rete più velocemente, grazie a due categorie di
istruzioni:
•
Aritmetica parallela: il VIS include operazioni matematiche di tipo SIMD, che
possono essere utilizzate per accelerare funzioni intensive di tipo I/O oppure di
networking.
•
Spostamento dati: il VIS possiede anche istruzioni che effettuano il load e lo
store in blocchi da 64 bit; ciò permette di accelerare le operazioni di I/O che si
presentano nel protocollo TCP/IP, ottenendo così un aumento delle performance
delle operazioni di rete. Ad esempio, il movimento dei dati tra buffer di
memoria viene aumentato di un fattore pari a 1.9X.
Le routine utilizzate per muovere segmenti di dati lungo una rete sono funzioni timecritical, che hanno un notevole impatto sulle prestazioni della rete.
Quando una tipica applicazione di rete legge o scrive dati fra i nodi, una chiamata di
sistema read/write inizia il movimento dei dati attraverso un driver di rete, che
trasferisce tali dati dalla memoria alla scheda di rete. Le istruzioni VIS di load e store
possono essere utilizzate per accelerare le operazioni di copia dei dati: più parole
possono essere trasferite utilizzando una singola istruzione, bypassando la memoria
cache. Ciò aumenta notevolmente il flusso di dati aggregati, rispetto alla copia delle
stesse regioni di memoria attraverso le tradizionali operazioni di load/store.
2.1.6.2
Il VIS e la decodifica MPEG2 in tempo reale
L'UltraSparc è stato il primo processore general-purpose capace di comprimere le
informazioni video in MPEG2, eliminando la necessità di un costoso sottosistema video
con processore dedicato.
Ciò è possibile grazie all'architettura dell'UltraSparc, composta da due ALU per gli
interi e un'unità floating point e grafica (FPGU), in grado di fornire cinque unità
funzionali:
•
•
•
•
•
Divisione/radice quadrata in virgola mobile
Addizione/sottrazione/valore assoluto/negazione in virgola mobile
Moltiplicazione in virgola mobile
Addizione grafica
Moltiplicazione grafica
Nonostante la potenza nella manipolazione intera e floating point, il throughput che si
ottiene con UltraSPARC non è sufficiente per la manipolazione di video digitale in
tempo reale; aggiungendo parallelismo al modo di manipolare dati del processore è la
via più elegante per superare anche questo limite.
Le istruzioni VIS possono infatti elaborare quattro pixel in una sola operazione,
effettuando la moltiplicazione, l'addizione, la somma o la valutazione logica; inoltre
sono presenti speciali istruzioni che migliorano specificatamente le prestazioni della
compressione/decompressione video. Per esempio una sola istruzione VIS, che calcola
la somma della differenza assoluta fra due vettori di otto pixel, sostituisce le 48
operazioni richieste da molti dei processori convenzionali.
In generale, il VIS fornisce un miglioramento di circa quattro volte in molte delle
operazioni time-critical della compressione/decompressione video, con un'occupazione
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 36 di 40
di area del chip da parte delle istruzioni grafiche pari solamente al 3%. Guadagni
ulteriori si possono avere nelle configurazioni multiprocessore.
2.2 LEON
LEON, è una implementazione completamente open source scritta in VHDL sviluppata
da Gaisler Research in collaborazione con l’Agenzia Spaziale Europea (ESA).
LEON è descritto da un modello VHDL sintetizzabile di un processore a 32 bit
compatibile con l’architettura SPARC-V8. Il codice sorgente è distribuito con licenza
GNU LGPL ed è dunque liberamente utilizzabile e modificabile.
Il processore (Figura 2.12) include una integer unit con pipeline a cinque stadi, due
cache a mappatura diretta e controllo di parità per dati e istruzioni, 136 registri da 32
bit divisi in otto finestre. Il codice sorgente preso in considerazione (relativo alla
versione 2.2) include anche:
•
•
•
Un controller per memorie a 8 o 32 bit, che fornisce un’interfaccia per PROM,
SRAM e dispositivi di I/O memory mapped;
Un controller di interrupt in grado di gestire fino a 15 segnali provenienti
dall’interno o dall’esterno del processore;
Una porta di I/O a 32 bit, che può essere utilizzata anche per l’ingresso degli
interrupt provenienti dall’esterno del processore.
Aderendo allo standard SPARC, con LEON possono essere usati compilatori
e kernel per l’architettura SPARC V8. Inoltre Gaisler Research fornisce un compilatore
C/C++ per LEON, LECCS, e un simulatore del processore, TSIM, che può essere
interfacciato a gdb e riprodurre fedelmente il funzionamento del LEON.
Figura 2.12: Diagramma a blocchi del processore LEON
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 37 di 40
2.3 Altre Soluzioni
Di seguito riportiamo per completezza altre soluzioni conformi allo standard SPARC,
ma ormai obsolete.
2.3.1 Super SPARC
Questa è una soluzione proposta da Texas Instrument in associazione con Sun.
Usualmente lavora ad una frequenza di clock intorno a 50 MHz ed è caratterizzata da
cache fino a 1MB L2, è disponibile entrambi su moduli a processore singolo e doppio.
Dal punto di vista tecnico, questa è una implementazione di SPARC-V8, è un
processore superscalare, con due cache, una per le istruzioni ed un’altra per i dati.
•
•
L’instruction cache da 20KB è associativa a 5 vie.
La data cache da 16KB è associativa a 4 vie.
2.3.2 Sun SPARC
Ormai parecchio obsoleta, è una implementazione dello Standard SPARC-V7; la
caratteristica principale è una Integer Unit (IU), una Floating Point Unit (FPU) esterna,
una direct associative cache unificata (dati e istruzioni) da 64 KB e una Memory
Management Unit (MMU). Esiste una pipeline di 4 fasi per le istruzioni intere (fetch F,
decode D, exec E, update WB). FPU e ed IU sono sincronizzati.
2.3.3 Micro SPARC
Questa è ancora una soluzione implementata da Texas Instrument in associazione con
Sun, usata nelle SparcStation Classic, SparcStation LX, ad una frequenza superiore ai
50MHz. Un suo derivato, MicroSpacr II, può essere trovato in SparcStation 4,
SparcStation 5 ad una frequenza superiore ai 110MHz.
Dal punto di vista tecnico, le sue caratteristiche principali sono un alto livello di
integrazione, la presenza di due cache, una per i dati ed una per le istruzioni.
•
•
Instruction direct associative cache da 4KB
Data direct associative cache da 2KB
2.3.4 Hyper SPARC
Questo processore è stato introdotto da ROSS nel 1993, ed è usualmente utilizzato
dalle SparcStation 10 e SparcStation20, ad una frequenza di 150MHz, ed è disponibile
su entrambi moduli a processore singolo e doppio.
Dal punto di vista tecnico è un’implementazione della specifica SPARC-V8, ed è
superscalare. E’ disponibile con L2 cache superiore a 512KB.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 38 di 40
3.0 Conclusioni e Sviluppi Futuri
Scalable Processor ARChitecture (SPARC) permette di avare processori ad alte
prestazioni e di implementare sistemi a diversi rapporti di prezzo e prestazioni.
In questa analisi abbiamo visto come i concetti tipici della strutturazione RISC di una
macchina convenzionale sono stati messi in pratica per la definizione e realizzazione
dell'architettura SPARC. In particolare, abbiamo analizzato l’architettura interna e le
principali funzionalità delle diverse unità di un processore SPARC. Inoltre, abbiamo
descritto le principali implementazioni, focalizzando l’attenzione su UltraSPARC, il
progetto attualmente più attivo ed aggiornato.
Possiamo dunque dichiarare che i processori SPARC forniscono un’ottima soluzione per
ambienti enterprise, grazie alle ottime performance ed in alcuni casi alla capacità di
fornire soluzioni robuste e performanti anche per ambienti mission-critical.
Concludiamo questa analisi affermando che attualmente Sun Microsystem sta
lavorando ad una nuova implementazione di UltraSPARC, in cui la tecnologia 90nm di
Texas Instrument, l’aumento della frequenza di clock, la banda, e l’aggiunta una
cache level-3 sono solo alcune delle nuove feature.
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 39 di 40
4.0 Riferimenti
[1]
Sito web Sparc International
www.sparcinternational.com
[2]
Sito web Sun Microsystem
www.sun.com/processors
[3]
The SPARC Architecture Manual Versione 9
www.sparc.com/standards/SPARCV9.pdf
[4]
The SPARC Architecture Manual Versione 8
www.sparc.com/standards/V8.pdf
[5]
Sito web SPARC
www.sparc.com/history.html
[6]
Sito web Texas Instruments
www.ti.com
[7]
Sito web Gaisler Research
www.gaisler.com
[8]
Wikipedia
en.wikipedia.org/wiki/SPARC
[9]
J. Vahid, T.Givargis
“Embedded System Design “, 2003
____________________________________________________________________________________
SPARC Architecture Overview
Pagina 40 di 40