(1) Non e' necessario che le letture di temperatura siano ugualmente spaziate nel tempo l'una dall'altra. Una soluzione alternativa (che le avrebbe anche risparmiato la questione del modulo di conteggio a 5/16) poteva anche consistere nel generare un opportuno segnale con periodo di 5 secondi, e con questo far partire il ciclo di 16 acquisizioni/controlli ad alta velocita'.

(2) Trattandosi di sensori di temperatura, ossia di una grandezza che varia molto lentamente rispetto ai tempi dell'elettronica, potremmo anche fare a meno dei registri di ingresso e leggere direttamente il dato, avendo probabilita' praticamente uguale a 1 di trovare il dato stabile.

(3) Il Multiplexer e' privo di ingressi di selezione; evidentemente, questi devono essere prelevati dalle uscite del contatore mod 16.

(4) Come normale convenzione normale, ai bit di un dato si assegnano gli indici piu' bassi ai bit meno significativi e quelli piu' alti ai bit piu' significativi. Lei invece nel desegno ha assunto che il bit di segno abbia indice 0.

(5) L'analisi della comparazione di due numeri in complemento a 2 va benissimo. Tuttavia, lei dice: "Siccome mi viene richiesto che devo mandare una richiesta di spegnimento elemento se Ti>Ni allora prelevo l'uscita Ti0<Ni0 (infatti Ti>Ni se il suo primo bit è 0 e Ni0 è 1). Questa uscita mi dovrà andare a pilore una richiesta di spegnimento." Ma, nel caso Ti0 = Ni0 (valori con lo stesso segno) lei utilizza l'uscita di sinistra del comparatore a 7 bit che, in mancanza di indicazioni in merito, io presumo essere l'uscita Ti(1-7) < Ni(1-7) (con lo stesso ordine cioe' delle uscite sul comparatore a 1 bit); mentre invece dovrebbe usare l'uscita Ti(1-7) > Ni(1-7).

(6) Analogamente per l'altro gruppo di comparazione: volendo mandare una richiesta di accensione nel caso Ti < Mi, e' giusto prelevare l'uscita < dal comparatore a 7 bit nel caso di segni uguali, non e' corretto prelevare l'uscita segno(T) < segno(M) nel caso di segni discordi -- va invece usata l'uscita segno(T) > segno(M), attiva quando T < 0 e M >= 0.

(7) Visto che lei suppone di avere in ROM le temperature di soglia, perche' mai allora mandare alla CPU le richieste di spegnimento e di accensione, anziche' risolverle direttamente in hardware? E' sufficiente usare un flip-flop per ciascun elemento riscaldante, forzarlo in ON al posto dell'invio di una "richiesta di accensione", forzarlo in OFF in presenza di una "richiesta di spegnimento", e lasciarne lo stato immutato se la temperatura letta e' compresa nel range definito dalle due soglie M, N.

(8) In ogni caso, mai una singola interfaccia invia due distinte richieste di interrupt. Qualora occorra discriminare tra due diverse cause di richiesta, e' sufficiente inviare un diverso Interrupt Vector Number per ciascuna possibile richiesta. Le faccio anche notare che la porta OR tra l'uscita Q e l'ingresso D del flip-flop puo' essere eliminata sostituendo il flip-flop D con un flip-flop JK avente l'ingresso K fisso a 0 e l'ingresso J connesso alla sorgente della richiesta.

Lei chiede inoltre:

"1) So che è possibile modificare un Ck usando i contatori, ma non ho mai visto usare un contatore mod 5/16. E' utilizzabile? Se non lo è come avrei potuto crearmi un Ck con sedici colpi in 5 secondi?"

Un'alternativa a questo dilemma l'abbiamo gia' vista alla voce (1). D'altra parte, (5/16) * 10^8 = 31250000 = (5 * 2^8 * 5^8) / (2^4) = (5^9 * 2^4), e dunque basta utilizzare una cascata di 9 contatori mod 5 seguita da un contatore mod 16.

"2) La parte di interrupt la applico un po’ meccanicamente in base a quello che ho capito a lezione. Tuttavia ci sono casi in cui mando i segnali di richiesta di interruzione (nel mio caso Ric1 e Ric2)anche alla porta and che pilota il tri-state e casi in cui non va a pilotare tale porta. Quando si deve mandare in questa and del tri-state e quando no?"

