(1) Come ho detto a lezione, il registro di uscita e' superfluo se decidiamo di congelare lo stato del contatore al completamento (con successo o meno) delle operazioni. Tuttvia c'e' una sottile differenza, tra l'avere un registro e non averlo. Se il registro non c'e', quando la CPU avvia una nuova ricerca il risultato della ricerca precedente viene irrimediabilmente perso (come probabilmente e' anche giusto che sia!); se invece il registro e' presente, possiamo fare in modo che il risultato della ricerca precedente rimanga ancora disponibile fino al completamento della nuova ricerca -- ma in tal caso il registro dovra' necessariamente avere un ingresso di abilitazione al caricamento, in modo da essere aggiornato solo al momento opportuno. Cosi' come voi lo avete disegnato, privo di abilitazione, esso cambia di contenuto ad ogni clock e incamera il risultato finale solo quando il contatore viene congelato -- in altri termini, non svolge nessuna funzione di memorizzazione e pertanto e' del tutto superfluo.

(2) La logica di controllo del multiplexer all'ingresso del registro puo' essere resa piu' semplice: il risultato della ricerca deve coincidere col campo INFO fornito dalla ROM solo se il comparatore da' un risultato di uguaglianza, in tutti gli altri casi il risultato deve essere forzato a 000...0 -- dunque il multiplexer puo' essere controllato semplicemente tramite l'uscita "=" del comparatore.

(3) Il controllo del CE del contatore e' in parte sbagliato: CE deve andare a 0 quando (a) TC = 1, oppure (b) KEY_CPU = KEY_ROM, oppure (c) KEY_CPU < KEY_ROM (quest'ultimo caso, dato l'ordinamento crescente delle KEY_ROM, significa che non toveremo mai piu' la KEY cercata). Nella vostra soluzione i casi (a) e (b) sono correttamente realizzati, ma per il caso (c) avete usato invece l'uscita KEY_CPU > KEY_ROM dal comparatore.

(4) L'uscita KEY_CPU < KEY_ROM che non avete utilizzato, non va connessa a massa (il che significa cortocircuitare l'uscita di una porta!) ma va semplicemente lasciata non connessa.

(5) IACK e' un segnale attivo alto, quindi puo' essere connesso al Clear del flip-flop di Interrupt Request solo se anche CLR e' attivo alto (e non attivo basso come voi lo avete disegnato -- basta semplicemente eliminare il pallino).

(6) L'ingresso della porta AND open-collector che genera -IRQ non puo' essere lasciato sconnesso: o non lo si disegna, o lo si connette ad un 1 logico fisso.

(7) La connessione da CE all'ingresso J del flip-flop e' logicamente sbagliata: occorre interporre un invertitore, affinche' sia J = 1 quando CE = 0, ossia affinche' il flip-flop si setti quando il contatore viene bloccato.

Per il resto tutto ok.

tally.pdf

Inoltre, c'e' qualche contraddizione nelle polarita' di alcuni segnali; ad esempio, il flip-flop che genera LE1 ha un ingresso di SET attivo basso (data la presenza del pallino) che viene pilotato dal segnale START che e' normalmente basso, salvo il momento in cui la scrittura da parte della CPU lo porta alto per un singolo periodo di SysClk, il che significa che questo flip-flop e' quasi sempre forzato a Q=1 (quando invece immagino che lei volesse portarlo a Q=1 proprio quando arriva START: in tal caso il SET deve esere attivo alto, non basso come lei lo ha disegnato). Stessa cosa per vari altri segnali: l'ingresso SET del contatore down (a proposito, cosa ci si aspetta che faccia un ingresso SET in un contatore?), l'ingresso SET del flip-flop che genera LE0 e di quello che genera C.

La logica che genera CE (i due flip-flop in basso a sinistra) non e' molto chiara. All'arrivo di START, il primo flip-flop va immediatamente ad 1; al clock successivo il secondo flip-flop cosa fa, essendo il suo ingresso K non connesso? Immagino che l'idea era quella di far andare ad 1 anche il secondo flip-flop al prossimo clock, nel qual caso dovrebbe essere K=0 fisso.

