Intanto, se il suo progetto e' un'interfaccia per microprocessore, puo' sempre utilizzare il segnale di System Reset (SYSRESET) che circola nel bus di sistema, e che consiste proprio in un impulso (tipicamente della durata di qualche centinaia di millisecondi) emesso una sola volta all'accensione dell'intero sistema, che copre il periodo di assestamento delle alimentazioni ai valori nominali, e serve appunto a garantire che il sistema inizi le operazioni partendo da uno stato predefinito.

Se invece il suo progetto e' di tipo "stand-alone", ossia non connesso ad alcun bus di microprocessore, puo' sempre ipotizzare, se necessario, la disponibilita' di un modulo "Power On Reset Generator" (dalla struttura interna non meglio specificata, perche' e' una struttura ibrida analogico/digitale, ma assunta nota) che produca un segnale Power-On Reset con le caratteristiche suindicate.

Tenga tuttavia presente che, dati i tempi contingentati della realizzazione di un progetto all'esame, quello del power-on reset e' davvero l'ultimo dei problemi di cui si deve preoccupare!

- scandire solo per colonne ma questo potrebbe creare problemi nel caso in cui mentre un tasto è premuto l'utente ne preme un'altro sulla stessa riga. Questa soluzione impiega soli 8 cicli del SYSCLK per scandire l'intera tastiera

La digitazione multipla in genere e' esclusa da questi progetti perche' piuttosto complessa. Di fatto, possono esserci varie combinazioni anche soltanto con due tasti:

1) tasto A premuto, poi tasto B premuto, poi tasto A rilasciato, poi tasto B rilasciato;

2) tasto A premuto, poi tasto B premuto, poi tasto B rilasciato, poi tasto A rilasciato;

3) tasto A premuto, poi tasto B premuto, poi tasto B rilasciato, poi tasto B ancora premuto, etc etc

(Casi di questo genere si verificano anche sulla tastiera del suo PC, quando ad esempio il tasto A coincide col tasto Ctrl oppure col tasto Shift oppure col tasto Alt.)

- scandire i contatti ad uno ad uno, ciò comporta l'impiego di 2 contatori il primo sincronizzato sul SYSCLK ed il seguente che ha come CE il TC del primo. Questa soluzione impiega 128 cicli del SYSCLK per scandire l'intera tastiera

Sottintendendo che la seconda soluzione è meno complessa mi chiedevo se i 128 cicli di clock non fossero un pò troppi per una pressione di un tasto. Supponendo un clock da 250 MHz ciò significherebbe infatti 0,512 microsec per un'intera scansione

No, non sono troppi. Un/a esperto/a dattilografo/a arriva piu' o meno ai 240 caratteri al minuto, il che significa 4 caratteri al secondo, il che significa che il tasto rimane premuto per circa 1/8 di secondo, ossia 125 millisecondi (MILLIsecondi!): in questo intervallo di tempo, con le frequenze di clock da lei stimate, riusciamo a fare circa 250.000 scansioni!

(1) Mancano i circuiti di interfaccia per la scrittura nel FIFO.

(2) Il FIFO e' un dispositivo asincrono, appena scompare RD scompare anche il dato in uscita da esso, e quindi tale dato va immagazzinato in un registro se lo si vuole utilizzare anche piu' in la' nel tempo.

(3) La seconda implementazione di RUOTA e' improponibile. La prima implementazione si potrebbe semplificare facendo leggere il dato dal FIFO quando il contatore mod 8 principale raggiunge il Terminal Count, poi sommando l'uscita della ROM alle uscite del contatore stesso (modulo 8) e pilotando con questo risultato il multiplexer all'uscita del registro. In questo modo, risparmierebbe un contatore. Inoltre, si puo' risparmiare anche il multiplexer finale per la generazione dello zero, semplicemente usando opportunamente l'ingresso di Enable di cui ogni multiplexer dispone.

14/02/02
========

(1) E' vero che l'ADC non fornisce segnale di fine conversione, ma ha comunque bisogno di un segnale di inizio conversione, visto che il tempo di conversione non e' assimilabile a 0.

