(2) Occorre indicare con chiarezza *quale* bit di uscita dal SIPO e'connesso a *quale* bit dell'ingresso dati del FIFO. In mancanza di altre indicazioni, io interpreto che l'uscita Q0 del SIPO e' connessa al bit D0 dell'ingresso dati del FIFO, l'uscita Q1 all'ingresso D1, e cosi' via, con tutte le (possibili) conseguenze del caso. Questa raccomandazione vale, ovviamente, per OGNI progetto.

(3) Non si puo' attestare cosi' un registro a 64 bit sull'I/O Data Bus del PD-32, che e' a soli 32 bit; esso deve necessariamente essere suddiviso in due registri da 32 bit da caricare con due distinti cicli di Output, e di conseguenza occorre utilizzare due SEL distinti.

(4) Sarebbe stato piu' economico realizzare il multiplexer per i 64 bit utilizzando 8 registri da 8 bit con uscita tri-state e un decoder (v. figura allegata).

0612082300-1.pdf

(5) Dal testo sembra di capire che anche in uscita i bit crittografati delle parole in uscita debbano essere invertiti. Il disegno sembra indicare che il bit 0 del PISO sia il primo a uscire; in tal caso, le connessione agli ingressi paralleli del PISO andrebbero invertite.

(6) Lei ha assunto che SYNC_IN abbia durata inferiore a un periodo di clock. E' piu' ragionevole assumere che, oltre ad essere sincronizzato col clock stesso, abbia durata pari a un singolo periodo di clock (se lei avesse dovuto generarlo, l'avrebbe generato cosi'!) Con questa ipotesi, dunque, SYNC_IN non puo' essere mandato al Clear del contatore (e comunque a nessun ingresso di controllo di tipo asincrono) poiche' il suo effetto avrebbe durata di due clock. Meglio sarebbe usare a questo punto un Clear sincrono o anche l'ingresso sincrono di Parallel Load.

(7) Come la scrittura, anche la lettura da un FIFO e' di tipo asincrono. Lei non puo' lasciare attivato l'ingresso OE (che meglio dovrebbe chiamarsi RD, Read Enable) del FIFO costantemente attivo, e sperare cosi' che i dati in uscita cambino esattamente nei momenti che fanno comodo a lei! Il dato dal FIFO va letto con un impulso sul RD (il cui fronte finale, come sappiamo, aggiorna i puntatori interni) e l'informazione va allora catturata su un registro se deve essere utilizzata anche quando il RD è tornato inattivo.

(8) Manca un meccanismo per l'identificazione del termine delle operazioni. Che cosa fare in questa circostanza, in assenza di specifiche in merito, e' lasciato a discrezione del progettista: per esempio, possono essere emessi in uscita degli zeri.

Per via dei punti (6) e (7), la temporizzazione andrebbe rivista, e di conseguenza anche i circuiti di controllo.

Perchè dice che lascio l'ingresso RD costantemente attivo?? Mi sembra che rimanga attivo esattamente per un ciclo di ck, in modo ritardato rispetto a TCcounter1, e questo mi da modo di calcolare le uscire dallo XOR e memorizzarle nel piso al prossimo ciclo. Dove è che sbaglio???

C'e' qui un equivoco di fondo: poiche' l'emissione del messaggio crittografato deve iniziare quando il messaggio originale e' arrivato nella sua interezza, le operazioni di lettura devono essere totalmente svincolate sia da cio' che accade sulla linea di ingresso dati (che non proviene, come le ho gia' detto, dall'I/O Bus ma dal mondo esterno, cosi' come SYNC_IN e CK) sia da cio' che accade su SYNC_IN stesso, che puo' arrivare subito come dopo mezz'ora o mai piu' -- in altri termini, se probabilmente e' lecito usare lo stesso clock sia per il messaggio di ingresso che per quello di uscita, sicuramente lei non puo' usare lo stesso contatore Counter1 sia per le operazioni di scrittura in FIFO che per le operazioni di lettura. (Pensi un attimo, se per una qualche ragione non arrivassero piu' SYNC_IN, che nel suo progetto appaiono come Start, lei non porterebbe mai a termine la crittografatura! E allora a che servirebbe avere un FIFO?)

----

Mi deve scusare, la mia risposta era ancora relativa al primo progetto che le ho mandato, non alla correzione. Quanto a quest'ultima:

(1) La scrittura in FIFO e la lettura da FIFO continuano ad essere asservite entrambe a SYNC_IN, e come le ho detto prima questo e' inammissibile. Le due sezioni, di scrittura al FIFO e di lettura dal FIFO, devono essere *completamente* indipendenti l'una dall'altra; la lettura e la generazione del messaggio devono iniziare quando il FIFO e' pieno, senza alcun'altra dipendenza.