Tutti quei flip-flop mi pare abbiano le seguenti funzioni (come risultano dalle temporizzazioni):

(1) caricare il contatore col valore del registro K (LE0 attivo per un singolo clock); c'e' qui pero' da osservare che le specifiche non prevedono che la CPU emetta il valore di K!

(2) abilitare il caricamento del registro di uscita (segnale LE1) fino al raggiungimento del conteggio 000;

(3) forzare il multiplexer superiore, anziche' il registro, ad apparire come operando U al primo clock utile della sequenza di calcolo.

Probabilmente lo stesso risultato si sarebbe ottenuto in maniera piu' semplice soltanto decodificando opportuni conteggi dal contatore, e sicuramente con un numero minore di flip-flop. C'e' anche da tener presente che il segnale di START, essendo generato indirettamente da un ciclo di I/O Write, ha durata di esattamente un SysClk ed e' sincronizzato con esso: andrebbe verificato se cio' non debba comprtare modifiche alla logica di generazione dei vari segnali di controllo.

Da quanto si capisce (ma non sarebbe male dirlo esplicitamente da qualche parte nel progetto), lei trasforma la formula di calcolo, nel caso ad esempio K=3, in y = ((a3 * x + a2) * x + a1) * x + a0, e va benissimo. Tuttavia, dato il ridotto numero di clock che l'intera sequenza richiede (massimo 8), si poteva anche pensare di azzerare inizialmente il registro accumulatore, e trasformare la sequenza di calcolo in y = (((0 * x + a3) * x + a2) * x + a1) * x + a0, richiedendo cosi' un clock aggiuntivo ma risparmiando entrambi i multiplexer sull'operando U.

In ogni caso, la valutazione e' sicuramente buona.

Ho pensato che fosse ipotesi standard che dove non viene specificato la periferica abbia un suo proprio clock diverso dal clock del processore.

Sara' anche, ma e' sempre meglio dirlo esplicitamente (e magari giustificare l'uso di un clock a frequenza cosi' relativamente alta).

Qui forse ho capito male come viene segnalata l'attivazione basso/alto degli ingressi nei componenti. Io l'avevo intesa in questo modo: siccome il nome dell'ingresso sul componente è scritto negato allora vuol dire che è attivo basso. Poi il pallino fa da invertitore per il segnale in ingresso; quindi quando START=1 l'invertitore lo fa diventare 0, l'ingresso è attivo basso, e quindi viene attivato.

Sia il pallino che la negazione negano, se sono presenti entrambi le due negazioni si annullano, dando come risultato un segnale ancora attivo alto. Se lei vuole indicare un segnale attivo basso, deve usare o solo la negazione sul nome del segnale o solo il pallino sul suo terminale.

Ho pensato che siccome un contatore up viene inizializzato con 000 con un segnale di CLEAR sui FF, allora un contatore down si inizializzare con 111 con un segnale di SET.

Il segnale di SET come lo intende lei non esiste nei contatori commerciali, sia up che down hanno solo un ingresso di Clear che forza lo stato a OO..O; e' chiaro che, se le fa comodo, puo' anche ipotizzare la presenza di un segnale del genere, sebbene quasi sempre si possa ovviare utilizzando il Parallel Load con 11..1

Qui ho pensato che si potesse supporre perché le specifiche non lo prevedevano ma nemmeno lo vietavano.

Questo e' un discorso che non regge. Immagini cosa accade nel mondo reale: le stesse specifiche vanno anche al programmatore che scrive il software di controllo, e lui non sapra' mai che deve anche emettere il valore di K. Una volta messo assieme il software e l'hardware, non funzionera' nulla e i due cominceranno a litigare!! Quella che lei sta imponendo e' una specifica aggiuntiva, per di piu' ingiustificata.

In proposito, tenga sempre presente la regola d'oro del progettista: emettere output rigorosamente secondo specifiche, in input aspettarsi di tutto...

C'e' anche un problema di inizializzazione del registro: essendo i numeri in complemento a 2, non possiamo inizializzarlo a 0, perche' potrebbero arrivare anche dati tutti negativi e allora falliremmo a individuare il massimo tra di essi. O si precarica il registro con il minimo numero negativo rappresentabile (100...00) oppure si fa in modo, magari decodificando l'opportuno conteggio dal contatore, che il primo dato della serie di 256 finisca "comunque" nel registro.