(2) A che serve abilitare o disabilitare lo shift register?

(3) In alternativa al contatore delle medie mobili, si poteva usare uno shift register a 8 bit sull'uscita del comparatore e testare che fossero tutte e otto a 1.

(4) Non mi e' chiara la gestione dei clock: perche' usa un clock a 10 MHz dividendolo per 8 e usando la frequenza risultante per campionare il segnale? Il clock a 10 MHz va inviato all'ADC come inizio conversione, va usato per catturare i singoli campioni, va usato per scrivere entro la RAM (che ha tempo di ciclo di 75 nsec). L'unico inghippo sta nel fatto che gli addizionatori hanno tempo di 60 nsec, quindi non e' possibile realizzare un albero di sommatori (che nel suo disegno peraltro non appare) ma va inserito un registro di pipeline tra i due livelli dell'albero.

Questo progetto va un po' rivisto, alla luce di quest'ultima considerazione.

18/10/05
========

(1) Gli impulsi di cui si parla sono generati da dispositivi elettromeccanici, quindi e' ragionevole assumere che la loro durata sia maggiore del periodo del clock. In tal caso, pero', i flip-flop in alto non generano certo un segnale largo quanto un singolo periodo di clock!

(2) Nell'accumulo dell'importo si poteva risparmiare qualche addizionatore osservando che arriva un solo impulso alla volta, e quindi sarebbe stato sufficiente un registro accumulatore su cui andava in somma solo l'uscita della ROM corrispondente all'impulso in arrivo.

(3) I registri di uscita vanno opportunamente abilitati al caricamento, altrimenti cambiano di stato ad ogni clock (e' da immaginare che la stampante abbia bisogno di vedere dati stabili mentre li stampa).

(4) Come e' fatto un sommatore mod 60? e uno mod 24?

(5) A che serve il flip-flop di Interrupt Request, se non c'e' nessuna CPU nel sistema?

(6) Come ho detto ad altri suoi colleghi a proposito di questo progetto: a rigore, la stampante dovrebbe ricevere codici ASCII e non numeri binari -- ma non so se anche questo fosse nelle intenzioni di chi ha steso il testo del progetto.

Stavo rivedendo le domande ke le ho posto oggi è mi è venuto un dubbio... Relativamente alla domanda 3 del 13/09/2006 non ho capito se è (2^7)^(2^12) oppure (2^7) x (2^12).

Nessuna delle due. Era (2^12)^(2^7), ossia (numero di possibili combinazioni stato/uscita)^(numero di possibili combinazioni ingresso/stato = numero di righe della tavola) = (2^(4+8)) ^ (2^(3+4)).

E comunque non capisco da dove viene quel 2^1536 nella Q & A #10 (Macchine di Mealy) ...

Sappiamo che (x^y)^z = x^(y*z). Dunque (2^12)^(2^7) = (2^12)^128 = 2^(12*128) = 2^1536.

(2) L'albero di addizionatori e' un po' pesante, non trova? Un modo semplice ed efficiente e' il seguente: si spezza ICOMPOUT in due sezioni da 16 bit ciascuna, ciascuna sezione viene mandata a una ROM in cui sono immagazzinate le somme dei bit di ingresso (risultato su 5 bit, poiche' puo' avere valore da 0 a 16 compreso), e i risultati vengono mandati a un normale addizionatore a 5 bit.

(3) Non useremo mai, se non richiesto esplicitamente, la mascheratura degli interrupt, per cui si puo' evitare di fare intervenire i segnali SETIM, CLRIM e simili.

(4) Il flip-flop di richiesta interrupt deve tener memoria che si e' verificato un superamento di soglia, ma deve restare settato fino all'IACK anche se, trascorrendo altri clock, non c'e' piu' superamento.

Le invio il progetto svolto del 12/12/05 Tema A.
[...]

Direi che, a parte le considerazioni che lei stesso fa subito dopo, non ci sono grossi problemi. Non si capisce da dove venga il segnale QREG che concorre ad abilitare il contatore in basso a sinistra, ma immagino che sia l'uscita del flip-flop che memorizza l'evento di coda piena.

La cosa che secondo me è poco realistica è l'assunzione di fondo che ho fatto, ovvero di ipotizzare che, dopo la corretta scrittura di un messaggio, possa stare tranquillo di non ricevere altri SYNC_IN mentre sto codificando e inviando serialmente il messaggio.

Purtroppo, mi sono reso conto che avrei dovuto pensare meglio soltanto verso la fine del compito.

Se questo dovesse capitare all'esame, non avrei probabilmente il tempo di modificare in tutto o in parte quello che ho fatto.

Esatto.

1) Ci sono errori macroscopici che non ho notato in quanto ho fatto in questo progetto?

