\articolo{Uno host bridge PCI a 32 bit per il processore MC68020 a 14\,Mhz}{Paolo Canali}
\paragrafo{Scopi del progetto}
\noindent Un bus è un insieme di conduttori che connette tra loro i componenti
(``agenti'') di un sistema perché possano comunicare; se viene realizzato
sotto forma di connettori (che prendono il nome di ``slot'') adatti ad
accogliere schede o moduli saldati su un circuito stampato si chiama
``backplane''. Finora, ogni famiglia di personal computer ha utilizzato un
proprio backplane, diverso dagli altri: i personal in architettura {\az Intel}
sono dotati di slot ISA, i {Macintosh} di {Nubus}, gli \A
di slot {Zorro}, i computer {\az Sun} di S-bus, le macchine {\az Digital}
di Q-bus, le {\az Silicon Graphics} di GIO e così via.

Oggi però gli slot di espansione local bus conformi alle specifiche PCI,
nati sui PC in architettura {\az Intel}, sono progressivamente diventati uno
standard universale. A meno di tre anni dalla pubblicazione della revisione
2.0 delle specifiche, anche molti calcolatori non {\az IBM} compatibili vengono
dotati di slot di espansione PCI 2.0 nella versione a 32 bit e tensioni di 5
volt. Di conseguenza, la quasi totalità dei chip periferici moderni
(controller grafici, chip SCSI-2 e UltraSCSI ecc.) è disponibile solo con
questa interfaccia. PCI 2.0 soppianterà tutti i bus proprietari che oggi
hanno prestazioni e popolarità insufficienti a giustificare la loro
esistenza, come Zorro III: entro brevissimo tempo, con il passaggio alle
tecnologie a 3 Volt (già previste dallo standard, figura~\ref{fig:pci1})
\begin{figure}[ht]
\def\epsfsize#1#2{0.1#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 2175 1025]{pci/fig1.ps}\end{center}
\caption{\label{fig:pci1}\small Sistema di identificazione delle schede basato sulla forma
del connettore}
\end{figure}
un computer
privo di slot PCI resterà tagliato fuori da qualsiasi possibilità di
espansione interessante.

Nell'attuale versione commerciale a ``basse prestazioni'' il bus PCI usa 32
linee per dati e indirizzi, ed è già capace di trasferire più di 130
Megabyte al secondo (durante i picchi di attività). Lo standard PCI 2.0
prevede una variante a 64 bit capace di trasferire fino a 8 byte a ogni
ciclo di clock, con frequenza massima di 33\,MHz (quindi in grado di spostare
264 Megabyte al secondo); è allo studio la possibilità di ottenere oltre
500 Megabyte al secondo raddoppiando il clock. È consentito usare nello
stesso sistema più di un bus PCI operante in concorrenza con gli altri, per
sfruttare a pieno le CPU con local bus operante attorno al Gb/sec e i
sistemi multimaster.

