(2) Perche' avete bisogno di due registri temporanei all'uscita di FPMA? Non ne basta uno solo?

(3) A che serve la quaterna di registri all'uscita dalla ROM? Se l'indirizzo della ROM e' stabile, anche le sue uscite saranno stabili.

(4) Visto che ad ogni istante viene utilizzato un solo dato a 64 bit dalla ROM, che necessita' ha quest'ultima di avere parole da 4x64 bit?

(5) Quasi tutto lo SCO puo' essere realizzato con un contatore mod 4 che scandisce contemporaneamente le colonne della matrice e le componenti del vettore di ingresso, seguito da un contatore ancora mod 4 che scandisce le righe della matrice e le componenti del vettore di uscita. Sarebbe opportuno che lo SCO venisse posto esplicitamente sotto questa forma.

(2) Il flip-flop SR con R=0 non verra' mai resettato!

(3) Come fa un multiplexer a 3 ingressi di controllo ad accettare 9 ingressi dati (QREG0, ..., QREG7 piu' la costante "00...0") ?

(4) Il registro temporaneo all'uscita del moltiplicatore/accumulatore deve essere aggiornato ad ogni clock, ma il suo ingresso LE e' connesso al Terminal Count!

(5) La temporizzazione, con i valori di conteggio illustrati, non corrisponde assolutamente all'algoritmo delineato all'inizio del progetto, secondo il quale le operazioni potrebbero essere risolte in 8 o 9 periodi di clock (un clock per coefficiente).

I dubbi non finiscono mai!!! ;-)

Diceva un proverbio: "Doubt is the beginning not the end of wisdom"...

Sulla soluzione, dalle temporizzazioni e dalla ASM si evince che per ogni ciclo di lettura / scrittura in memoria servano 3 cicli di clock...Credo di aver sentito però che lei abbia detto che, se non è specificato nel testo, possiamo assumere di riuscire a leggere il dato dalla memoria in un solo periodo di clock oppure mi sbaglio?

Il punto non e' ovviamente il numero di clock, ma il tempo di accesso alla memoria. Se la memoria ha un tempo di accesso Tacc, e il clock ha periodo Tclk > Tacc, allora (forse) riusciamo a scrivere in un singolo periodo di clock; se invece 2Tclk < Tacc < 3Tclk, ci serviranno 3 cicli di clock.

E' vero, se il testo nulla specifica in merito, possiamo in linea di massima assumere Tacc < Tclk. Tuttavia, il tema che lei mi cita si riferisce all'accesso alla memoria del PD-32, e di conseguenza al System Clock come clock di riferimento; come sappiamo, il tempo di accesso alla System Memory e' tale che il ciclo di accesso alla memoria richiede (almeno) 3 periodi di System Clock.

Intanto si parte con un accumulatore ESPRESSO IN DECIMALE (leggasi anche: BCD) inizializzato con zero. Quanto alla lunghezza di questo accumulatore, si hanno due casi:

(a) non sappiamo in anticipo quanti bit da convertire ci arriveranno, e allora dovremo essere pronti con un accumulatore con numero arbitrario di cifre;

(b) sappiamo in anticipo quanti bit da convertire ci arriveranno (era questo il caso del compito) e allora possiamo stimare fin da subito di quante cifre dovra' essere costituito il nostro accumulatore (nel nostro caso erano 10, poiche' il massimo numero binario assoluto rappresentabile con 32 bit e' 4294967295, come qualunque calcolatrice degna di tale nome e' in grado di dirci)