Abbiamo gia' visto che la CPU, date le premesse, puo' benissimo non intervenire affatto nel processo. In ogni caso, mai condizionare le porte AND tra IORD e SEL con alcunche': se vogliamo impedire alla CPU di leggere il dato, ovviamente non ci riusciamo -- la CPU va a leggere a proprio piacimento; d'altra parte, se va a leggere quando il dato non e' ancora pronto, che legga un dato fasullo o che legga cio' che trova su un bus non pilotato da un tri-state attivo (che e' un dato altrettanto fasullo), e' evidentemente del tutto irrilevante.

(2) L'addizione (+1) e la sottrazione (-1) possono piu' semplicemente essere realizzate in questo modo:

addizione (+1) Cin = 1, secondo operando = 0000...0
sottrazione (-1) Cin = 0, secondo operando = 1111...1

In tal modo, basta negare Cin e mandare il risultato su tutti i bit del secondo operando, e il valore di Cin determina se vogliamo eseguire l'addizione o la sottrazione: un solo invertitore al posto di 20 porte XOR.

Per il resto, nient'altro di significativo da eccepire.

Non c'e' ragione di accorpare le tre porte di input in una sola: basta usare contatori con uscita tri-state, e in piu' si risparmia al softare la fatica di disassemblare i tre dati (cosa che comporta operazioni di And e Shift).

Analogamente per le porte di input: perche' richiedere alla CPU di assemblare i due dati in uno solo, quando noi cosi' risparmiamo solo una porta And?

Il multiplexer a due vie con un ingresso fisso a zero, non puo' essere semplifcato in una sola porta?

2006-07-15
==========

A cosa serve il blocco in ingresso col simbolo "="? e il flip-flop che lo segue?

I multiplexer all'uscita dei comparatori non servono, basta mandare le opportune uscite dai comparatori agli ingressi di Enable dei rispettivi registri.

Stesso discorso di cui sopra per le porte di input.

(2) Il contatore down mod 8 e' inizializzato male: appena gli si da' il Clear, le uscite vanno a zero, forzano a zero il Count Enable e inibiscono cosi' ogni ulteriore conteggio. (Questo tuttavia non implica che sia scorretto disabilitare un contatore tramite una decodifica delle sue uscite: e' solo che la cosa va fatta con attenzione.) Nel caso di un contatore down, poi, il TC e' esatamente la decodifica di tutte le uscite uguali a zero.

(3) Il registro finale, dal quale si preleva il risultato, andrebbe inibito al caricamento alla fine del calcolo, altrimenti il suo contenuto cambiera' ad ogni clock.

(4) Poiche' in floating point lo "0" coincide con 0000...00, anziche' usare un multiplexer per forzare la costante 0 si poteva mandare un clear al registro stesso.

Per il resto, abbastanza bene.

(1) Il circuito per generare un segnale con durata di un singolo periodo di clock puo' essere semplificato come segue (se l'impulso, come in questo caso, ha durata sicuramente maggiore del periodo di clock): impulso applicato all'ingresso di uno shift register a due bit, And tra Q del primo flip-flop e Q* del secondo flip-flop.

(2) Come e quando vengono azzerati i quattro contatori di monete?

(3) Visto che le monete vengono inserite sicuramente una per volta, non sarebbe stato piu' economico usare un registro accumulatore per gli importi, con un unico sommatore a due operandi, uno dei quali e' il registro stesso e l'altro l'uscita dalla ROM o dal contatore selezionata dall'impulso in arrivo?

(4) Manca la parte relativa all'invio del credito cumulativo alla stampante.

(5) A rigore, i dati alla stampante non dovrebbero essere inviati in formato binario ma come codici ASCII, ma non so se questa era anche l'intenzione di chi ha steso il testo del progetto.

2005-06-27
==========

(1) La RAM deve essere condivisa con la CPU; mancano tuttavia i rlativi circuiti di interfaccia al System Bus.

