Svolgendo il progetto assegnato dal professor Chiari il 27-06-2005 mi è sorto un dubbio. Ognuno dei quattro banchi di cui è composta la memoria RAM del PD32 è attestata su un certo byte del memory data bus. Se si effettua un trasferimento di un byte da un registro ad una locazione in memoria i cui bit meno significativi dell'indirizzo non sono 00, ad esempio 10, verrà attivato soltanto il segnale Mb2 ma a questo punto non è necessario uno shift dei dati per portare il byte del registro sulle linee MDB(16-23)?

Certamente, altrimenti il byte finisce nella locazione sbagliata.

E se questo è vero tale shift viene effettuato sul memory data register?

Si'. Se l'operazione e' conseguenza di una istruzione eseguita dalla CPU, sono i circuiti interni alla CPU stessa che provvedono alla bisogna. Se invece l'accesso alla memoria viene eseguito da un'unita' esterna alla CPU (una periferica con memoria condivisa, oppure un DMA Controller) allora occorrera' prevedere degli appositi circuiti che "emulino" il comportamento della CPU, in particolare che gestiscano i segnali MBx e il corretto posizionamento dei dati sui 4 byte del Memory Data Bus.

Inoltre, non c'e' alcuna necessita' di condizionare la permanenza in "11" a START=0: la permanenza puo' benissimo essere incondizionata.

Nel tentare di risolvere l'esercizio ho supposto che il dispositivo legga sempre il contenuto di otto porte, richiedendo alla cpu di porre a zero quelle che non contengono coefficienti del polinomio.

E' un'ipotesi ragionevole.

In alternativa il dispositivo avrebbe potuto avere un contatore ad incremento con il count enable dipendente in qualche modo dal segnale di gate delle porte di uscita della cpu cosi' da conoscere il numero di coefficienti del polinomio da calcolare?

Si', ad esempio richiedendo alla CPU di scrivere i coefficienti a partire dal meno significativo: in questo modo, contandoli, possiamo dedurre quali rimangono a zero e di conseguenza semplificare i calcoli.

Si utilizzano registri di tipo D edge triggered con load asincrono?

Se sono davvero indispensabili, si'; altrimenti se possibile conviene usare una qualche alternativa.

E' corretta l'idea di soluzione esposta nel file allegato?

Perche' usare 2 registri in uscita al moltiplicatore/addizionatore e 14 stati, quando potrebbe risolvere ugualmente con un solo registro e 7 stati:

y = a0 + a1 x + a2 x^2 + a3 x^3 + a4 x^4 + a5 x^5 + a6 x^6 + a7 x^7 =
= a0 + x (a1 + x (a2 + x (a3 + x (a4 + x (a5 + x (a6 + x a7))))))

Il calcolo procede di conseguenza in questo modo:

(1) a6 + x a7 -> Temp
(2) a5 + x Temp -> Temp
(3) a4 + x Temp -> Temp
(4) a3 + x Temp -> Temp
(5) a2 + x Temp -> Temp
(6) a1 + x Temp -> Temp
(7) a4 + x Temp -> Temp

In questo progetto la CPU non invia alcun dato all'interfaccia, deve dare soltanto uno Start. Di conseguenza, il registro in alto a sinistra, anche questo incorrettamente indicato come PISO, non ha alcuna funzione. I dati EXTDATA, inoltre, non provengono dalla CPU ma dal mondo esterno, e non sono in alcun modo sincronizzati con essa, ma con un clock EXTCLK anch'esso proveniente dal mondo esterno.

La porta di input in alto a destra: a che serve, se poi il risultato viene (correttamente) prelevato in basso a sinistra dal registro cjhe mantiene il massimo valore trovato?

9 luglio 2002 (IFRANGE)
=======================

I dati provengono dall'esterno, non dall'I/O Data Bus, dunque non puo' sincronizzarli con I/O Write poiche' la CPU non ha modo di sapere quand'e' che arrivano.

Inoltre, perche' indica con "PISO" un semplice registro D (latch o edge-triggered che sia)? PISO significa "Parallel-Input Serial-Output", dunque e' un qualcosa con piu' linee di ingresso e una sola linea di uscita, e non e' questo il suo caso!

23 luglio 2002 (SERIN)
======================

A che serve la porta di output che ha disegnato per prima, per di piu' connessa all'I/O Address Bus anziche' all'I/O Data Bus? In questo progetto la CPU non invia alcuna informazione all'interfaccia, ne' da' alcuno Start: l'interfaccia lavora in continuazione, e l'unico trasferimento di dati avviene dall'interfaccia *verso* la CPU.