(2) La generazione di SYNC_OUT e' di conseguenza sbagliata, perche' la durata del relativo impulso dipende da quando dura lo stato di "coda piena", il quale a sua volta dipende da quando viene eseguita la prima lettura da FIFO, la quale a sua volta dipende da quando arriva il primo SYNC_IN dopo "coda piena".

(3) Lei usa una logica contorta (multiplexer, flip-flop, porte...) per generare lo 0 continuo alla fine del messaggio di uscita. Ogni shift register, anche un PISO, ha anche un ingresso seriale SerialIn: non e' piu' semplice applicare uno 0 a quest'ingresso, evitare che alla fine del messaggio il PISO riceva altri Load Enable, e lasciare che lo shift register si riempia da solo di zeri verso l'uscita?

(2) Il contatore dei coefficienti non viene mai resettato!

(3) Il contatore down riceve un LOAD che dovrebbe terminare quando esso raggiunge TC. Ma se sta forzato in Load, non raggiungera' mai TC!

(4) Il registro di uscita non ha Enable, dunque si modifica in continuazione.

(5) All'inizio delle operazioni, il registro del Moltiplicatore/Addizionatore va necessariamente azzerato. Non si capisce inoltre come faccia ad entrare nella sommatoria il termine a0, a meno che il modulo Power (di cui peraltro non viene fornito il progetto) non generi un valore 1.

(6) Lei comincia a utilizzare i coefficienti a partire dal piu' significativo, il che significa che il modulo Power dovrebbe generare per prima cosa X elevato al piu' alto esponente richiesto, al ciclo successivo dovrebbe generare la potenza per un esponente inferiore, e cosi' via. Comunque sia progettato il modulo Power, non sarebbe stato piu' facile generare le potenze di X per esponenti crescenti?

(7) Il modulo Power, comunque sia strutturato, richiede almeno un moltiplicatore, il che contraddice i vincoli imposti dal testo.

1) Vorrei capire a fondo il funzionamento di determinati segnali; prendendo ad esempio il contatore, come si utilizzano esattamente TC, LE, CLR? Cioè, come viene generato il TC?

Il TC viene generato semplicemente decodificando il conteggio terminale del contatore: in un contatore up modulo N, esso sara' la decodifica del conteggio N-1; in un contatore down modulo N, esso sara' la decodifica del conteggio 0, qualunque sia N.

Il TC puo' essere o meno condizionato al CE (Count Enable) del contatore. (Nei contatori reali disponibili in commercio, spesso esistono due CE, ad uno solo dei quali il TC e' condizionato; il contatore e' abilitato al conteggio solo se entrambi i due CE sono attivi.) Questa proprieta' e' legata all'uso che si fa del TC. Ad esempio, se vogliamo connettere due o piu' contatori in cascata, collegheremo il TC di ogni contatore al CE del contatore successivo -- ma in tal caso, per il corretto funzionamento del tutto, il TC di ogni contatore deve esere condizionato al proprio CE. Se invece vogliamo usare il TC per bloccare il contatore una volta che esso e' arrivato al massimo conteggio, allora connettiamo il TC negato al CE -- ma in tal caso e' evidente che TC non deve essere condizionato al CE, altrimenti il loop CE - TC - invertitore - CE entrerebbe in oscillazione!

Posso assumere che esso resta alto per tutto il periodo il cui il contatore è nell'ultimo stato?

Certamente, essendo appunto la decodifica di un particolare conteggio.

Ma, essendo un segnale 'sporco' per cosa posso usarlo effettivamente?

Ad esempio per inviarlo all'Enable di un registro D, o al Count Enable di un altro contatore, perche' in questi casi il segnale viene campionato solo all'arrivo del clock, e dunque si spera che nel frattempo il TC si sia assestato.

LE è un segnale sincrono, quindi potrei mandare il TC nell'ingresso di LE senza aver problemi?

Nei contatori commerciali LE si trova sia sincrono che asincrono, senza una netta prevalenza dell'uno o dell'altro. Per questa ragione, e' bene specificare *sempre* nei progetti quale caso si sta assumendo.

Il CLR invece, è sempre asincrono oppure può anche essere sincrono?