(2) Gli ingressi D del registro in alto a sinistra, a cosa sono connessi? (Non lasciate mai fili penzolanti nel vuoto!!!) A cosa serve il successivo registro connesso alle sue uscite?

(3) Perche' manda VAL-1, e non VAL, al comparatore per la verifica di fine scansione?

(4) Troppi flip-flop: basta bloccare il contatore quando D=1 oppure quando Count=VAL.

(5) Visto che l'indirizzo base della RAM e' 80000000h, l'indirizzo del vettore di test da inviare alla CPU sara' 80000000h + Count*2; poiche' Count non puo' essere superiore a 1 M = 00100000h, questa operazione puo' essere eseguita senza fare ricorso a un addizionatore, basta disporre opportunamente i bit di Count e forzare il bit 31 a 1.

1) Quali aspetti e quali argomenti Lei ritiene che debbano essere maggiormente approfonditi dallo studente per avere una buona preparazione? Quelli citati nel diario delle lezioni, quelli del programma, entrambi?

Sicuramente quelli citati nel diario delle lezioni.

2) Quali argomenti riguarderanno strettamente le prove d'esame? Quelli del diario delle lezioni, quelli del programma, entrambi?

Sicuramente quelli citati nel diario delle lezioni.

3) A lezione Lei ha riservato ampio spazio alle famiglie logiche e alle varie tecnologie di implementazione (RTL, TTL, ECL, ecc.). Poichè tali argomenti richiedono, se approfonditi, una considerevole quantità di studio e poichè negli appelli degli anni passati mi sembra non siano quasi mai comparsi come prove d'esame, vorrei sapere quanto ritiene debbano essere curati questi aspetti e con quale livello di dettaglio si devono imparare e/o memorizzare i dettagli, sia in relazione alle prove d'esame ma soprattutto in funzione della preparazione dello studente.

Beh, lo spazio riservato non e' stato poi cosi' ampio. Mi e' sembrato che avere una conoscenza anche minima di come e' realmente costituita una porta, potesse servire come criterio per valutare con cognizione di causa fenomeni come i ritardi di propagazione, i tempi di commutazione, e cosi' via. Peraltro, mai le tecnologie di implementazione costituiranno, di per se', tema d'esame.

Per quanto riguarda invece i dispositivi di uscita (che chiameremo genericamente "attuatori", e che possono essere elementi riscaldanti, comandi di movimento per motori, convertitori digitale-analogici per la generazione di segnali vocali o musicali, etc.) useremo sempre un registro di uscita in cui immagazziniamo il codice digitale da emettere in modo che rimanga stabile fino al momento in cui emetteremo un nuovo codice.

Ho trovato ricorrente una richiesta negli esercizi degli esami del 2005, ovvero quella di determinare la massima frequenza di lavoro di un sistema SCA/SCO di tipo (e.g.) Mealy/D-Mealy in funzione dei tempi caratteristici dei componenti delle due reti.

A lezione, Lei ci ha mostrato come calcolare la frequenza massima di lavoro di due (o più) componenti SCO in serie solamente, è corretto?

E' corretto in parte, nel senso che quella che ho mostrato era l'interconnessione di una SCO e di una SCA che (accidentalmente) avevano strutture simili se non identiche. In realta', e mi pare di averlo anche sottolineato a lezione, il calcolo della frequenza massima di lavoro si esegue sempre secondo lo stesso criterio: una volta definita la struttura di ciascuna delle due (o tre, o N) componenti, si elencano tutti i possibili percorsi dall'uscita di ogni registro all'ingresso di ogni registro, per ogni percorso si calcolano i tempi di transito dei segnali, e la frequenza massima di lavoro deve essere tale che il suo periodo sia identico al MASSIMO tra quei tempi di transito. Ovviamente, tale criterio vale anche se, come SCO, lei utilizza una delle strutture speciali di SCO che abbiamo visto a lezione al posto di una generica macchina di Mealy o di Moore.

Se sì, all'esame dobbiamo essere in grado di rispondere alla richiesta di cui sopra comunque oppure no?

A questo punto, direi proprio di si'. D'altra parte, sia sul libro di testo, sia sugli appunti del Prof. Chiari, sia nelle soluzioni dei temi d'esame ci sono esempi esaustivi in proposito.