Non e' chiaro quando e per quale causa abbia inizio la sequenza di operazioni. Dal suo disegno, sembra di capire cha appena esaurita una sequenza si inizia a lavorare sulla successiva, ma il testo richiede che sia la CPU a decidere quando e' il momento di ricominciare.

Non si vede nessun meccanismo mediante il quale la CPU viene avvertita che le elaborazioni sono terminate e che dunque possa andare a leggersi il risultato (tipicamente, in questa circostanza si emette un interrupt).

Infine, non serve a nulla condizionare l'And sui tri-state di uscita con altri segnali che non siano IORD e SEL: se la CPU decide di andare a leggere il risultato quando esso non e' ancora pronto, non fa alcuna differenza che essa vada a leggersi il contenuto corrente del registro ovvero cio' che trova su un I/O Data Bus non pilotato!

Se lo ritiene utile, per questo compito esiste un documento che lo discute a fondo e che propone una possibile soluzione completa: lo trova a http://www.pmar.it/retilogiche/prove/ifmax.pdf assieme alle soluzioni di altri compiti che trova alla voce "Prove d'esame" del nostro sito.

La domanda è: ma il tempo di clock non si può ridurre indefinitamente aumentando la parallelizzazione ad ogni stadio?

Certamente. Ma dovrebbe essere abbastanza evidente, se non altro alla luce del buon senso, che in questi casi l'assunzione implicita e' che almeno una delle reti originali rimanga non duplicata.

Poi le volevo chiedere la correzione della domanda numero 3 sempre dello stesso compito (in allegato)

(2) L'encoder va bene, anche se il testo chiedeva di usare multiplexer di un determinato taglio; in ogni caso, esso non tiene conto della possibilita' che vengano premuti due o piu' tasti contemporaneamente. E' anche vero che, trattandosi di eventi manuali/meccanici, la contemporaneita' e' molto relativa, data anche la elevata frequenza di clock; e' anche vero che in una sequenza di eventi come (a) tasto A abbassato e mantenuto premuto, (b) tasto B abbassato e poi rilasciato, (c) tasto A rilasciato, la pressione del tasto B passa del tutto inosservata (se anche l'interrupt viene servito immediatamente, la scansione non riparte se non dopo il rilascio del tasto A). Trattandosi tuttavia di sottigliezze, possiamo anche lasciar correre.

(3) La richiesta di interrupt non e' generata correttamente. Consideri cosa accade: (a) C va alto, essendo trovato un tasto premuto; (b) si attiva la richiesta di interrupt; (c) la CPU reagisce con IACK, che resetta il flip-flop di Interrupt Request; (d) ma il tasto e' ancora premuto, quindi al clock successivo il flip-flop si setta nuovamente e genera una nuova Interrupt Request.

(4) Il registro in uscita dalla ROM e' probabilmente superfluo: dal momento che abbiamo a che fare con eventi manuali/meccanici, e' da presumere che l'Interrupt Acknowledge (e dunque l'esecuzione della routine di servizio interrupt) venga emesso "molto" prima che il tasto venga rilasciato, ossia che gli indirizzi di ROM cambino, e quindi non sembrerebbe necessario memorizzare l'uscita dalla ROM.

(5) Nella routine software che mi propone, cos'e' D0 ?

Il valore assoluto di un intero N in complemento a 2 veiene generato con la seguente logica: se il bit di segno e' 0 (numero positivo) si lascia passare il numero N immutato, se il bit di segno e' 1 (numero negativo) si lascia passare il complemento a due di N, che viene generato complementando tutti i bit di N (cosa che indico con N*) e sommando aritmeticamente 1. Sembrerebbe quindi ci sia bisogno di un multiplexer e di un addizionatore i cui operandi siano la costante "000...00" e N* e con CarryIn = 1. In realta' la cosa puo' essere resa ancora piu' semplice, eliminando il multiplexer e mantenendo solo l'addizionatore: se il bit di segno è zero, eseguiamo la somma aritmetica 0 + N + 0, mentre se il bit di segno è 1 eseguiamo la somma aritmetica 0 + N* + 1. Il circuito che ne deriva appare nel PDF allegato.