Normalmente e' asincrono; in rari casi, se la cosa ci puo' far comodo, possiamo assumere che sia sincrono. (E' opportuno specificare sempre, nel progetto, se ci troviamo in uno di questi "rari casi" oppure no.)

Poiché CLR è asincrono, mandare TC nel suo ingresso mi può creare problemi, giusto? Mi renderebbe instabile (di breve durata) l'ultimo stato del contatore, giusto?

Si', ma non e' detto che questo sia dannoso. Come ho fatto vedere a lezione nel caso generale, la decodifica di un conteggio M inviata al Clear asincrono consente di realizzare in maniera semplice un contatore di modulo M-1. Normalmente non ci sono problemi, salvo quando la frequenza di clock diventa eccessivamente alta e allora la durata di quello stato "instabile" diventa significativa.

Poiché il CE è sincrono, potrei usare tranquillamente il TC di un contatore per abilitare il CE di un altro contatore, giusto?

Esatto, ne abbiamo parlato anche sopra.

Può darmi dei consigli, delle 'dritte' (del tipo "cosa non fare mai..." o "quando conviene usare un determinato segnale...", ecc..), su come utilizzare al meglio i vari segnali sincroni e non?

Non e' facile dire, cosi' su due piedi. I segnali di controllo asincroni agiscono immediatamente, mentre quelli sincroni hanno effetto solo all'arrivo del clock; l'uno e l'altro effetto possono essere sia vantaggiosi che svantaggiosi, a seconda delle circostanze.

Un caso che mi sento di mettere in evidenza, perche' appare molto spesso ma altrettanto spesso viene trattato con superficialita', e' quello di un segnale della durata di un clock che viene applicato al Clear asincrono di un contatore per farlo ripartire (tipico segnale di Start). In questo caso c'e' da fare molta attenzione, poiche', se si analizza la situazione, si vedra' che lo stato 0 del contatore permane per *due* periodi di clock: non appena viene applicato il segnale, il contatore passa immediatamente a 0, poi arriva un clock e il segnale scompare subito dopo, e il contatore passera' al conteggio 1 soltanto dopo il prossimo clock!

2) Relativamente ai FF di tipo edge-triggered ed ai FF Latch: a parte il fatto che l'edge-triggered è sensibile solo sul fronte (salita o discesa) mentre il latch è sensibile su tutto lo stato di "1" del segnale di gate, ci sono altre differenze sostanziali?

No, non vi sono altre differenze sostanziali, non dal punto di vista logico, almeno.

In particolare, su quali tipi di connessioni viene preferito il latch all'edge-triggered e viceversa?

Il latch viene usato quando il segnale di caricamento non e' legato a un clock, oppure quando il clock a cui esso e' sincronizzato non e' disponibile. In tutti i casi in cui invece tale clock e' disponibile, e' raccomandabile usare il D-FF -- a meno che non sia necessario che il dato da catturare venga presentato immediatamente all'uscita. Tipicamente, il latch viene usato lato interfaccia; all'interno del circuito, dove tutto e' (o dovrebbe essere) sotto il controllo del progettista, raramente vi sono ragioni per non usare il D-FF.

So che nei sistemi che progettiamo in questo corso utilizziamo un solo clock di tipo a fronte;

Non e' detto. Possono anche capitare (sono capitati) progetti che richiedono l'uso di due o piu' clock distinti.

i latch li usiamo come registri di interfaccia (data-buffer) con i microprocessori (solo per le periferiche di output del microprocessore, giusto?),

Beh, si', le porte di input (in uscita dall'interfaccia) sono sotto il nostro controllo, e dunque, come ho detto sopra, raramente vi sono ragioni per usare latch.

di cui si può utilizzare l'AND tra i segnali IOWR e SEL come ingresso di sincronizzazione (gate) del latch. L'uscita del latch può essere collegata all'ingresso di un registro interno allo SCA sincronizzato con il clock del sistema. C'è altro?

Direi di no.

3) Slide di Chiari, Parte 1 - Reti Combinatorie - slide 87: in riferimento ai due schemi a fondo pagina che implementano le due funzioni cablate, ho capito che si usano porte normali prive della resistenza, in quanto viene utilizzata un'unica resistenza di pull-up sul bus che è in comune per tutte le porte connesse al bus, ma: la prima figura sembra un NOR, ma accanto c'è scritto NOR CABLATO, OR CABLATO, AND CABLATO, perchè? la seconda sembra una funzione espressa come OR di AND e poi negata, ma accanto c'è scritto NOR CABLATO, OR CABLATO, AND CABLATO, perchè? Come funzionano esattamente queste funzioni 'cablate'?

Intanto qui sono buffer tri-state, un po' diversi dalle porte normali prive di resistenza (meglio: prive dello stadio di uscita superiore che forza il livello "1" sull'uscita). Il funzionamento di queste "porte" e' molto semplice:

(a) se l'abilitazione del singolo buffer tri-state e' a 1, allora il livello logico presente al suo ingresso viene trasferito sull'uscita;

(b) se l'abilitazione del singolo buffer tri-state e' a 0, allora il livello logico presente al suo ingresso e' irrilevante e la sua uscita (essendo ad alta impedenza) non da' alcun contributo al livello logico presente sull'uscita della "porta";