No, a parte la considerazione di fondo.

2) Risulterebbe comunque sufficiente, in termini di valutazione, utilizzare una soluzione non troppo realistica, come in questo caso?

Sicuramente sufficiente, almeno in questo caso.

3) Questa domanda esula dal progetto specifico. Ho notato che, a volte, si preferiscono usare i buffer tri-state al posto dei MUX. Non è stupefacente, considerando che si sta parlando di una porta contro, solitamente, più porte in cascata. Allora la domanda è, perché non usare sempre buffer tri-state? Spero non sia una domanda sciocca.

Qualcuno disse una volta: "Non esistono domande sciocche, solo le risposte talvolta possono esserlo." Al di la' delle corrette considerazioni che lei stesso fa sul numero di porte nell'uno e nell'altro caso, occorre considerare che al multiplexer standard si invia un codice di selezione binario, mentre al multiplexer realizzato con tri-state occorre inviare un codice 1-su-N gia' decodificato: se tale codice non e' gia' pronto in qualche modo, occorrera' usare un decoder, il che probabilmente vanifica il risparmio sul numero di porte. Un'altra considerazione spesso importante e' il numero di collegamenti e il percorso ("routing") che essi devono fare: in un multiplexer standard (che diremo "concentrato") gli N segnali di ingresso devono tutti viaggiare lungo il sistema fino a raggiungere il multiplexer, nel caso di porte tri-state (multiplexer "distribuito") l'unico segnale che viaggia su grande scala e' l'uscita del multiplexer. In quest'ultimo caso, tuttavia, un percorso altrettanto lungo deve essere seguito dai segnali di abilitazione, il che ci potrebbe riportare al punto di partenza; tuttavia, se essi possono essere generati localmente, come nel caso delle combinazioni IORD*SEL nelle porte di input, allora il vantaggio e' indiscutibile. Un'ultima considerazione: mentre un multiplexer classico ha sempre un numero di ingressi pari a una potenza di 2 (numero che peraltro deve essere definito anzitempo), il multiplexer a porte tri-state puo' facilmente essere realizzato per un numero qualunque di ingressi, senza conseguente spreco di porte inutilizzate. (Quest'ultima considerazione tuttavia, alla luce delle moderne tecniche di realizzazione mediante "gate array", va presa con le molle, perche' i "compilatori" di circuiti sono solitamente in grado di identificare le porte non usate o comunque ridondanti e di renderle di conseguenza riutilizzabili.)

(2) Non vedo necessita' di una SCO esplicita. Se P e IRQ sono contemporaneamente alti, i contatori rimangono bloccati, e tanto basta. D'altra parte, lei gia' converte la transizione 0-1 di P in un impulso da un singolo clock (secondo flip-flop in basso da destra), quindi di cos'altro dobbiamo tenere memoria? Diverso sarebbe stato se, magari, avesse inglobato anche questo flip-flop, o addirittura tutti e due, nella SCO, che allora avrebbe avuto un senso.

(3) Il registro in basso a sinistra che fa da porta di input e' connesso male: se (evento altamente improbabile, ma non impossibile) il tasto viene rilasciato dopo IACK e prima che venga emesso IORD, i contatori sono ripartiti e il dato letto da ROM non e' piu' valido. Invece, basta catturare il dato da ROM ad esempio con l'impulso di cui al punto (2).