0612082046-1.pdf

(2) Dovendo immagazzinare solo numeri positivi, i due registri non hanno bisogno di particolare inizializzazione se non di una messa a zero all'inizio delle operazioni, e per questo e' sufficiente usare l'ingresso di Clear asincrono.

(3) L'abilitazione al caricamento dei registri di massimo e di minimo, invece, deve essere inibita quando il contatore ha raggiunto il Terminal Count e dunque quando la sequenza di dati in esame e' terminata. Attenzione, in tal caso lo stato 0 del contatore, essendo forzato dal segnale di inizio operazioni, potrebbe essere uno stato "speciale" di durata non necessariamente uguale a un periodo di XCLK (questo clock e il System Clock a cui e' legato il segnale di inizio operazioni *non* sono correlati) e quindi potrebbe essere opportuno *non* abilitare i registri di massimo/minimo al carimento in questo stato. Le normali operazioni partirebbero allora col conteggio 1, e allora attenzione al Terminal Count, che si setta al conteggio 1023 quando ancora manca un dato alla fine della sequenza.

(4) Il flip-flop di Interrupt Request deve avere XCLK come clock, mentre IACK deve andare sull'ingresso di Clear asincrono. Inolttre, IACK deve anche abilitare l'emissione dell'Interrupt Vector Number sull'I/O Data Bus.

(5) I vari SEL vanno generati da una decodifica dell'I/O Address Bus, non dell'I/O Data Bus. Noti che uno stesso SEL puo' essere utilizzato sia per la lettura (I/O Read) che per la scrittura (I/O Write); nel suo caso, non e' necessario generare tre SEL distinti (SEL0, SEL1, SEL2) ma ne bastano due.

Alla fine del procedimento di risoluzione le ho scritto un paio di domande relative alla prova.

1) ad un certo punto il testo dice che la CPU calcola U e aggiorna delle locazioni di memoria AMIN,BMAX,UMIN e Umax. Queste azioni mi sembrano molto semplici da implementare, ma quello che volevo chiederLe è se devo farle io. Il fatto che il testo dica: "La CPU calcola…." mi ha portato a pensare che non devo occuparmene.

Quello che lei ha usato e' un testo d'esame per Calcolatori 2, in cui il software PD-32 faceva parte del programma. Se lei fa parte del Nuovo Ordinamento, in cui tale argomento non e' in programma, allora non se ne deve occupare; se lei invece fa parte del Vecchio Ordinamento, in cui tale argomento *era*  in programma, allora se ne dovra' occupare.

2) Nel mio tentativo di risolvere il problema mi sono accorto di aver bisogno della collaborazione della CPU, la quale deve inviarmi 2 segnali. Uno di init per inizializzare i due registri Rmin e Rmax e anche di un segnale che in qualche modo mi resetti il contatore, ovvero un clear. Penso che questo dovrebbe essere il compito dello SCO. Potrebbe, anche in linea di massima, dirmi come faccio a progettarlo?

Vedo dal progetto che lei usa una scrittura su porta fittizia (SEL0) per generare il Clear del contatore: benissimo, lo stesso segnale puo' anche inizializzare i registri. Quanto allo SCO: ma lei l'ha gia' fatto, coincide praticamente col contatore modulo 1024, visto che il suo compito e' proprio quello di enumerare gli stati operativi dell'interfaccia e, quando e' arrivato al termine del conteggio, a stabilire che le operazioni sono terminate!

(1) Non e' necessario disegnare i dettagli interni del FIFO (che comunque sono ben piu' complessi di quelli che lei ha indicato). Esso puo' invece essere visto semplicemente come scatola nera con indicati solo i segnali necessari (Data In, Data Out, Read, Write, Full, Empty).

(2) La ROM e' pilotata dai 10 bit piu' significativi di un contatore binario a 10+3 bit, in modo che l'indirizzo si incrementi ogni 8 clock, e va bene. Tuttavia, questo contatore andrebbe resettato almeno una volta all'inizio delle operazioni (e allora e' piu'semplice resettarlo ad "ogni" comando di inizio operazioni!)

