Programmable Interrupt Controller

Facoltà di ingegneria

Corso di studi in ingegneria informatica

Esame di calcolatori elettronici II

Tesina di fine corso

Implementazione VHDL di un Programmable Interrupt Controller (PIC) mod. Intel 8259A

Anno Accademico 2007-2008

Docente: Ch.mo prof. Antonino Mazzeo

Studente: Anzivino Antonio – 534/1922

PIC 8259A/simple

L’obiettivo di questo progetto è implementare in linguaggio VHDL un controller interrupt programmabile (PIC) secondo le specifiche del modello Intel 8259A, uno dei più diffusi chip per la realizzazione di funzionalità di interruzione. Lo scopo di un controller interrupt programmabile è la gestione, per conto della CPU, delle richieste di interruzione provenienti dai dispositivi periferici connessi al calcolatore. L’Intel 8259A è stato a lungo adottato nelle architetture basate su x86 (Intel e AMD), ma, con l’evolvere dei calcolatori, il dispositivo PIC è stato sostituito da un più avanzato APIC (Advanced PIC), che non sarà oggetto di trattazione.

Caratteristiche del controller PIC

La caratteristica di rilievo di un controller PIC è proprio la programmabilità: come si può vedere sul datasheet, l’Intel 8259A possiede diverse modalità di funzionamento, ed è possibile programmare da CPU il modo in cui le interruzioni dovranno essere gestite. Il PIC, infatti, è in grado di mascherare le interruzioni che non dovranno essere servite in un dato momento, in quanto il processore sta eseguendo compiti più importanti. La programmazione del PIC è un’operazione che viene eseguita all’accensione del calcolatore, mediante BIOS, ma le impostazioni possono essere sovrascritte dal sistema operativo in fase di caricamento, in quanto il kernel gira in modalità Supervisore con libero accesso all’hardware.

Nei calcolatori moderni, il controller PIC è integrato sulla scheda madre, all’interno del Southbridge, che include tutti i dispositivi di interfacciamento con i bus di I/O, come PCI, PCI-Express, IDE, porte seriali e parallele. Il Southbridge gestisce le operazioni più lente del calcolatore.

Assieme alla piedinatura, il datasheet fornisce dettagliate indicazioni sui registri che possono essere programmati nel PIC, e una completa descrizione del protocollo di interruzione. Tuttavia, per motivi di praticità e di tempo, non siamo stati in grado di implementare tutte le funzionalità, e pertanto ci limiteremo ad implementare un PIC a priorità che implementa unicamente il protocollo di segnalazione a livelli di priorità.

Interruzioni e operazioni di I/O

Iniziamo con una panoramica sul problema delle interruzioni. Le operazioni di I/O sono l’elemento chiave di un calcolatore, in quanto esso non è un sistema autistico ma deve comunicare con l’esterno: tanto con un operatore umano quanto con un altro calcolatore.

• Visualizzazione a schermo di testo su una console di comando
• Visualizzazione a schermo di una interfaccia grafica bidimensionale (GUI)
• Rendering tridimensionale (applicazioni CAD e videogiochi)
• Lettura e scrittura di dati su memoria di massa
• Trasmissione di dati ad un altro calcolatore attraverso una rete di calcolatori, come Internet
• Scansione di un documento di testo
• Stampa di fotografie
• Riproduzione e registrazione di segnali audiovisivi
• Interazione utente con tastiera e mouse/trackball o touchscreen (lettura dei comandi impartiti dall’utente sull’interfaccia attraverso i suddetti dispositivi)

Tali operazioni, così come tutte le altre che non riteniamo di elencare, vengono eseguite da dispositivi che, anche se interni al calcolatore, sono esterni alla CPU che esegue il software applicativo. In un tipico scenario, supponendo che l’utente voglia spedire un messaggio di posta elettronica, i dispositivi di I/O coinvolti sono tanti e ognuno ha una specifica funzione. Descriviamo quindi lo scenario come segue:

• L’utente utilizza il mouse per posizionare il puntatore sul comando “Crea messaggio” (input)
• Mentre l’utente esegue l’azione al punto 1, il puntatore sullo schermo segue i movimenti dell’utente (output)
• L’utente fa click sul comando (input)
• A schermo viene visualizzata una finestra di composizione messaggio (output)
• L’utente richiede che venga aperta la rubrica per selezionare il destinatario (input)
• Il sistema legge la rubrica da disco (input)
• Il sistema visualizza i contatti a schermo sotto forma di una lista (output)
• L’utente seleziona il destinatario (input)
• L’utente scrive il testo del messaggio sulla tastiera (input)
• A schermo vengono visualizzati i caratteri digitati dall’utente, che così può correggere eventuali errori (output)
• L’utente fa click sul comando “Invia messaggio” (input)
• Il sistema trasmette un pacchetto di sincronizzazione TCP verso il server di posta in uscita (output)
• Il sistema attende un acknowledgement TCP dal server (input)
• Il messaggio viene trasmesso secondo il protocollo SMTP (output, ma vi sono anche input in realtà)
• A schermo viene visualizzata una conferma dell’avvenuto invio

In questo semplice scenario, i dispositivi coinvolti nell’interazione sono tastiera, mouse, schermo, disco rigido e scheda di rete. Ognuno ha il proprio compito, e il processore, guidato dal sistema operativo e dal software applicativo, deve far sì che il loro utilizzo corretto porti allo scopo preposto, nel caso l’invio di un messaggio email.

Il problema è che le operazioni di I/O sono estremamente lente rispetto alla velocità di esecuzione delle istruzioni di una CPU. Un dattilografo difficilmente supera la velocità di 5 tasti premuti al secondo, mentre una CPU in grado di completare un’istruzione al secondo (ciò si può ottenere col pipelining, ad esempio), alla frequenza di soli 100MHz è in grado di completare 100 milioni di istruzioni al secondo.