Tra il SIPO e il bus (la porta di destra) conviene inserire un "registro tampone", altrimenti la CPU ha a disposizione un solo periodo di XCLK per reagire all'interrupt: se non lo fa, al clock successivo il SIPO potrebbe venire modificato e il dato da passare alla CPU verrebbe perso. La sequenza e' la seguente: al 12-esimo clock il contenuto del SIPO viene copiato nel registro tampone e viene generato l'interrupt; la CPU legge il dato dal registro tampone (e non dal SIPO) avendo in questo modo almeno 12 periodi di XCLK di tempo per reagire all'interrupt.

9 settembre 2002 (SEROUT)
=========================

Qui c'e' gran confusione. Il primo registro che fa da porta, e' incorrettamente indicato come PISO (ha infatti 12 uscite). Il secondo registro, in alto a destra, anche questo incorrettamente indicato come PISO, non ha nessuna funzione: questa interfaccia non invia alcun dato alla CPU! Il vero PISO invece e' il registro in basso a sinistra, la cui uscita seriale tuttavia non deve andare alla CPU ma al mondo esterno.

13 dicembre 2002 (IFPTY)
========================

Anche qui il solito PISO (in alto a sinistra) che non serve a nulla: i dati provengono dall'esterno, non dalla CPU.

La parità si calcola con un albero di XOR, non con Half Adder ne' con ROM -- quindi non va bene ne' la prima ne' la seconda soluzione. Inoltre, i dati arrivano in parallelo, non in serie, dunque la parita' va calcolata in un singolo periodo di clock e di conseguenza il contatore mod 16 non deve esistere.

21 luglio 2003 (IFKEY)
======================

Questo va abbastanza bene. Due soli appunti:

(1) il clock non e' un generico XCLK (mai citato nel testo del progetto) ma puo' benissimo essere il System Clock