(c) se tutti buffer tri-state hanno i rispettivi Enable a 0, allora il livello di uscita viene determinato dalla tensione connessa al resistore di carico (che verra' chiamato di "pull-up" se la tensione e' positiva, e di "pull-down" se il resistore e' collegato a massa o a una tensione negativa)

Il comportamento della prima "porta", quella identificata come "NOR cablato", che ha buffer tri-state con ingressi a 0 e un resistore connesso a una tensione positiva, e' allora il seguente:

(a) se tutti gli Ei stanno a 0, allora l'uscita e' 1
(b) se almeno un Ei sta ad 1, allora l'uscita e' 0

che e' esattamente il comportamento di un NOR.

Il comportamento della seconda "porta", quella identificata come "OR cablato", che ha buffer tri-state con ingressi a 1 e un resistore connesso a una tensione negativa, e' invece il seguente:

(a) se tutti gli Ei stanno a 0, allora l'uscita e' 0
(b) se almeno un Ei sta ad 1, allora l'uscita e' 1

che e' esattamente il comportamento di un OR.

Il termina "cablato" significa che una particolare funzione logica di piu' ingressi viene realizzata semplicemente "cablando" tra di loro in parallelo le uscite di piu' circuiti.

4) Libro Reti Combinatorie.

A) Pag. 98, paragrafo III.3.5: dobbiamo studiare anche la logica steering dinamica? Se sì, come funziona?

No, non dobbiamo studiarla; non l'abbiamo fatta a lezione, dunque non si porta all'esame. (Peccato, era una cosa interessante...)

B) Pag. 115 [errate corrige?]: la seconda formula in questa pagina è la seguente:
    f1 = I1 + I3 ; f2 = yz + x ; f3 = I1 + I2
ma non dovrebbe essere:
f1 = I1 + I2 ; f2 = yz + x ; f3 = I1 + I3

E' esatto, c'e' evidentemente un errore di stampa.

C) Pag. 132, figura V.6 [errate corrige]: già le avevo mostrato questa figura ed avevamo appurato che gli indici non erano corretti; comunque gliela segnalo nuovamente nel caso in cui volesse correggerli per l'eventuale errata corrige.

La copia del testo che io ho e' quella temporaneamente cedutami dal Prof. Cioffi, che ha gia' apportato parecchie correzioni a matita sugli indici nella figura in questione. Purtroppo, questo comporta che non riesco a leggere le espressioni per gli indici prima della correzione, e leggo con difficolta' quelle dopo la correzione. Se potesse mandarmi una scansione a risoluzione relativamente alta della figura, posso vedere di mettere a posto la cosa.

D) Pag. 142 [errate corrige?]: Alla 3° riga non mi torna la frase "La struttura completa di un moltiplicatore 5 x 5 è riportata in fig. V.16." ... la figura V.16 non mostra un moltiplicatore 5 x 5 ....; inoltre la struttura non mi sembra completa...vedo solo il circuito per addizionare i prodotti parziali, ma non la matrice dei prodotti parziali...

Infatti, e' un generico moltiplicatore n x n.

5) Libro Reti Sequenziali.
A) Pag. 19 [errate corrige?]: relativamente alla seconda matrice in questa pagina, se ho capito bene  come funziona, all'incrocio (riga - colonna) B - C non dovrebbe essere 0 ?

Si', ma personalmente sono portato a ritenere che invece sia sbagliata la Fig. 1-13. Se ci fa caso, dallo stato A si esce con ingresso 0 sia verso lo stato B (con uscita 0) sia verso lo stato C (con uscita 1) -- il che e' impossibile (almeno per una macchina a stati finiti "deterministica"); la stessa cosa accade per lo stato C e l'ingresso 1 (e qui sono portato a ritenere che la freccia da C a B vada invertita, da cui segue che l'elemento della matrice delle adiacenze da lei citato abbia in realta' valore corretto). Temo che nella Fig. 1-13 manchi qualche transizione, e/o che l'etichetta o la direzione di qualche transizione sia sbagliata.

B) Pag. 21, prime 6 righe: non riesco a capire perché l'uscita per una macchina di Mealy è disponibile dopo un tempo Tw, mentre per una macchina di Moore è disponibile dopo un tempo Tdelta + Tw ...

Basta osservare la Fig. 1-15 (pag. 20) per rendersi conto che, in una macchina di Mealy, una variazione in ingresso si propaga all'uscita passando attraverso il blocco omega (da cui Tw); mentre in una macchina di Moore, una variazione in ingresso deve prima provocare un cambio di stato (Tdelta) ed e' poi quest'ultimo che si propaga attraverso il blocco omega (da cui l'ulteriore tempo Tw).

C) Pag. 40 [errate corrige?]: in riferimento all'ultima riga della pagina, dove si ha "...alla rete è diventato sk, la macchina passerebbe in si.", non dovrebbe essere "...alla rete è diventato sk, la macchina passerebbe in sj."?

Si', secondo la tabella 2-3 la transizione avverrebbe in sj.