Gestione delle interruzioni

È ovvio che, nel caso di un calcolatore che stia eseguendo molti compiti, come la navigazione sul web, la compilazione di un programma e la masterizzazione di un DVD, è improponibile che il processore si metta in attesa attiva dell’input utente da tastiera, ossia non esegua alcun compito fin quando l’utente non avrà premuto un tasto.

La prima soluzione, apparentemente, a questo problema, sarebbe quella per la CPU di interrogare (polling) uno a uno i dispositivi di input per stabilire quale desideri essere servito: nel nostro caso, non sappiamo se in un dato momento è la tastiera a richiedere che venga letto un carattere o il mouse che venga rilevato il suo movimento. La soluzione sincrona, però, non si presta all’applicazione reale, in quanto la CPU spreca inutilmente cicli nella fase di polling.

La soluzione al problema è asincrona: si fa in modo che siano le periferiche stesse a interrompere la CPU quando è richiesta attenzione. Per la verità, una periferica non può letteralmente interrompere la CPU, ma ciò è solo l’effetto macroscopico che si vede eseguendo i programmi a velocità CPU. Per implementare le interruzioni, è innanzi tutto necessario un passo teorico: una piccola modifica al ciclo di Von Neumann, che diviene il seguente:

1. Fetch
2. Operand Assembly
3. Execute
4. IF NOT Interrupt THEN Serve Interrupt
5. GoTo 1

La CPU, dunque, al termine di ogni istruzione, verifica se vi è una richiesta di interruzione da parte di una periferica, e in tal caso si prepara a servire tale interruzione.

Fatto ciò, si è subito visto che vi sono servizi da considerarsi time critical, ossia che è importante che vengano serviti prima di altri tipi di servizi di minore importanza. Ad esempio, in un impianto industriale, l’interruzione proveniente da un controller termostatico che segnala l’eccessiva temperatura di un altoforno dovrebbe far immediatamente scattare una routine di emergenza che spenga l’impianto. Ciò dovrebbe avere massima priorità, senz’altro più alta di quella di un dispositivo che segnala l’avvenuta produzione di un pezzo.

Priorità degli interrupt

Dunque, nei processori moderni, gli interrupt sono organizzati a priorità. La priorità di un dispositivo è detta IRQ. Per convenzione, sui dispositivi 8259, ha priorità maggiore il dispositivo con IRQ0.

La convenzione va oltre la specifica delle priorità: la maggior parte dei dispositivi assume un IRQ specifico. Wikipedia ci riporta una tabella nella quale possiamo osservare quali siano, nell’architettura x86, gli IRQ tipicamente assegnati a determinate periferiche:

• IRQ 0 - System timer. Reserved for the system. Cannot be changed by a user.
• IRQ 1 - Keyboard. Reserved for the system. Cannot be altered even if no keyboard is present or needed.
• IRQ 2 - Cascaded signals from IRQs 8-15. A device configured to use IRQ 2 will actually be using IRQ 9
• IRQ 3 - COM2 (Default) and COM4 (User) serial ports
• IRQ 4 - COM1 (Default) and COM3 (User) serial ports
• IRQ 5 - LPT2 Parallel Port 2 or sound card
• IRQ 6 - Floppy disk controller
• IRQ 7 - LPT1 Parallel Port 1 or sound card (8-bit Sound Blaster and compatibles)
• IRQ 8 - Real time clock
• IRQ 9 - Free / Open interrupt / Available / SCSI. Any devices configured to use IRQ 2 will actually be using IRQ 9.
• IRQ 10 - Free / Open interrupt / Available / SCSI
• IRQ 11 - Free / Open interrupt / Available / SCSI
• IRQ 12 - PS/2 connector Mouse. If no PS/2 connector mouse is used, this can be used for other peripherals
• IRQ 13 - ISA / Math Co-Processor
• IRQ 14 - Primary IDE. If no Primary IDE this can be changed
• IRQ 15 - Secondary IDE

Come possiamo notare, il timer di sistema ha priorità massima, il controller IDE primario ha priorità sul secondario ma non sul coprocessore matematico né sulle porte seriali COM. Possiamo verificare ciò empiricamente: nel nostro caso abbiamo constatato, attraverso i tool forniti dal sistema operativo, l’assegnazione degli IRQ su un processore AMD64 per quanto riguarda il timer di sistema.

Ciò significa che, nel caso in cui sia la porta parallela LPT1 che la tastiera sollevino un interrupt, verrà servita prima la tastiera e poi la porta parallela. In un tipico protocollo di I/O asincrono, CPU e periferica comunicano tra di loro per concordare l’operazione e in seguito scambiare i dati. Ricordiamo che l’accesso all’I/O è riservato al sistema operativo, quindi un software (come il client di posta che vuole caricare la rubrica) dovrà chiedere al kernel di eseguire l’azione per suo tramite.

Sebbene la gestione del file system sia incredibilmente complicata, per ragioni di robustezza e sicurezza, possiamo semplificare tutto ciò riducendo il caricamento della rubrica da disco ad una serie di passi più semplici:

1. Il client prepara i registri del processore in una configurazione conforme alle specifiche del sistema operativo. Ad esempio, il registro A0 viene caricato col puntatore alla stringa che contiene nome e percorso del file da caricare, D0 viene caricato con i flag di sola lettura e A1 con il puntatore al buffer dove dovrà essere caricato il contenuto del file.
2. Il client effettua dunque una system call, facendo in modo che il processore entri in stato Supervisore ed esegua le routine di file system del kernel. Da adesso in poi, il controllo è del sistema operativo.