(3) La lettura da un FIFO e' generalmente asincrona, il che significa che il Read deve essere di tipo impulsivo affinche' il FIFO possa discriminare tra due letture consecutive; questo implica che il dato in uscita dal FIFO non e' valido e stabile per tutti gli 8 clock necessari, e di conseguenza, ad ogni avanzamento dell'indirizzo di ROM, il dato letto dal FIFO andrebbe memorizzato su un registro (magari di tipo latch).

(4) Lei prende l'uscita dalla ROM, la carica su un contatore, e usa l'uscita di quest'ultimo per selezionare il bit del dato da avviare verso l'uscita. La soluzione potrebbe anche andar bene, posto che il caricamento del secondo contatore sia di tipo sincrono, e purtroppo non riesco a leggere bene il disegno in modo da stabilire se il Load di quest'ultimo viene applicato al momento giusto. Ma le chiedo: non sarebbe stato piu' semplice usare come controllo del multiplexer la somma aritmetica modulo 8 (utilizzando un Adder a 3 bit) tra l'uscita della ROM e i 3 bit meno significativi del primo contatore?

(5) Quanto alla generazione degli zeri al termine delle operazioni, e' sufficiente inibire (mediante ingresso di Enable) l'uscita del multiplexer quando il contatore principale arriva alla fine del conteggio.

La periferica in questione sta connessa da una parte alla CPU PD-32 attraverso il bus di sistema, dall'altra agli ingressi e alle uscite di un circuito combinatorio da testare. Attracerso la RAM da 2 Mword (residente sull'interfaccia) la CPU fornisce alla periferica un set di N vettori di ingresso e un set di altrettanti vettori di uscita, diciamo cosi', ideali. La periferica, una volta avviata, legge dalla RAM il primo vettore di ingresso, lo applica al circuito da testare, rileva il vettore di uscita che quest'ultimo genera, ed esegue il confronto bit a bit con il primo vettore ideale di uscita. Se questo primo test "passa", allora la periferica estrae dalla RAM il secondo vettore di ingresso, lo applica al circuito da testare, rileva il vettore di uscita prodotto dal circuito, e lo confronta bit a bit col secondo vettore di uscita ideale. Se anche questo test ha successo, allora la periferica ripete l'operazione con la terza coppia di vettori ingresso/uscita, e cosi' via.

La sequenza degli eventi e' la seguente. Via software, la CPU predispone sulla RAM (accessibile sia dalla CPU che dalla periferica, come abbiamo detto) una serie di vettori di ingresso e una serie di vettori di uscita; poi passa (chiaramente attraverso una porta di output) il numero N di vettori di ciascun set (ovviamente, i due set hanno lo stesso numero di elementi) e avvia le operazioni della periferica, la quale procede come abbiamo visto prima. Le operazioni della periferica terminano (con conseguente generazione di interrupt) o quando tutti i vettori di test sono stati applicati con successo, oppure non appena un qualche test fallisce. Che cosa viene comunicato, in risposta, dalla periferica alla CPU? Molto semplicemente, ad esempio, il numero di test eseguiti con successo: se tale numero e' uguale ad N, allora la CPU capisce che tutti i test sono "passati", se invece esso e' M < N, allora la CPU capisce che solo M test sono passati con successo e dunque che il circuito sotto collaudo ha qualche problema. Tuttavia, il testo chiede che, in caso di test fallito, vengano restituiti anche:

(1) l'indirizzo del vettore di ingresso che ha provocato un'uscita errata; detto A l'indirizzo iniziale della RAM cosi' come e' visto dalla CPU, dovrebbe essere chiaro che l'indirizzo richiesto e' pari ad A+M;

(2) il vettore di uscita "sbagliato", e questo lo si ricava dal circuito sotto collaudo, visto che e' appena stato utilizzato nel confronto (fallito) col vettore di uscita ideale.

Tutte le informazioni restituite dalla periferica alla CPU, transitano ovviamente attraverso porte di input di dimensioni adeguate.