Avete travisato un po' il testo originale, facendo in hardware anche tutto cio' che era previsto fosse svolto in software, ma meglio cosi' (in questo caso, eh!)

(1) Occorre economizzare sul multiplexer dei dati in ingresso, usando registri con uscita tri-state e un decoder per gli Output Enable.

(2) Volendo fare tutto in hardware, non e' piu' indispensabile catturare i valori di temperatura in un colpo solo e poi processarli uno per volta: e' sufficiente catturare il dato al momento di processarlo. In tal modo, il TC del contatore/timer dovra' solo resettare il contatore di canale, il quale dovra' autobloccarsi alla fine della scansione; questo consentira' di evitare altri circuiti di controllo.

(3) Il segnale per ciascun elemento riscaldante e' uno solo, non due: se sta a 0, l'elemento si spegne, se sta a 1 l'elemento si accende. Inoltre, tale segnale non puo' essere di tipo impulsivo, come appare dal vostro progetto: se decidiamo che un dato elemento riscaldante debba essere acceso o spento, tale stato dovra' persistere per i successivi 5 secondi -- in altri termini, ciascun elemento riscaldante deve essere pilotato da un flip-flop.

(4) Avendo cosi' tanto tempo a disposizione per la singola scansione, non e' giustificato l'uso di due comparatori; meglio usarne uno solo eseguendo prima uno dei test e poi l'altro.

(5) Volendo fare tutto in hardware, non e' giustificato l'uso di una ROM; meglio sarebbe usare una RAM che possa essere scritta dalla CPU e letta dall'interfaccia.

IFPTY
=====

(1) L'albero di XOR va disegnato.

(2) Non e' corretto usare l'uscita dell'albero di XOR come clock per il registro di uscita, meglio mandarla all'Enable del registro e XCLK al clok.

(3) L'uscita dal registro deve essere attestata sull'I/O Data Bus. Il pilotaggio dell'Output Enable non e' corretto: deve essere IORD*SEL2.

(4) Anche il pilotaggio dell'Output Enable per il contatore di errori e' scorretto: deve essere IORD*SEL1.

(5) La CPU deve avere un modo per azzerare il contatore di errori quando vuole procedere a una nuova acquisizione.

SERIN
=====

(1) A che serve un segnale di Load Enable in uno shift-register in configurazione SIPO?

(2) Cosi' com'e', il registro cattura dati ad ogni XCLK, mentre invece dovrebbe entrare in azione solo 12 clock dopo l'arrivo di XSYNC.

(3) La generazione dell'interrupt e' un po' troppo semplicistica...

Provate a fare le temporizzazioni di questo circuito, vedrete che le cose non sono cosi' semplici, soprattutto se ammettiamo la possibilita' che due XSYNC consecutivi siano separati anche soltanto da 12 clock.

SEROUT
======

(1) Il segnale IOWR*SEL0 che usate come Start potrebbe durare molto meno che non un singolo periodo di XCLK -- in particolare, potrebbe diventare attivo e poi inattivo quando "nessun" fronte di XCLK e' arrivato nel frattempo (il System Clock e XCLK sono del tutto incorrelati tra loro), nel qual caso il flip-flop non si setterebbe per nulla.

(2) Anche il contatore deve essere in qualche modo asservito allo Start; in particolare, deve ricontare 12 clock da quando questo arriva.

(3) Come fa la CPU a sapere se e' quando un dato e' stato completamente emesso, in maniera da poterne inviare un successivo?

IFKEY
=====

Mi riesce francamente difficile capire la logica che sta dietro alla ricerca (binaria, mi dite): c'e' un addizionatore/sottrattore che accetta un operando dallo shift register e l'altro da un registro, e la cui uscita finisce ancora sul registro. Ora, dato che il registro viene azzerato allo Start e che lo shift register viene inizializzato con 111...1, al primo passo il registro non puo' che essere caricato con 111...1, puntando quindi all'ultima locazione di ROM. Inoltre dite che ad ogni clock lo shift register presenta un valore che si dimezza ogni volta; l'operazione eseguita e' una somma se KEY > ROM_KEY, mentre e' una sottrazione se KEY < ROM_KEY.

Allora supponiamo di lavorare con una ROM da sole 8 locazioni, che contengono le seguenti chiavi

indirizzo  chiave
   0          3
   1          5
   2          9
   3         11
   4         16
   5         21
   6         33
   7         41

Supponiamo che la chiave cercata sia 33, che sta alla locazione 6. Lo shift register viene inizializzato con 111 (=7), e il registro con 0.

Passo 1) (ShiftReg=111) +- (Reg=000) = 111 (7) -> Reg;

Passo 2) 33 < ROM(7) -> sottrazione:
         (ShiftReg=011) - (Reg=111) = 100 (4) -> Reg