Dunque partiamo con 10 cifre DECIMALI tutte uguali a zero. Ad ogni bit che arriva (posto che i bit arrivino a partire dal piu' significativo, come era il caso del compito) l'algoritmo (che lei e tutti gli altri avete usato decine o forse centinaia di volte quando avete fatto calcoli analoghi con carta e matita) e' semplicemente il seguente:

- MOLTIPLICARE (IN ***DECIMALE***) L'ACCUMULATORE PER DUE E SOMMARE IL BIT CHE STA ENTRANDO.

(E' essenziale che la moltiplicazione per 2, base del numero da convertire, venga eseguita in base 10, base del numero convertito, altrimenti e' facile dimostrare che la cosa non puo' funzionare. Molti compiti, in cui l'algoritmo era stato ben intuito, sono stati sbagliati proprio perche' tale moltiplicazione e' stata fatta in base 2 anziche' 10.)

Cosa significa moltiplicare in decimale un numero per 2? Questo dovremmo saperlo fin dalle scuole elementari:

(1) Si parte dalla cifra di destra come "cifra corrente", e si pone a 0 il "riporto";

(2) Si moltiplica la "cifra corrente" per 2 e si somma il "riporto" al risultato;

(3) Se il risultato e' minore di 10, si pone riporto = 0, si passa alla cifra immediatamente piu' a sinistra come "cifra corrente" e si torna al passo (2);

(4) Se invece il risultato e' maggiore o uguale a 10, si sottrae 10 da esso, si pone riporto = 1, si passa alla cifra immediatamente piu' a sinistra come "cifra corrente" e si torna al passo (2).

Non ho messo la condizione di terminazione, ma mi pare sia facilmente intuibile. Inoltre, la somma di 0 o di 1 al risultato della moltiplicazione per 2 significa semplicemente modificare il passo (1) dell'algoritmo appena delineato con

(1') Si parte dalla cifra di destra come "cifra corrente" e si pone a 0 o a 1 (a seconda del valore del bit che sta entrando) il "riporto".

Ora, il fatto che l'algoritmo sia un loop, significa che tutte le cifre del nostro accumulatore si comportano allo stesso modo, dunque, volendo tradurre l'algoritmo in hardware, ci basta chiarire solamente il comportamento di una singola "cifra". Che e' semplicemente questo:

     cifra     riporto in          cifra    riporto in
    presente    ingresso           futura     uscita
    --------------------------------------------------
       0           0                  0          0
       0           1                  1          0
       1           0                  2          0
       1           1                  3          0
       2           0                  4          0
       2           1                  5          0
       3           0                  6          0
       3           1                  7          0
       4           0                  8          0
       4           1                  9          0
       5           0                  0          1
       5           1                  1          1
       6           0                  2          1
       6           1                  3          1
       7           0                  4          1
       7           1                  5          1
       8           0                  6          1
       8           1                  7          1
       9           0                  8          1
       9           1                  9          1
      

dove

"cifra futura" = (2 * "cifra presente" + riporto in ingresso) mod 10
riporto in uscita = (2 * "cifra presente" + riporto in ingresso)/10

Non ho usato a caso i termini "presente" e "futura", perche' e' facile vedere che questa e' la tavola di transizione di una semplice macchina sequenziale, dove la "cifra" rappresenta lo stato, il "riporto in ingresso" rappresenta l'ingresso, il "riporto in uscita" rappresenta l'uscita. Ora, i riporti di ingresso/uscita sono singoli bit, dunque non c'e' da porsi il problema di come codificare i rispettivi simboli; tale problema si pone invece per lo stato, ossia per le "cifre". Come codifichiamo le cifre? Il testo del progetto ci dice che, anziche' usare una codifica arbitraria come siamo soliti fare, dobbiamo usare la codifca BCD (che e' poi, come anticipavo prima, la "codifica naturale" per le cifre decimali); a questo punto la nostra tavola di transizione si modifica banalmente in

    s3 s2 s1 s0   cin     s3's2's1's0'   cout
    -----------------------------------------
    0  0  0  0     0      0  0  0  0       0
    0  0  0  0     1      0  0  0  1       0
    0  0  0  1     0      0  0  1  0       0
    0  0  0  1     1      0  0  1  1       0
    0  0  1  0     0      0  1  0  0       0
    0  0  1  0     1      0  1  0  1       0
    0  0  1  1     0      0  1  1  0       0
    0  0  1  1     1      0  1  1  1       0
    0  1  0  0     0      1  0  0  0       0
    0  1  0  0     1      1  0  0  1       0
    0  1  0  1     0      0  0  0  0       1
    0  1  0  1     1      0  0  0  1       1
    0  1  1  0     0      0  0  1  0       1
    0  1  1  0     1      0  0  1  1       1
    0  1  1  1     0      0  1  0  0       1
    0  1  1  1     1      0  1  0  1       1
    1  0  0  0     0      0  1  1  0       1
    1  0  0  0     1      0  1  1  1       1
    1  0  0  1     0      1  0  0  0       1
    1  0  0  1     1      1  0  0  1       1
      

Dunque come realizziamo alla fine il nostro convertitore binario-BCD (leggasi, aggiungo ancora una volta, binario-decimale)? Come una rete iterativa a 10 celle, dove ciascuna cella e' una macchina sequenziale descritta dalla tavola sopra costruita, il riporto in uscita da ciascuna cella va connesso al riporto in ingresso della cella alla sua sinistra, e ciascun bit da convertire entra come riporto in ingresso nella cella di destra.

Vogliamo fare un esempio, per chiarire meglio le cose? Supponiamo per semplicita' che i bit da convertire siano 6 anziche' 32; dunque il nostro accumulatore dovra' essere in grado di convertire il massimo numero binario a 6 bit (2^6 - 1 = 63) e pertanto dovra' avere solo due cifre:

    Acc = 0 0

Sia 110100 la sequenza da convertire. Allora, usando la tavola di transizione di cui sopra:

                        Acc = 0 0
    (Primo bit = 1)     Acc = 0 1 (BCD: 0000 0001) infatti (1) = 1
    (Secondo bit = 1)   Acc = 0 3 (BCD: 0000 0011) infatti (11) = 3
    (Terzo bit = 0)     Acc = 0 6 (BCD: 0000 0110) infatti (110) = 6
    (Quarto bit = 1)    Acc = 1 3 (BCD: 0001 0011) infatti (1101) = 13
    (Quinto bit = 0)    Acc = 2 6 (BCD: 0010 0110) infatti (11010) = 26
    (Sesto bit = 0)     Acc = 5 2 (BCD: 0101 0010) infatti (110100) = 52

Come comportarsi in queste circostanze. In genere, o il testo richiede esplicitamente una tipologia di soluzione, o altrimenti la soluzione e' unica e non c'e' necessita' di specificarla, o in alternativa ci si affida al "buon senso": tra le varie possibili opzioni, ce ne sara' evidentemente qualcuna che e' palesemente migliore di altre sotto uno o piu' criteri. (Il concetto che vorrei che gli studenti capissero e' che, nel mondo reale, le decisioni finali saranno lasciate a voi stessi e alla vostra responsabilita': non basta sapere, occorre anche -- e soprattutto -- sapere che cosa e' meglio.)

(1) Attenzione all'uso di XSYNC come Clear asincrono: se arrivano due blocchi consecutivi di dati, il contatore resterebbe (erroneamente) al conteggio 0 per *due* clock consecutivi. In circostanze del genere, usare sempre un'inizializzazione *sincrona* del contatore di controllo.

(2) Per una ragione opposta, e' bene arrestare il contatore quando e' arrivato al conteggio terminale: se il successivo XSYNC arriva dopo oltre 12 clock, TC ridiventa attivo, il che potrebbe avere conseguenze indesiderate.

(3) Non serve a nulla condizionare IORD*SEL anche con l'uscita del flip-flop: se la CPU va a leggere quando il dato non e' ancora pronto, che differenza fa farle leggere un dato errato oppure lo stato del Data Bus non pilotato?

(4) Il registro di uscita deve essere caricato tramite un Enable derivato in qualche modo dal TC, non mediante il clock.

(5) Il flip-flop di I/O Status deve generare un interrupt, oppure forzare Ready sul bus; altrimenti, come fa la CPU a capire che e' pronto un nuovo dato?

SEROUT
======

(1) Il registro di input non puo' essere caricato da STARD, che e' semplicemente un segnale di controllo, ma dalla combinazione IOWR*SEL.

(2) Manca una abilitazione al caricamento del PISO, che dovrebbe essere derivata sincronizzando in qualche modo la combinazione IOWR*SEL di cui sopra al clock XCLK; questa stessa abilitazione, ritardata di in XCLK, diventa (in maniera naturale) XSYNC da mandare in uscita.

(3) XDATA non va alla CPU, ma al mondo esterno; di conseguenza non ha senso condizionarlo ad un IORD.

(4) Il TC deve generare un interrupt, o forzare Ready: altrimenti, come fa la CPU a sapere che il dato e' stato completamente emesso?

(1) Se lei pilota il Counter col System Clock, questo continua a girare inutilmente per la quasi totalita' del periodo di 5 secondi. Meglio sarebbe derivare dal System Clock un clock a 5/16 di secondo e pilotare con questo il Counter, che in questo modo non solo girerebbe in continuazione ma a bassa velocita', ma esaurito un giro riprenderebbe immediatamente il giro successivo senza porci il problema di cosa fare al TC in attesa del successivo scatto dei 5 secondi. (Il TC come lo ha connesso lei non serve a nulla!)

(2) I registri sui sensori non servono. I sensori di temperatura hanno variazioni lentissime, e i dati cha da essi vengono letti possono tranquillamente essere assunti stabili nell'arco di poche decine di nanosecondi -- quanti ne servono per elaborarli.

(3) Lei seleziona un sensore ogni System Clock e manda il dato corrispondente alla CPU tramite I/O Data Bus. Intanto, mai la CPU riusira' a catturare un dato che e' presente per un solo System Clock; in secondo luogo, da nessuna parte la CPU e' avvertita che un nuovo dato e' pronto (qui, occorre generare un interrupt oppure attivare la linea di bus Ready). Inoltre, come fa la CPU a sapere a quale sensore si riferisce il dato che lei sta inviando? Occorre fare in modo che la CPU possa leggere anche l'indirizzo del sensore.

(4) Lei invia i dati per tutti gli elementi riscaldanti in un colpo solo. Va bene, se non che cio' implica che la CPU deve ogni volta assemblare una word con i valori di *tutti* gli elementi riscaldanti. La soluzione e' semplice: visto che (punto 1) e' opportuno spaziare di molto nel tempo le operazioni tra un acanale e l'altro, e che (punto 3) dovra' mandare alla CPU anche l'indirizzo del sensore (che ovviamente coincide con quello dell'elemento riscaldante), allora, molto semplicemente, fa in modo che la CPU risponda solo sul bit 0 dell'I/O Data Bus col dato relativo a un solo elemento riscaldante (quello corrispondente all'indirizzo del sensore) e poi lei dirotta via hardware quel bit al flip-flop corrispondente.

In particolare volevamo sapere se:
1) il clock dei flip-flop relativi agli elementi riscaldanti è giusto porlo pari al TC del contatore di 5 sec.?

Come ha visto, il problema e' un po' piu' complesso che non il solo clock.

2) è corretto collegare l'uscita del DEMUX all'AND dei buffer-3-state di ogni registro relativo al proprio sensore?

Si'.

3) è corretto inserire il TC del contatore all'ingresso CLR del contatore a 16? Ci potrebbero essere problemi nella temporizzazione?

I problemi ci sono, ma come abbiamo visto sono ben altri.

4) è corretto utilizzare lo STARD del PD32 per resettare il contatore di tempo?

No, questa e' un'interfaccia che va a ciclo continuo, non ha bisogno di essere avviata. Ogni ciclo deve partire ogni 5 secondi, senza intervento diretto dalla CPU.

(1) Non e' chiaro quando e in conseguenza di che cosa abbiano inizio le operazioni dell'interfaccia.

(2) Dal momento che l'accumulatore invia sempre i suoi dati ad altri registri, puo' risparmiarsi il multiplexer per la costante "0" semplicemente mantenendo l'accumulatore in Clear quando l'interfaccia e' a riposo.

(3) Conviene ipotizzare che i registri X abbiano uscita tri-state, evitando cosi' il multiplexer per i dati B del modulo FPMA: i multiplexer richiedono sempre un mucchio di porte!

Le ultime due osservazioni non sono veri e propri errori, semplicemente mettono in evidenza dei possibili affinamenti; per il resto la soluzione va benissimo.

BINBCD
======

E' piu' o meno cosi' che andava fatto il progetto. Solo alcune osservazioni:

(1) Lei ipotizza che, al termine di un blocco da 32 bit, ne abbia subito inizio un altro; nelle trasmissioni seriali non e' cosi', tra un blocco e il successivo puo' trascorrere un numero indefinito di clock, e dunque di dati da ignorare. Cio' comporta che lei avrebbe dovuto contare i 32 bit e caricare il registro di uscita al termine del conteggio, dopo di che aspettare il prossimo XSYNC -- che puo' arrivare anche immediatamente, ma non e' detto.

(2) Non ci vuol molto ad aggiungere a ciascuna delle sue celle un rivelatore di zero, inviare le rispettive uscite a un codificatore a priorita', e di qui individuare qual e' la prima cifra signficativa diversa da zero, in modo da iniziare l'emissione a partire proprio da questa cifra.