(2) Il SEL delle due porte di input *deve* essere lo stesso (è compito dell'uscita di comparatore A=B decidere quale delle due deve essere abilitata), la CPU legge il risultato da un unico device_address, ne' puo' sapere quale e' la effettiva sorgente del dato che sta leggendo.

Manca la comparazione con la stringa S'.

17 dicembre 2004 (IFSPK)
========================

(pag 2) La ROM contiene gia' i campioni del segnale che occorre emettere in uscita, non c'e' bisogno di alcunn decoder: le uscite della ROM vanno direttamente all'uscita (che, come dice il testo, e' *un* canale ad 8 bit).

6 luglio 2005 (IFABS)
=====================

(pag 3 in alto) A cosa servono i tri-state abilitati da INIZIO? Se ci pensa un attimo, non hanno alcuna funzione. A cosa serve un XOR con un ingresso fisso a 0? A nulla, lascia comunque passare l'altro ingresso inalterato e dunque e' equivalente a un pezzo di conduttore. Puo' anche risparmiare i tri-state verso il bus interno semplicemente connettendo il bit di segno, qualunque esso sia, agli ingressi degli XOR in pag. 2 e al carry-in del sommatore.

(pag 3 in basso) L'interrupt non deve essere generato dall'OR di E0, E1 ma dalla decodifica dello stato #1023

E' corretta l'idea espressa nel disegno?

Si'. Soltanto, nell'addizionatore in alto a destra (quello che fa da sottrattore), deve entrare non con -Y ma con Y negato, e applicare 1 al carry-in.

In alternativa, le due ROM possono essere identiche, e l'addizionatore in basso puo' essere configurato come sottrattore. (Sembrerebbe antieconomico, ma in molte realta' c'e' anche il problema del "magazzino" da affrontare: si preferisce talvolta avere una quantita' doppia dello *stesso* dispositivo, anziche' due quantita' singole di due dispositivi diversi.)

Mai, dico ***mai*** usare la seconda soluzione (clock pilotato da un circuito combinatorio): pensi soltanto alla possibilita' di alee o di altre incertezze transitorie all'uscita del circuito: bastano uno o due impulsetti spuri per far avanzare senza controllo il suo contatore.

Dalla teoria una scrittura in RAM ha bisogno di 3 fasi:

1. l'indirizzo e il dato sono stabili e il WE è inattivo (tempo di setup)
2. l'indirizzo e il dato sono stabili e il WE è attivo (tempo di strobe)
3. l'indirizzo e il dato sono stabili e il WE è inattivo (tempo di hold)

Il PD-32 e', come dice lo stesso nome, un PROCESSORE DIDATTICO, ed esiste come entita' solo per introdurre in maniera "soft" tutta una serie di concetti architetturali; dunque non prenda MAI il PD-32 come riferimento assoluto, la realta' e' ben altra! La struttura del PD-32 e' piu' o meno simile a quello che poteva essere un semplicissimo microcontrollore di una quindicina di anni fa. Nello specifico, cio' che il ciclo di Memory Write del PD-32 vuole indicare (che vuole, diciamo cosi', "trasmettere") e' che, appunto, esistono le tre fasi che lei ha elencato, e, per semplicita', viene assegnato lo stesso tempo (un singolo periodo di clock, che e' l'unita' di tempo) a ciascuna di esse. La cosa non e' del tutto ingiustificata, se pensa che in effetti i segnali di Address, di Data e di Control si devono propagare dal modulo CPU al modulo di memoria attraverso un bus, quindi attraverso una distanza fisicamente spesso notevole, e di conseguenza, per eliminare o limitare tutta una seri di problemi legati alla propagazione dei segnali, ai disturbi che si possono avere lungo il percorso, e cosi' via, si lasciano *ampi* margini di tempo ai vari eventi. Inoltre, la memoria principale del sistema non e' detto che sia di tipo statico, potrebbe anche essere di tipo dinamico, e questo, come certo sapra', comporta tutta una serie di altre problematiche -- d'altra parte, il ciclo generato dalla CPU deve potersi adattare indifferentemente sia a memorie statiche che a memorie dinamiche.

Nella realta', le cose vanno diversamente. Intanto, all'interno di una singola CPU, i problemi di distanza non esistono (o comunque sono di un piu' basso ordine di importanza); in secondo luogo, le memorie interessate sono *sicuramente* di tipo statico, dunque il ciclo di scrittura puo' essere *adattato* ad esse; in terzo luogo, le memorie statiche di oggigiorno sono ancora piu' efficienti di quanto non si potrebbe sospettare. Le accludo il datasheet di una RAM da 16-Mbit della NEC (quindi gia' di notevole capacita' e dimensioni, e' chiaro che RAM di dimensioni minori possono essere rese ancora piu' veloci). Se va a pag. 7 del file (Write Cycle) e analizza sia la temporizzazione in basso che la tabella in alto, vedra' che:

(1) il tempo minimo di setup tra indirizzo e Write Enable (tAS nella tabella) e' specificato a zero: cio' significa che quello che nel PD-32 era il periodo T1, qui puo' essere ridotto praticamente a zero;

(2) non e' necessario che i dati siano validi e stabili per *tutta* la durata di WE: basta che essi siano validi e stabili da un certo tempo (tDW >= 7 nsec) prima del *fronte finale* di WE, e che vi rimangano per un certo tempo dopo (tempo di hold, tDH) che, come vede, e' specificato a zero!

(3) solo l'indirizzo deve permanere valido e stabile ancora per un certo tempo dopo la fine del WE, tale tempo (tWR) e' specificato a 1 nsec.

Quindi, come vede, non ci sono grossi vincoli sulla temporizzazione dei dati, il loro tempo di hold puo' anche essere portato a zero, basta solo garantire una brevissima permanenza dell'indirizzo (cosa che nel progetto IFHIST era in realta' fatta giocando piu' o meno tacitamente con i ritardi di porte e multiplexer).

Inoltre mi ero stupito di come in calcolatori con un tempo di clock inferiore anche di molto ad 1 ns(oggi le cpu lavorano a più di 3 Ghz), la RAM, pur essendo una SRAM on board e quindi più veloci avesse dei tempi di risposta in scrittura così brevi. In pratica esse debbono registrare un dato in meno di un terzo di nano secondo, ma non sono fatte con le tecnologie che abbiamo studiato?? oppure i CMOS possono avere tempi così rapidi??

Non si lasci ingannare dalle frequenze di clock multi-gigahertz che vengono dichiarate: quelle intervengono solo nel "core" della CPU e in ppratica regolano solo i trasferimenti da registro a registro o attraverso multiplexer o semplicissimi circuiti combinatori, ma non appena entra in gioco un'unita' funzionale un tantino piu' complessa, servono piu' periodi di quel clock per far procedere correttamente le cose. Una cosa e' il clock di CPU, che puo' arrivare ad alcuni GHz, un altro e' il clock di bus, che come sapra', raramente supera i 300-400 MHz.

0801191436.pdf

Conviene sempre partire, in linea di massima, da una macchina di Moore, e poi, se si ha tempo e voglia, provare a vedere se trasformandola in macchina di Mealy si ha una significativa riduzione nel numero di stati. Normalmente, si scopre che il gioco non vale la candela; tuttavia ci sono alcuni casi (veda ad esempio il progetto del Massimo Comun Divisore assegnato all'esame di dicembre 2007) in cui la macchina di Mealy e' senz'altro da preferire a quella di Moore.