Per la migliore comprensione dell'argomento bisognerebbe conoscere almeno i
principi di funzionamento del bus PCI, che purtroppo non possono essere
forniti in questa sede per ovvi motivi di spazio. Si rimanda alla ormai
copiosa letteratura tecnica sull'argomento: ad esempio le specifiche
originali {\az Intel}, i libri di commento e spiegazione pubblicati da alcuni
editori scientifici internazionali (sono reperibili presso qualsiasi
libreria specializzata italiana a circa 100\,000 lire l'uno), o anche la
rubrica \emph{Transaction} di \emph{Amiga Magazine}.

Comunque, è bene chiarire che tecnicamente PCI non è un ``local bus'': è
invece un ``mezzanine bus'', cioè un particolare backplane di espansione
sincrono veloce. In altre parole, si tratta di un nuovo componente dei
personal computer senza equivalenti sulle architetture tradizionali; la
nuova architettura del calcolatore diventa quella di figura~\ref{fig:pci2}.
\begin{figure}[ht]
\def\epsfsize#1#2{0.1#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 2300 1470]{pci/fig2.ps}\end{center}
\caption{\label{fig:pci2}\small Tipica struttura di un calcolatore moderno,
con due backplane, due bus (uno di I/O) e due bridge}
\end{figure}
Infatti
forzando un microprocessore a usare il local bus di un'altra famiglia di
CPU non si otterrebbe alcun vantaggio in termini di prestazioni, perché
ogni local bus vero e proprio (che è formato dai segnali sui piedini della
CPU) è ottimizzato per il particolare tipo di accesso a memoria e
periferiche del singolo microprocessore.

PCI è totalmente distinto dal local bus, anche sui PC in architettura
{\az Intel}, e utilizza segnali e protocollo studiati per essere efficenti con
qualsiasi tipo di microprocessore e con la grande maggioranza delle
architetture di macchina oggi in commercio. La denominazione ``PCI local bus''
è stata coniata solo per indicare sinteticamente agli acquirenti di PC in
architettura {\az Intel} che questo bus è qualcosa di più nuovo e veloce di
quello standard. Così non è stato necessario introdurre un nuovo concetto
nella mente nell'utente medio di quei sistemi, impresa di esito incerto che
avrebbe richiesto milioni di dollari in investimenti pubblicitari.

Il circuito che interfaccia la CPU agli slot PCI si chiama ``host bridge''. Di
solito è un comune chip con un centinaio di piedini, collegati in parte
alla CPU e in parte agli slot PCI, che ha il compito di convertire il
protocollo di trasferimento dati seguito dal local bus della CPU nel
protocollo PCI 2.0. Non è per niente un compito banale, e non si può
portare avanti in modo efficente e affidabile usando risorse limitate come
i chip PAL (sufficienti invece per il bus ISA).

Per i processori RISC (PowerPC, ARM, Alpha ecc.) esistono decine di questi
chip, adatti a ogni livello di prestazioni e frequenza di clock.
Addirittura, una versione della CPU Alpha già contiene internamente l'host
bridge PCI; ciò conferma che l'adozione di un'architettura RISC garantisce
automaticamente l'inserimento nel flusso principale dell'innovazione
tecnologica.

La scelta si riduce drasticamente nel caso delle ``vecchie'' CPU CISC, dove
host bridge già pronti esistono solo per i processori a 32 bit più
recenti. Ad esempio, Newbridge Microsystem realizza un bridge per il local
bus sincrono di 68040 e 68060. Altri (come Applied Micro Circuits
Corporation) propongono delle specie di kit costituiti da un bus controller
PCI 2.0 semiconfigurabile e capace di effettuare la conversione big/little
endian richiesta per il 68040 e 68060: ma la flessibilità è limitata, e
sono previste un numero limitato di applicazioni.

Per 68000, 68020 e 68030 non esiste assolutamente nulla: senza uno host
bridge PCI, il divario di prestazioni tra le schede per gli attuali \A e
quelle per tutti gli altri computer entro uno o due anni diventerebbe
abissale. Ciò sarebbe particolarmente sgradevole per i possessori di \A
1200: per anni (fino a pochi mesi fa) non hanno avuto a disposizione né
68040 o 68060, ed è preclusa ogni possibilità di espansione a 32 bit con
schede Zorro III.

Per gli \A modulari, alcuni produttori di schede grafiche (come {\az Village
Tronic}), hanno aggirato il problema realizzando in proprio un chip bridge
tra bus Zorro e PCI, da includere in ogni scheda. È una soluzione semplice,
ma fa aumentare spaventosamente i costi e rovina le prestazioni
dell'interfaccia PCI.

La soluzione migliore consiste nel realizzare una schedina per lo slot CPU
di \A munita di connettore di replica del local bus (per le eventuali
schede acceleratrici), un chip host bridge da 680x0 a PCI 2.0, e uno o più
connettori PCI in grado di accogliere le stesse schede usate sui PC {\az Intel} o
sulle macchine RISC: è proprio questa la soluzione esplorata nel progetto
realizzato.

\paragrafo{Caratteristiche}
\noindent Uno host bridge si può realizzare in molti modi
diversi; poiché influenza le prestazioni del computer bisognerebbe
esaminare molti aspetti:

\begin{itemize}
\item{acquisizione dei bus;}
\item{coerenza dell'indirizzamento;}
\item{gestione comunicazioni tra rami non direttamente collegati;}
\item{ordinamento dei dati;}
\item{gestione degli interrupt e delle eccezioni;}
\item{influenza dei buffer locali e dei modi di trasferimento speciali;}
\item{controllo della latenza;}
\item{verifica dell'interoperabilità degli agenti;}
\item{bus locking;}
\item{testabilità;}
\item{caratteristiche elettriche;}
\item{\ldots e tanto altro ancora.}
\end{itemize}

Un bridge a 32 bit ideale (figura~\ref{fig:pci3})
\begin{figure}[ht]
\def\epsfsize#1#2{0.1#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 1989 1490]{pci/fig3.ps}\end{center}
\caption{\label{fig:pci3}\small Struttura di uno host bridge in grado
di supportare il DMA in modo efficiente}
\end{figure}
sfrutta a fondo i modi di trasferimento
dati ``burst'' supportati da PCI; funziona in modo sincrono a 33\,Mhz senza
stati d'attesa; ha un'ottima gestione del ``bus mastering'' (su \A si
chiamerebbe DMA) per gestire autonomamente stream di dati multimediali senza
intervento della CPU; consente la creazione di computer con più CPU che
lavorano in parallelo. Per ottenere ciò ingloba sia il controllore della
cache secondaria che della Fast RAM, in quanto uno host bridge di questo tipo
deve poter accedere ad alcuni dei loro segnali interni.

Specifiche di questo genere non sono disponibili neanche nella terza
generazione di host bridge {\az Intel}, i più evoluti attualmente in commercio.
Non sarebbe realistico inseguirle in una implementazione per \A di prima
generazione: meglio iniziare dalle cose semplici e aggiungere ma mano nuove
funzioni. Il progetto è stato quindi suddiviso in varie fasi:

\begin{enumerate}
\item{La prima
fase, l'unica già portata a termine, è essenzialmente uno studio di
fattibilità approfondito: è stato realizzato e verificato il corretto
funzionamento del ``cuore'' del bridge, arrivando a definire quali sono le
strade migliori per realizzarlo e isolando le aree del progetto che sono
critiche per le prestazioni o per il costo.

Il risultato è stato decisamente positivo: il circuito esegue correttamente
la conversione di protocollo tra un generico bus locale 68020 a 14\,MHz e PCI
2.0 in versione a 32 bit e 5 Volt, e si può costruire in modo compatibile (per
costo e tecnologia utilizzata) con una normale processo industriale.

Schede di questo tipo non richiedono volumi di produzione elevati e costi
minimi, mentre è importante poter mettere a punto ed eventualmente
personalizzare il progetto nel minor tempo possibile: il campo di
applicazione tipico delle FPGA (Field Programmable Gate Array, cioè un
insieme di porte logiche con interconnessioni programmabili). Usando
componenti a media densità, il progetto finale sarebbe valido anche per
produzioni in serie dell'ordine della decina di migliaia di pezzi.

In questa fase non è stata prestata attenzione alle prestazioni, che
comunque le simulazioni finali mostrano essere circa 8\,Mbyte al secondo.
}
\item{
Nella seconda fase bisognerà scegliere la specializzazione del circuito
più opportuna, e riprogettare l'host bridge in modo da soddisfare i
requisiti. Si deve cioè decidere per quale modello di \A deve essere
costruito, se sono più importanti i costi o le prestazioni, e quindi
impostare un progetto che faccia uso della tecnologia più opportuna.}
\item{Durante la terza fase, congelate le specifiche, si realizzano prototipi
da raffinare esaminando il comportamento con le varie combinazioni di
espansioni per \A in commercio.}
\end{enumerate}

In questa fase andrebbe risolto anche il problema del firmware. A livello
elementare è sufficiente realizzare un layer software che gestisca il
processo di autoconfigurazione in standard PCI e lo converta in informazioni
comprensibili al sistema operativo attuale; il BIOS della scheda verrebbe
del tutto ignorato. Attualmente i produttori possono seguire due standard
per realizzare il BIOS della scheda, cioè per organizzare il contenuto
della sua ROM.

Il primo è basato sui meccanismi dell'{IBM PC} originale: la ROM contiene
alcune semplici tabelle per l'identificazione e qualche Kilobyte di codice per
processori in architettura {\az Intel}, eseguibile negli ambienti DOS e Windows.
La quasi totalità delle schede PCI in commercio segue questo standard,
quindi su \A il BIOS non verrebbe usato, e per ogni scheda occorre uno
specifico driver software.

Il secondo formato è frutto delle specifiche OpenFirmware (appoggiate anche
da IBM e Apple). La ROM contiene strutture dati che descrivono nel dettaglio
i registri e il modo di funzionamento della scheda, più una collezione di
routine scritte in un linguaggio ``ad alto livello'': in questo modo le
caratteristiche di base di una qualunque scheda possono essere utilizzate
senza bisogno di driver specifici, perché basta il supporto standard ad
OpenFirmware.

Per riassumere, alla prima fase del progetto è stata data una risposta
positiva alla domanda ``Si può fare un'interfaccia PCI per \A usando
componenti e strumenti accessibili?''; la seconda pone il problema ``Come si
vuole fare?'' e la terza ``Come si costruisce?''.

\paragrafo{Strumenti}
\noindent Lo strumento più adatto per realizzare il prototipo durante la prima fase
sono i chip logici programmabili ad alta complessità (EPLD e FPGA).

FPGA dichiarate ``PCI compliant'' vengono prodotte da Quicklogic (serie
Wildcat 8000, le consegne sono iniziate a giugno 95), AT\&T (famiglia ORCA) e
Altera (famiglie Max 7000 e Flex 8000). Altri produttori hanno annunciato
disponibilità più o meno immediate di componenti simili.

Sono stati scelti i chip Altera, grazie alla disponibilità di un sistema di
sviluppo sofisticato Max+plus II, figura~\ref{fig:pci4})
\begin{figure}[ht]
\def\epsfsize#1#2{0.2#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 1024 768]{pci/fig4.ps}\end{center}
\caption{\label{fig:pci4}\small Il sistema di sviluppo Max+plus II}
\end{figure}
con il quale è possibile
apportare modifiche ed eseguire simulazioni in un tempo relativamente breve.
La versione di Max+plus II utilizzata è la 3.20 per ambiente Windows, con
le relative librerie standard per le macrofunzioni e lasciando le opzioni
per la sintesi logica ai valori consigliati. Purtroppo non esiste alcun CAD
elettronico per \A in grado di lavorare su FPGA né si prevede la
disponibilità futura di software di questo tipo. In seguito (magari usando
altri chip o soluzioni miste FPGA/TTL) si potrà recuparare buona parte del
lavoro svolto grazie alla disponibilità di filtri di esportazione dei file
di progetto in formati standard come VHDL. Sfortunatamente i chip Altera
sono inadatti a una realizzazione in serie, perché i modelli di interesse
per questo progetto hanno un costo proibitivo (sulle 400\,000 lire l'uno, e
nel progetto finale ne occorrono due).

A scapito dei costi anche il datapath è realizzato dentro le FPGA, per
ottenere simulazioni più significative e un prototipo più compatto; è
tuttavia possibile realizzarlo con componenti TTL standard riducendo il
costo del bridge del 70\%.

Attualmente il prototipo è stato provato teoricamente, con una simulazione
post-layout dei soli chip che non tiene conto degli effetti del circuito
stampato (l'intero physical design è stato appena abbozzato). L'esperienza
mostra che il simulatore Altera è abbastanza preciso, quindi in caso di
costruzione di un prototipo fisico dovrebbero manifestarsi solo i consueti
piccoli difetti dovuti alle discrepanze tra valori teorici dichiarati e
comportamento reale dei componenti.

La descrizione vera e propria del circuito è stata effettuata in tecnica
mista. I blocchi funzionali sono stati realizzati con un linguaggio di
descrizione dell'hardware; il progetto si basa principalmente su una
macchina a stati, quindi è stato sufficiente il linguaggio AHDL (che nasce
dall'ambiente PAL). Per il complessivo (figura~\ref{fig:pci5})
\begin{figure}[ht]
\def\epsfsize#1#2{0.2#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 1024 768]{pci/fig5.ps}\end{center}
\caption{\label{fig:pci5}\small Circuito complessivo}
\end{figure}
e per creare gli stimoli
del simulatore è stato invece scelto il tradizionale metodo grafico.

Le figure~\ref{fig:pci6}, \ref{fig:pci7} e~\ref{fig:pci8}
\begin{figure}[ht]
\def\epsfsize#1#2{0.2#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 1024 768]{pci/fig6.ps}\end{center}
\caption{\label{fig:pci6}\small Risultati della simulazione}
\end{figure}
\begin{figure}[ht]
\def\epsfsize#1#2{0.2#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 1024 768]{pci/fig7.ps}\end{center}
\caption{\label{fig:pci7}\small Risultati della simulazione}
\end{figure}
mostrano una parte dei risultati della simulazione: si
tratta rispettivamente dei cicli di scrittura in memoria, di lettura in
memoria, e di lettura dallo spazio di configurazione. I segnali sono divisi
in tre gruppi: quello più in alto raccoglie i segnali relativi al local bus
68020, quello centrale quelli del bus PCI, e in fondo sono raffigurati
alcuni nodi interni di interesse. Durante il primo ciclo viene mostrata in
azione la logica di traslazione degli indirizzi della ROM; il terzo (lettura
da spazio di configurazione) è sostanzialmente identico a una normale
lettura, ma il comando di bus (\c{0xA}) è diverso.

In figura~\ref{fig:pci8}
\begin{figure}[ht]
\def\epsfsize#1#2{0.2#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 1024 768]{pci/fig8.ps}\end{center}
\caption{\label{fig:pci8}\small Risultati della simulazione}
\end{figure}
si può notare un piccolo errore di temporizzazione sul rilascio
della linea \c{/dsack} (è mantenuta bassa per un tempo troppo lungo); non è
stato corretto perché si manifesta solo in caso di pilotaggio del 68020
incompatibile con gli attuali \A. I glitch visibili sulle uscite non sono
pericolosi perché avvengono in istanti dove i segnali affetti non sono
significativi e sono troppo stretti per innescare problemi di rumore: si
limitano a incrementare la dissipazione di potenza del dispositivo.

Lo schema a blocchi definitivo del bridge è visibile in figura~\ref{fig:pci9}.
\begin{figure}[ht]
\def\epsfsize#1#2{0.1#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 2050 1753]{pci/fig9.ps}\end{center}
\caption{\label{fig:pci9}\small Schema a blocchi definitivo}
\end{figure}
Una
descrizione completa dello schema e dei sorgenti AHDL è improponibile in
questa sede; ma la complessità è limitata e gli ``addetti ai lavori'' non
dovrebbero incontrare difficoltà. Chi conosce i cicli di bus del 68020 (o
68030 in modo asincrono), può aiutarsi con la figura~\ref{fig:pci10}
\begin{figure}[ht]
\def\epsfsize#1#2{0.1#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 2262 1388]{pci/fig10.ps}\end{center}
\caption{\label{fig:pci10}\small Schema della transazione di lettura
elementare (la fase di arbitraggio non è mostrata)}
\end{figure}
che riportata un tipico ciclo di lettura PCI.

Il bridge supporta l'indirizzamento di tutti e tre gli spazi del PCI 2.0
(memoria, I/O e configurazione) mediante rimappatura con aliasing degli
indirizzi all'interno dello spazio di memoria unico della CPU 68020; i cicli
di bus generati dal sequencer sono: I/O read, I/O write, memory read, memory
write, configuration read, configuration write. Come scheda PCI target è
stata scelta una S-VGA accelerata basata sul chip {\az Cirrus Logic} GD5434 (64
bit interni e 32 esterni). Contiene un generatore di interrupt, registri
mappati in tutti e tre gli spazi, oltre che un'area di memoria RAM e una
ROM. Il processore scelto è un MC68020 a 14\,MHz. In questo modo di
funzionamento il throughput risulta ridotto, ma diventa possibile utilizzare
componenti più lenti e meno complessi come le FPGA a media densità.

L'host bridge realizzato è quindi del tipo per agenti slave implementati
come risorsa su motherboard. Questa classe di bridge è prevista
esplicitamente dalle specifiche PCI 2.0 e consente qualche semplificazione;
in particolare non occorre una completa caratterizzazione elettrica del
backplane, e la generazione della parità su dati e comandi è semplificata.
Vista la natura dedicata, non è stata prestata particolare attenzione ai
requisiti di interfaccia elettrica.

Per non imporre innaturali costrizioni nella stesura del codice applicativo
che accede al PCI, sono gestite le transazioni in lettura e scrittura per
qualsiasi dimensione dei dati, con l'eccezione degli accessi a word e long
word disallineate nello spazio di I/O PCI (normalmente di nessuna utilità
pratica).

Un corretto interfacciamento con il CL-GD5434 richiede la gestione di tutte
le condizioni di abort previste dal protocollo PCI, originate sia dal master
che dal target. Gli interrupt non sono fondamentali e quindi non vengono
supportati; potrebbero essere eventualmente gestiti mediante autovettore.
L'unico vincolo imposto sulla frequenza di clock PCI è che sia superiore a
quella del local bus di un \A 1200 standard.

Comunque le prestazioni non sono eccessivamente importanti, anche perché il
throughput del 5434 è limitato, quindi non sono supportate le transazioni
burst e manca una bufferizzazione dei dati al di là dei semplici latch
richiesti dallo standard. Essendo presente un solo master (il 68020) non
occorre implementare un arbitro né le funzioni di lock, mentre la natura di
framebuffer della memoria video sulla scheda PCI esclude la necessità di
supporto della cache e controllo della parità. In un'applicazione reale, la
Fast RAM di sistema sarà opportunamente posta sul local bus della CPU.

\paragrafo{Problemi realizzativi}
\noindent La realizzazione di uno host bridge per i processori a 32 bit della famiglia
680x0 è particolarmente interessante e impegnativa, perché si manifestano
tutti i problemi dell'interfacciamento tra bus diversi.

Questi processori mettono a disposizione sei spazi di indirizzamento a 32
bit individuati da tre bit di selezione emessi assieme agli indirizzi, ma
essi sono di natura profondamente diversa da quella dei tre spazi del PCI
2.0. Infatti non sono assegnati a funzioni diverse (per esempio: memoria e
I/O) con supporto a transazioni di bus di tipo diverso, come richiesto dal
PCI 2.0 (modellato soprattutto sui processori {\az Intel}).

Invece, per i processori 680x0 rappresentano più che altro una possibilità
di segmentazione dell'unico spazio di memoria esistente: le tre linee si
limitano a riflettere lo stato del processore nell'istante di sottomissione
della richiesta alla bus unit, specificando se l'accesso è un prelievo (o
scrittura) di codice oppure dati, o anche se si tratta di una comunicazione
con i coprocessori (MMU, FPU, interrupt acknowledge) e il livello di
privilegio in cui si trova il processore.

Quindi è inevitabile un aliasing degli indirizzi per poter accedere agli
spazi di I/O e configurazione PCI, da rimappare opportunamente nello spazio
indirizzi del 680x0. Ciò non costituisce una limitazione grave, perché la
dimensione degli spazi di configurazione e di I/O in tutti i dispositivi PCI
commerciali è minima: si perde accessibilità solo di una piccola fetta
dello spazio di memoria PCI. È un problema trascurabile rispetto alla
necessità dell'\A di avere una ben precisa mappa di memoria, che rende
irraggiungibili ampie fette dallo spazio di indirizzamento PCI.

La natura a 32 bit pieni del bus PCI rende più difficile il suo
collegamento ai chip con bus a 16 bit come 68000 e 68010, per i quali potrà
eventualmente essere realizzata in seguito una versione particolare del
bridge.

Un altro ostacolo è rappresentato dall'ordinamento dei byte in memoria e
dal dynamic bus sizing. Il PCI 2.0 segue lo stesso ordinamento dei byte dei
processori 80x86, mentre i processori 680x0 seguono la convenzione opposta e
il 68020 ha un byte router interno per gli accessi non a 32 bit. Ciò ai
fini del bridge non costituisce un problema serio sinché si effettuano solo
accessi a 32 bit allineati in modo naturale (alla longword): in pratica,
nell'attuale implementazione il problema dell'ordinamento è stato solo
parzialmente affrontato (come si può notare nel sorgente \f{service.tdf}) e
dovrà essere meglio precisato nella seconda fase.

Le specifiche elettriche dei driver nel caso di singolo agente su
motherboard sono sostanzialmente simili a quelle della logica CMOS, non
particolarmente restrittive, quindi ci si è accontentati della
dichiarazione di conformità alle specifiche PCI fatta da Altera.


\paragrafo{Struttura}
\noindent Il bridge è stato implementato in due FPGA Altera EPM7192GC160; lo schema a
blocchi è visibile in figura~\ref{fig:pci9}.

Per assicurare modularità e rapidità di modifica, il progetto è stato
suddiviso in tre sorgenti in linguaggio AHDL, realizzando con l'editor
grafico solo i collegamenti tra i blocchi. Il criterio seguito per
l'accorpamento delle funzioni è la riduzione dei segnali di collegamento
tra i blocchi del \hbox{bridge}: si è tentato di riunire nello stesso sorgente
solo funzioni interdipendenti, riducendo una parte della modularità e
generalità del progetto.

Per evitare un'eccessiva criticità degli istanti di applicazione degli
stimoli, le parti implementate in logica asincrona sono state sostituite per
quanto possibile con schemi completamente sincroni (più adatti alla
struttura delle EPLD scelte come target dell'implementazione). È stata
anche attivata l'opzione di clock globale disponibile sulle logiche EPLD
serie 5000, con visibile effetto benefico.

Il segnale PAR è retto da una rete completamente autonoma che richiede come
ingresso solo il segnale di abilitazione dei buffer di uscita. \c{/berr} e
\c{/halt}
del 68020 sono collegati assieme, poiché ogni ciclo abortito su PCI viene
sempre ritentato dal bridge (in mancanza di agenti che supportino il bus
locking); \c{/ds} non viene usato poiché la durata di ogni ciclo di bus è
legata solo alla velocità del lato PCI, dunque il 680x0 ha sempre i dati
pronti nel momento in cui sono richiesti.

La macchina a stati (figura~\ref{fig:pci11})
\begin{figure}[ht]
\def\epsfsize#1#2{0.1#1}
\begin{center}\tolerance=10000\leavevmode\epsffile[0 0 2097 970]{pci/fig11.ps}\end{center}
\caption{\label{fig:pci11}\small Struttura del sequencer che gestisce le
transazioni sui bus PCI e 68020}
\end{figure}
è il sequencer di bus che genera anche
tutti i segnali di controllo del datapath. È stata implementata come come
macchina di Mealy a numero di stati minimo (lasciata ottimizzare dal
compilatore, che ha fatto un buon lavoro), seguita da una rete combinatoria
per la generazione delle uscite e quindi da una barriera di latch per
risincronizzare alcune uscite della macchina a stati con il clock di sistema.

La presenza dei latch è inevitabile, a causa dei glitch visibili
sull'uscita della rete combinatoria (ma non tutti creano disturbo), mentre
l'uso di una macchina di Moore è impossibile perché introdurrebbe un
ritardo di un ciclo di clock sulla risposta agli stimoli, che sarebbe
incompatibile con il protocollo PCI 2.0.

La rete è priva di sincronizzatori sul lato dell'interfaccia col processore
Motorola: si rischiano problemi di violazione dei tempi di setup e hold dei
flip-flop che reggono i bit di stato, risolti agganciando opportunamente il
clock di questi flip-flop a quello del 680x0.

Non si può separare il sequencer del protocollo PCI da quello del 68020,
come suggerito anche dalle specifiche PCI, perché il protocollo asincrono
scelto per far funzionare il 68020 è già un metodo di sincronizzazione
elementare.

I risultati migliori in termini di prestazioni sono stati ottenuti
descrivendo il sequencer in modo da delegare al compilatore la maggiore
quantità possibile di scelte. Ciò ha richiesto una definizione degli stati
con costrutti ``if then'' e ``case'' scelti in modo da specificare lo stato
delle uscite solo in corrispondenza delle transazione di stato ed evitando
ogni definizione di tipo tabellare.

Solo alla fine è stata fatta la scelta delle FPGA da usare come target
definitivo, escludendo i modelli in package inadatto e provando
ripetutamente il fitter. I dispositivi scelti sono una coppia di
EPM7192GC160-15; usando questi componenti il timing analizer fornisce una
registered performance pari a 21\,ns, il massimo tempo di propagazione è di
15\,ns e i tempi di setup sui nodi sensibili hanno valori intorno ai 25\,ns,
con un massimo di 30\,ns. Poiché bisogna tener conto delle finestre
temporali entro cui possono commutare gli ingressi del circuito e garantire
dei margini, è stato scelto un periodo di clock di 70\,ns che corrispondono
ai circa 14\,MHz dell'\A 1200. Le simulazioni hanno confermato la validità
della scelta, che richiede che il 68020 venga alimentato con un segnale di
clock in anticipo di 25\,ns rispetto a quello del bridge (basta pilotare
\A con un oscillatore esterno e alimentare il piedino \c{clk} delle FPGA con
una linea di ritardo).

Dopo aver determinato una configurazione di progetto stabile è iniziato il
lavoro di modellazione accurata dei cicli di bus, cioè la generazione di
vettori di stimolo basati sui valori tipici e su quelli più sfavorevoli
elencati nei datasheet dei componenti. Purtroppo il simulatore Altera non
accetta in alcun modo nodi di ingresso con lo stesso nome di quelli di
uscita: sui bus bidirezionali non è possibile applicare uno stimolo quando
il buffer interno è in stato di alta impedenza (cioè quando il bus è
commutato in ingresso), e osservare lo stato imposto quando si ha pilotaggio
(bus commutato in uscita). Per aggirare la limitazione è stata trovata una
soluzione parzialmente soddisfacente, che consiste nell'esaminare solo
qualche linea del bus prelevata come buried node.

Un altro problema mostrato dalle simulazioni è la presenza di uno
sfasamento fisso pari a 5\,ns (a causa del buffer interno) tra il clock
applicato al bridge e il Global Clock che alimenta tutta la logica, ma le
simulazioni hanno anche mostrato che ciò non causa problemi funzionali.
L'uscita di clkout, sfasata di 14\,ns e prevista in origine per alimentare il
bus PCI, non è servita ed è lasciata inutilizzata.


\paragrafo{Possibili miglioramenti}
\noindent È stata anche esplorata la possibilità di introdurre il supporto alle
transazioni disallineate con dimensione della parola arbitraria, che implica
la realizzazione di un byte swapper per dare al bridge la funzione di
dynamic bus sizing richiesta dal 68020. Il progetto modulare consentirebbe
una facile inserzione della nuova rete, che infatti è stata interamente
sviluppata. Purtroppo la lentezza della macchina a stati e il fit molto
stretto sui dispositivi hanno sconsigliato la sua incorporazione nel
progetto. Con l'aumento considerevole delle uscite, e quindi della rete
combinatoria a valle della macchina di Mealy, si rischierebbe da un lato di
dover abbassare la frequenza di clock, e dall'altro di dover includere un
terzo chip a causa dei registri introdotti nel datapath. In entrambi i casi,
per aggiungere una funzione accessoria si comprometterebbe la funzionalità
principale.

Sarebbe possibile anche alimentare il bus PCI con un clock diverso da quello
del bridge e del 68020, cosa che il progetto consente senza alcuna
difficoltà, ma che sarebbe vantaggioso solo in un backplane con altri
agenti master. Più interessante è la possibilità di sostituire MC68020
con un MC68030 (che non richiede alcuna modifica al circuito), alimentandolo
con una frequenza di clock più elevata di quella usata per il bridge:
facendo funzionare il bus della CPU in modo asincrono non occorrono
modifiche funzionali al progetto. Sarebbe necessaria solo una verifica dei
sincronizzatori di ingresso per assicurarsi che non vengano violati i tempi
di hold e setup.

Per maggiore completezza si potrebbero implementare tabelle di traslazione
degli indirizzi programmabili tramite registri nello spazio di
configurazione e il supporto per la cache, ma ciò causarebbe un'esplosione
di complessità che non si concilia con le caratteristiche delle FPGA
disponibili. Invece non è impossibile (anche se poco utile) implementare il
ciclo di interrupt acknowledge.

L'esame dei dati ha dimostrato che la limitazione sulla frequenza di clock
è dovuta alle FPGA target, capaci di supportare con discreta agilità
datapath estesi ma dalle prestazioni sequenziali modeste. Una semplice
ricompilazione su FPGA serie 9000 (non supportate dalla versione del
software utilizzata) consentirebbe probabilmente di raggiungere la frequenza
di lavoro massima del bus PCI.

%\smallskip\noindent Copyright\copyright 1995
%Paolo Canali, tutti i diritti riservati. È consentita la
%pubblicazione e duplicazione del presente articolo solo unitamente agli atti
%del convegno IPISA~'95.


\begin{thebibliography}{10}
\bibitem{PCI} PCI Special Interest Group.
\emph{PCI local bus specification, revision 2.0}.
\emph{PCI system design guide, revision 1.0}.
\emph{PCI BIOS specification, revision 2.0}.
M/S JF2-51, 5200 NE Elam Young Parkway, Hillsboro, OR 97124-6497.

\bibitem{DH} Dave Haynie, Scott Schaeffer, Scott Hood, Dan Baker.
\emph{\A 4000/3000 hardware developer notes}. Revision 1.1, dicembre 1992.
\emph{Atlanta DevCon notes}.

\bibitem{CIR}Cirrus Logic, inc.
	\emph{mAlpine family technical reference manual}.
	Novembre 1993.

\bibitem{MOT} Motorola. \emph{MC68020 user's manual}. Quarta edizione,
	ISBN 0-13-541657-4 Prentice Hall, Englewood Cliffs, N.J. 07632.
	\emph{MC68040 32-bit microprocessor user's manual}.
\emph{MC68040UM/AD}.
	\emph{MC68060 Product Brief}.
	\emph{MC68030 Enhanced 32-bit microprocessor user's manual}. Seconda
edizione, ISBN 0-13-566951-0 Prentice Hall, Englewood Cliffs, N.J. 07632.

\bibitem{PMC} Lo standard PMC è sviluppato da tre organismi:
	IEEE (P1386.1),
	Multibus Manifacturers Group: Aloha, OR, (503) 696-7155, e
	VMEbus International Trade Association (VITA), Scottsdale, AZ (602)
        951-8866.

\bibitem{CAN} Paolo Canali. Nuove architetture per la multimedialità.
	\emph{Amiga Magazine}.

\bibitem{CAN2} Paolo Canali.
	Studio dei backplane di espansione per sistemi a microprocessore, con sviluppo
	di un host bridge PCI 2.0 per local bus 68020.
	Tesi di laurea in ingegneria elettronica presso
	l'Università degli studi di Pisa, A.A.~1994--1995.

\bibitem{JOEL} Joseph Liu (\c{joel@xilinx.com}). Detailed model shows FPGA's true costs.
\emph{EDN}, 11 maggio 1995, pagg.~153--158.

\bibitem{CUY} Kenneth M. Cuy. Design considerations bring unity to a mixed-voltage world.
\emph{EDN}, 2 febbraio 1995, pagg.~115--118.

\bibitem{QUIN} Richard A. Quinnel. Mezzanine buses bring backplane benefits to the board level.
	\emph{EDN}, 2 marzo 1995.

\bibitem{API} Steve Apiki. SCSI rides high on PCI. \emph{Byte}, Vol.~19, No.~12, pag.~163.
\end{thebibliography}

\autore{%
Paolo Canali}{}

\citazione{\selectlanguage{english}The nice thing about standards is that there are so many of them
to choose from.}{Andrew S. Tanenbaum}