Passo 3) 33 < ROM(4) -> sottrazione:
         (ShiftReg=001) - (Reg=100) = 101 (5) -> Reg

Passo 4) 33 < ROM(5) -> sottrazione:
         (ShiftReg=000) - (Reg=101) = 011 (3) -> Reg

Passo 5) 33 < ROM(3) -> sottrazione:
         (ShiftReg=000) - (Reg=011) = 101 (5) -< Reg

e cosi' via all'infinito, poiche' ormai lo shift register e' pieno solo di zeri, e quindi continuera' ad emettere zeri.

Forse e' meglio che ridiate un'occhiata a questa soluzione.

(1) Il blocco "Parallel In Serial Out" che cos'e, e come fa a convertire una dato parallelo a 32 bit in 4 byte consecutivi con un solo colpo di clock (quello abilitato da SEL*IOWR)?

(2) Stesso discorso per il blocco "Serial In Parallel Out". Come fa ad essere "Serial In" se al suo ingresso ci sono 8 bit di dati?

(3) All'uscita dal "Serial In Parallel Out" lei butta via il bit di segno. Perche' mai? I dati in ingresso possono essere sia positivi che negativi!

(4) Non e' necessario multiplexare la costante "0" all'ingresso del registro accumulatore: basta usare un Clear asincrono, c'e' ampiamente tempo a disposizione per questa operazione prima di iniziare i calcoli.

(5) L'addizionatore floating-point e' completamente sbagliato: prima di eseguire l'addizione (o sottrazione, qualora i due operandi abbiano segni diversi) le mantisse vanno allineate mediante shift per riportarle "come se" avessero lo stesso esponente; una volta eseguita l'operazione sulle mantisse, il risultato va nuovamente shiftato per la normalizzazione finale, con contemporaneo incremento o decremento dell'esponente.

Esempio di addizione floating-point su numeri con 1 bit di segno, 7 bit di esponente (non polarizzato, per semplicita'), 24 bit di mantissa, normalizzazione e conseguente eliminazione del bit a 1 piu' significativo.

Supponiamo che gli operandi siano:

X = {0 0000110 [1.]001001001001001001001001 } =
  = (1 + 2396745 / 2^24) 2^6 = 1.142857134342193603515625 * 64 =
  = 73.142856597900390625

Y = {0 0000011 [1.]000000010010001101000101 } =
  = (1 + 74565 / 2^24) 2^3 = 1.004444420337677001953125 * 8 =
  = 8.035555362701416015625

Gli esponenti differiscono di 6 - 3 = 3, dunque la mantissa di Y va shiftata a destra di 3 posizioni (con perdita degli ultimi 3 bit di mantissa); solo adesso possiamo eseguire la somma:

1001001001001001001001001 +
0001000000010010001101000
---------------------------
1010001001011011010110001

Non avendo avuto overflow, il risultato e' gia' normalizzato, l'esponente del risultato e' 6 (l'esponente comune a cui abbiamo riportato entrambi gli operandi), e dunque il floating-point risultante e'

Z = {0 0000110 [1.]010001001011011010110001} =
  = (1 + 4503217 / 2^24)*2^6 = 1.268412649631500244140625 * 64 =
  = 81.178409576416015625

(Il risultato esatto avrebbe dovuto essere 81.178411960601806640625; ci ritroviamo un errore a partire dalla quinta cifra decimale, dovuto ai soli 24 bit di mantissa a disposizione.)

Se ci fosse stato overflow, o se (in caso di sottrazione) avessimo avuto una sequenza di bit iniziali a zero, avremmo dovuto nuovamente shiftare il risultato (e contemporaneamente aggiornare il suo esponente) in modo da avere il primo bit ad 1, che poi andra' eliminato nella rappresentazione normalizzata finale.

(2) Un FIFO e' tipicamente asincrono, ossia privo di clock (proprio perche' una delle sua applicazioni principali e' quella di "sincronizzare" dati che devono arrivare e uscire con clock diversi). In tal caso, la lettura dal FIFO deve essere di tipo impulsivo: non puo' mantenere fisso il Read Enable e sperare che il FIFO emetta i dati nel momento esatto e per la durata esatta richiesti dai circuiti che seguono.

(3) C'e' una reale necessita' del REG32 sotto ai quattro registri REG8 all'uscita dal FIFO, solo se lei riesce a sovrapporre nel tempo la sequenza di lettura dal FIFO con l'operazione in virgola mobile.

(4) Lei carica il registro di uscita al momento di arrivo di IACK. Tuttavia, non c'e' nessun meccanismo che blocchi le operazioni dei circuiti aritmetici al momento in cui viene processato l'ultimo dato e fino al momento di arrivo di IACK (in particolare, CONT1 continua a girare e a fornire LE1 all'accumulatore), per cui, se IACK tarda ad arrivare per un motivo qualunque, il registro di uscita verra' caricato con qualcosa di diverso dal risultato desiderato, che e' ormai andato perso!

(4) A ben leggere, il testo chiede di progettare anche l'addizionatore floating-point.

(posso anche togliere lo iack dal set del FF e lasciare solo il coda-piena)

Non sarebbe piu' semplice eliminare REG32 e catturare il risultato con il primo LE2 generato dopo "coda vuota"?

1) Relativamente al file ifrange.pdf : pagina 4, figura 4 => l'uscita del secondo comparatore non va presa da XGTY0 ?

Si', e' esatto.

2) Relativamente al file 061012sol.pdf (quello del progetto per il calcolo della FFT butterfly) :
A) pagina 5, figura 7 => nei progetti d'esame procedo sempre come in figura? Cioè, quello presentato è un modo standard di gestire le porte di output del PD32 relative alla periferica che vado a progettare?

Beh, e' abbastanza standard. L'alternativa di usare porte And con ingressi diretti e negati e' ovviamente corretta, salvo il fatto che nel "mondo reale", quando si scopre che l'interfaccia ha indirizzi che entrano in conflitto con quelli di altre interfacce, diventa complicato apportare modifiche. La soluzione con comparatore, invece, consente di modificare il circuito in un solo punto (la costante binaria, tipicamente realizzata con ponticelli o con interruttorini) per riallocare altrove l'intero blocco di indirizzi. Inoltre, l'uscita dal comparatore ci dice anche se sta avvenendo accesso a una qualunque delle porte dell'interfaccia, cosa che in determinate circostanze puo' far molto comodo.

B) pagina 8, figura 12 => la descrizione recita "..secondo le equazioni di Fig. 10.", ma non dovrebbe essere "..secondo le equazioni di Fig. 9." ?

Si', e' esatto.

C) pagina 10, figura 15 => la 3° riga della descrizione recita "..registri temporanei R1, R2, R3, R4.", ma non dovrebbe essere "..registri temporanei R1, R2, R4, R5." ?

Si', e' esatto.

D) pagina 11, figura 17 => la 5° riga della descrizione recita "..i circuiti di Fig. 16 e Fig. 16 possono..", ma credo che sia "..i circuiti di Fig. 15 e Fig. 16 possono.." .

Si', e' esatto.

E) pagina 13, figura 21 => la 4° riga della descrizione recita "..la fase 4 consiste sia del calcolo do XR..", ma è "..la fase 4 consiste sia del calcolo di XR.." .

Si', e' esatto.

F) pagina 16, figura 26 ; pagina 20, figura 31 =>
- perché alcuni segnali come ad esempio R2OE e R3OE nella fase 1 sono (don't care) ? Non sarebbe meglio metterli a 0 onde evitare problemi elettrici causati dal fatto che più registri accedono contemporaneamente allo stesso 'bus' ?

Perche' l'idea originale era quella di pilotare gli Output Enable dei registri con uscite di decoder, anziche' direttamente; in questo senso, il don't care si riferiva all'ingresso del decoder, e non all'Output Enable. Poi ho deciso che non era il caso di complicare (peraltro inutilmente) la cosa, ma il don't care e' rimasto. Ovviamente, MAI lasciare in don't care degli Output Enable...

- nella fase 4 non dovrebbe essere R1EN = 1 ?

Certamente.

- nella fase 7 non dovrebbe essere SUB = 0 ?

Si', come peraltro appare in Fig. 24, pag. 14.

G) pagina 17, figura 27 =>
- all'esame devo fare considerazioni del genere? Devo ipotizzare un tempo di clock per il processore e dei tempi di calcolo per i componenti più lenti e dividere la frequenza di clock se necessario?

In generale, no. Tuttavia, in presenza di componenti particolarmente lenti come nel nostro caso, e' opportuno, se non risolvere il problema, almeno far vedere nel progetto che la cosa non e' sfuggita...

- se ho capito bene come funziona il circuito in figura, il segnale IFCLK non dovrebbe essere preso all'uscita della porta AND e, cioè, quando il contatore conta 24 ?

In realta' in questo caso e' indifferente. Sia prelevando il segnale dalla porta AND che dall'uscita Q3 otteniamo un clock alla stessa frequenza, solo che nel primo caso il duty cycle (rapporto tra tempo di ON e periodo del segnale) sara' di 1/24, mentre nel secondo sara' di 8/24, ossia un po' piu' vicino al 50%. E' solo una questione di gusti, diciamo che detesto gli impulsi troppo stretti :-)

H) pagina 18, figura 28 => la 9° riga della descrizione recita "..la FSM nell stato di Ready, ...", ma è "..la FSM nello stato di Ready, ..." .

I) pagina 21, figura 33 => l'ultima riga dell'intestazione recita "..da zero nella locazione IFBY_FLAG.", ma credo che sia "..da zero nella locazione IFBFY_FLAG." .

L) pagina 22, figura 34 => la 5° riga del codice recita "..;Salvataggio del cntesto", ma è "..;Salvataggio del contesto" .

Ovviamente ha ragione. Scrivo sempre con gli spelling checker disabilitati (sono cosi' fastidiosi quando non si scrive letteratura...) e nella fretta di mettere in linea il tutto non ho revisionato a dovere il testo.

La ringrazio per la pazienza e l'attenzione che ha messo.

Le scrivo per inviarle un'immagine della figura V.6 (quella i cui indici sono sbagliati), pagina 132 del libro Reti Combinatorie come lei mi ha chiesto. La foto è in allegato.

Infatti, molti indici sono errati. Tra l'altro, mi pare che, almeno sulla copia che ho io, anche alcuni indici della Fig. V.5 siano sbagliati. Comunque, mi sono ricalcolato tutto, cercando anche di interpretare il testo relativo alle figure in questione che mi sembra un po' involuto. Le accludo in allegato un pdf con le mie conclusioni.

0612110033-1.pdf

Inoltre, c'era rimasto anche il dubbio a pagina 164 del libro Reti Sequenziali: nelle equazioni considera 2taucmax, mentre noi avevamo ragione di credere che fosse solo taucmax...

Se legge anche la parte iniziale della sezione, vedra' che l'assunzione che viene fatta e' che le reti veloci abbiano tempo di calcolo taucmax, mentre la rete lenta ha tempo di calcolo esattamente doppio, ossia 2*taucmax (nell'esempio, tali tempi vengono assunti rispettivamente a 50 e 100 nsec), e cosi' i conti tornano.

Un'altra domanda. Relativamente ad una domanda che le ho posto nella precedente e-mail la sua risposta è stata:

> Intanto qui sono buffer tri-state, un po' diversi dalle porte normali
> [...]

Ma io mi riferivo alla slide 87, mentre mi pare di aver capito che, nella sua risposta, lei si riferiva alla slide 89... Potrei dunque porle nuovamente la domanda su citata?

Ha ragione, sulla mia copia la numerazione delle pagine e' di difficilissima interpretazione. Allora, slide 87. Le varie dizioni si riferiscono al tipo di logica (positiva o negativa) utilizzata sugli ingressi e/o sull'uscita, ossia sull'interpretazione che diamo loro. Le ricordo che

Livello fisico   | Logica positiva Logica negativa
-----------------+-----------------------------------
      0          |      inattivo        attivo
      1          |       attivo        inattivo

(1) Se la logica e' positiva (livelli attivi alti) sia sugli ingressi che sull'uscita, allora la struttura si comporta come un NOR (almeno un ingresso attivo comporta uscita inattiva).

(2) Se la logica e' positiva sugli ingressi e negativa sull'uscita (livello attivo basso, per esempio su una linea di Interrupt Request) allora la struttura si comporta come un OR (almeno un ingresso attivo comporta uscita attiva).

(3) Se la logica e' negativa sugli ingressi e positiva sull'uscita, allora la struttura si comporta come un AND (almeno un ingresso inattivo comporta uscita inattiva).

A rigore, mancherebbe ancora il caso:

(4) Se la logica e' negativa sia sugli ingressi che sulle uscite, allora la struttura si comporta come un NAND (almeno un ingresso inattivo comporta uscita attiva).

Infine, in riferimento al libro Reti Sequenziali, pagina 21, prime 6 righe: ho compreso la sua spiegazione relativamente al perché l'uscita per una macchina di Mealy è disponibile dopo un tempo Tw, mentre per una macchina di Moore è disponibile dopo un tempo Tdelta + Tw, ma non mi torna ancora una cosa...e cioè, perché allora per la macchina di Moore non ho Tdelta + TM + Tw, dove TM è il tempo dell'elemento di memoria?

Attenzione ai simboli: d'ora in poi indico con Tdelta (col delta minuscolo) il tempo di calcolo del blocco "delta", con TM il ritardo del blocco M (che sul libro e' indicato con TDelta, con Delta maiuscolo) e con Tomega il tempo di calcolo del blocco "omega"). Lei mi chiede allora, citando il testo: "l'uscita per una macchina di Mealy e' disponibile dopo un tempo Tomega; per una macchina di Moore e' disponibile dopo un tempo TM + Tomega: perche' non dopo un tempo Tdelta + TM + Tomega?"

Concordo con lei. Tuttavia, sul testo, il tempo Tdelta non interviene mai, mentre dovrebbe intervenire, per esempio, nel passaggio di stato della macchina di Mealy, che dovrebbe a rigore avvenire dopo un tempo Tdelta + TM, e non dopo un tempo TM come asserisce il testo. La mia ipotesi e' che ci sia un'assunzione implicita Tdelta = 0.