Scusa, mi ero dimenticato il file della periferica.
|
Ciao Paolo,
ho implementato nel protocollo un bit di ENABLE ( slv_reg6(2) ) asserito dal processore quando ha finito di inviare tutti i blocchi. Mettendo questo ENABLE in AND con Hready otterremmo un segnale che è proprio quello che vuoi tu.
Ricapitolando:
0) Esegui il reset
1) Scrivi zero su ENABLE (in realtà è già zero dopo il reset)
2) Esegui l'Hreset
3) Carichi i blocchi dati come prima
4) Dopo l'ultimo blocco fai il polling sul bit "polling" (slv_reg5(0))
5) Quando "polling" è uno scrivi uno su ENABLE (quindi Hready può transire a uno)
6) Fai il polling su Hready
7) Quando Hready è uno leggi gli H e riporti ENABLE a zero (qundi Hready torna a zero)
Questa soluzione potrebbe risolvere tutti i problemi? Che ne dici?
In allegato ho messo il file modificato e il nuovo test_bench. Fammi Sapere!
Ciao!
Lorenzo
--- Ven 20/5/11, Paolo Palana <
> ha scritto:
Da: Paolo Palana <
>
Oggetto: Re: [EMBEDDED] domanda su comportamento slv_reg5
A: "Lorenzo Iafolla" <
>
Cc:
Data: Venerdì 20 maggio 2011, 14:22
2011/5/20 Lorenzo Iafolla <
" rel=nofollow target=_blank>MailScanner ha rilevato un possibile tentativo di frode proveniente da "it.mc1100.mail.yahoo.com"
>
|
Ciao Paolo,
da quanto capisco il comportamento di Hready (slv_reg5(1)) non ti piace...
possiamo modificare il codice in modo che sia più semplice scrivere il driver. Cos'è che non ti piace? |
Ciao Lorenzo,
in realta' non e' che non mi piace il comportamente di Hready, e' solo che il fatto che vada ad uno (il che equivarrebbe a dire "risultato pronto" giusto?) dopo il reset potrebbe (e dico potrebbe) causare delle letture spurie dal driver che sarebbero difficilmente gestibili.
|
il fatto che dopo il reset Hready vada ad uno o il tempo che rimane asserito dopo la sua asserzione? In particolare, durante le normali operazioni, dopo aver elaborato il primo blocco, quando preferiresti che torni a zero Hready? |
Questa frase mi fa sorgere un dubbio. Hready diventa uno alla fine dell'elaborazione di ogni blocco, oppure diventa 1 quando ha finito di elaborare tutti i dati che gli sono stato inviati? Cerco di spiegarmi meglio. Supponiamo di avere 2 blocchi di dati da elaborare. Leggendo la descrizione, decisamente precisa ed esaustiva, del comportamento del VHDL sembrerebbe che la procedura per comunicare i dati alla periferica e per leggere il risultato sia la seguente:
1. carico il primo blocco in RAM
2. scrivo 1 su EOB
3. faccio polling sul slave_reg5(0) per sapere quando la periferica puo' accettare un nuovo blocco
4. scrivo 0 su EOB
5. carico il secondo blocco in RAM
6. scrivo 1 su EOB
7. faccio polling sul slave_reg5(0) per sapere quando la periferica puo' accettare un nuovo blocco
8. scrivo 0 su EOB
9. faccio Polling su Hready e quando Hready=1 allora leggo i registri risultato
Adesso la domanda e': C'e' il rischio
di trovare Hready ad 1 al passo 9 prima che sia stata terminata l'elaborazione del secondo blocco?
Se posso esprimere una mia opinione, mi aspetto che un bit che segnali la disponibilita' di risultati rimanga ad 1 fino a quando non viene effettuata la lettura e poi sia il software a segnalare alla periferica l'avvenuta lettura e tale segnalazione dovrebbe riportare a 0 il bit. Questo principalmente perche' non si ha la certezza di quando un pezzo di codice va in esecuzione, quindi avere un bit che rimane alto per un certo periodo di tempo e poi da solo torna a zero espone al rischio che il sistema operativo non si accorga mai che il risultato e' pronto.
Buona giornata a tutti
Paolo
|
A presto,
Da: Paolo Palana <
" rel=nofollow target=_blank>MailScanner ha rilevato un possibile tentativo di frode proveniente da "it.mc1100.mail.yahoo.com"
>
Oggetto: [EMBEDDED] domanda su comportamento slv_reg5
A:
" rel=nofollow target=_blank>
Data: Venerdì 20 maggio 2011, 10:44
Salve a tutti, innanzi tutto volevo avvisare che ieri sera ho fatto il porting del codice VHDL di sha1_core per la scheda che ho a disposizione. In realta' e' stata una cosa semplice. E' stato sufficiente sostituire la dual port ram usata nella CustomFifo. Pensavo comunque, se siete d'accordo, di rendere disponibile sia il codice modificato di sha1_core che l'interfaccia avalon che spero di sviluppare nel fine settimana. A questo punto, pero', devo farvi un paio di domande sul comportamento del registro slv_reg5, in particolare sul bit 1. Allora! Simulando il dispositivo mi sono accorto che appena dato il comando di reset slv_reg5(1) va a 1. Dopo aver dato il comando di reset scrivo 1 e poi 0 su slv_reg6(1) e poi asserisco il bit EOB. Il bit slv_reg5(1) rimane ad 1 fino a 22 cicli di clock dopo aver asserito il bit EOB. Il bit di polling, nel frattempo, passa ad 1 19 cicli di clock dopo aver asserito il bit EOB (questo suppongo
significhi che la periferica e' pronta per ricevere un nuovo blocco di dati) e rimane asserito, insieme a reset slv_reg5(1), per due cicli di clock. Successivamente slv_reg5(1) passa a 0, mentre il bit di polling rimane a 1 fino a quando non scrivo 0 sul bit EOB. Quando sui quattro registri di output appare il risultato dello sha1 il bit slv_reg5(1) diventa 1 (e questo suppongo significhi che e' possibile leggere i dati dalla periferica). Il bit slv_reg5(1) non dovrebbe diventare uno solo ed esclusivamente in corrispondenza dell'output vero e proprio dei dati? Potreste anche fornirmi, se possibile, delle coppie (input, output) che avete usato durante le vostre simulazioni? Grazie mille Paolo -- Paolo Palana, PhD Student <
" rel=nofollow target=_blank>
> Dept. of Computer Science,
Systems, and Industrial Engineering University of Rome "Tor Vergata", Via del Politecnico, 1 - 00133 Rome office: D1 - 21 phone : +39 06 7259 7714
| -- Paolo Palana, PhD Student <
" rel=nofollow target=_blank>
> Dept. of Computer Science, Systems, and Industrial Engineering University of Rome "Tor Vergata", Via del Politecnico, 1 - 00133 Rome office: D1 - 21 phone : +39 06 7259 7714
|
2011/5/20 Lorenzo Iafolla <
" rel=nofollow target=_blank ymailto="mailto:
">MailScanner ha rilevato un possibile tentativo di frode proveniente da "it.mc1100.mail.yahoo.com"
>
|
Ciao Paolo,
da quanto capisco il comportamento di Hready (slv_reg5(1)) non ti piace...
possiamo modificare il codice in modo che sia più semplice scrivere il driver. Cos'è che non ti piace? |
Ciao Lorenzo,
in realta' non e' che non mi piace il comportamente di Hready, e' solo che il fatto che vada ad uno (il che equivarrebbe a dire "risultato pronto" giusto?) dopo il reset potrebbe (e dico potrebbe) causare delle letture spurie dal driver che sarebbero difficilmente gestibili.
|
il fatto che dopo il reset Hready vada ad uno o il tempo che rimane asserito dopo la sua asserzione? In particolare, durante le normali operazioni, dopo aver elaborato il primo blocco, quando preferiresti che torni a zero Hready? |
Questa frase mi fa sorgere un dubbio. Hready diventa uno alla fine dell'elaborazione di ogni blocco, oppure diventa 1 quando ha finito di elaborare tutti i dati che gli sono stato inviati? Cerco di spiegarmi meglio. Supponiamo di avere 2 blocchi di dati da elaborare. Leggendo la descrizione, decisamente precisa ed esaustiva, del comportamento del VHDL sembrerebbe che la procedura per comunicare i dati alla periferica e per leggere il risultato sia la seguente:
1. carico il primo blocco in RAM
2. scrivo 1 su EOB
3. faccio polling sul slave_reg5(0) per sapere quando la periferica puo' accettare un nuovo blocco
4. scrivo 0 su EOB
5. carico il secondo blocco in RAM
6. scrivo 1 su EOB
7. faccio polling sul slave_reg5(0) per sapere quando la periferica puo' accettare un nuovo blocco
8. scrivo 0 su EOB
9. faccio Polling su Hready e quando Hready=1 allora leggo i registri risultato
Adesso la domanda e': C'e' il rischio
di trovare Hready ad 1 al passo 9 prima che sia stata terminata l'elaborazione del secondo blocco?
Se posso esprimere una mia opinione, mi aspetto che un bit che segnali la disponibilita' di risultati rimanga ad 1 fino a quando non viene effettuata la lettura e poi sia il software a segnalare alla periferica l'avvenuta lettura e tale segnalazione dovrebbe riportare a 0 il bit. Questo principalmente perche' non si ha la certezza di quando un pezzo di codice va in esecuzione, quindi avere un bit che rimane alto per un certo periodo di tempo e poi da solo torna a zero espone al rischio che il sistema operativo non si accorga mai che il risultato e' pronto.
Buona giornata a tutti
Paolo
|
A presto,
Da: Paolo Palana <
" rel=nofollow target=_blank ymailto="mailto:
">MailScanner ha rilevato un possibile tentativo di frode proveniente da "it.mc1100.mail.yahoo.com"
>
Oggetto: [EMBEDDED] domanda su comportamento slv_reg5
A:
" rel=nofollow target=_blank ymailto="mailto:
">
Data: Venerdì 20 maggio 2011, 10:44
Salve a tutti, innanzi tutto volevo avvisare che ieri sera ho fatto il porting del codice VHDL di sha1_core per la scheda che ho a disposizione. In realta' e' stata una cosa semplice. E' stato sufficiente sostituire la dual port ram usata nella CustomFifo. Pensavo comunque, se siete d'accordo, di rendere disponibile sia il codice modificato di sha1_core che l'interfaccia avalon che spero di sviluppare nel fine settimana. A questo punto, pero', devo farvi un paio di domande sul comportamento del registro slv_reg5, in particolare sul bit 1. Allora! Simulando il dispositivo mi sono accorto che appena dato il comando di reset slv_reg5(1) va a 1. Dopo aver dato il comando di reset scrivo 1 e poi 0 su slv_reg6(1) e poi asserisco il bit EOB. Il bit slv_reg5(1) rimane ad 1 fino a 22 cicli di clock dopo aver asserito il bit EOB. Il bit di polling, nel frattempo, passa ad 1 19 cicli di clock dopo aver asserito il bit EOB (questo suppongo
significhi che la periferica e' pronta per ricevere un nuovo blocco di dati) e rimane asserito, insieme a reset slv_reg5(1), per due cicli di clock. Successivamente slv_reg5(1) passa a 0, mentre il bit di polling rimane a 1 fino a quando non scrivo 0 sul bit EOB. Quando sui quattro registri di output appare il risultato dello sha1 il bit slv_reg5(1) diventa 1 (e questo suppongo significhi che e' possibile leggere i dati dalla periferica). Il bit slv_reg5(1) non dovrebbe diventare uno solo ed esclusivamente in corrispondenza dell'output vero e proprio dei dati? Potreste anche fornirmi, se possibile, delle coppie (input, output) che avete usato durante le vostre simulazioni? Grazie mille Paolo -- Paolo Palana, PhD Student <
" rel=nofollow target=_blank>
> Dept. of Computer Science,
Systems, and Industrial Engineering University of Rome "Tor Vergata", Via del Politecnico, 1 - 00133 Rome office: D1 - 21 phone : +39 06 7259 7714
| -- Paolo Palana, PhD Student <
" rel=nofollow target=_blank ymailto="mailto:
">
> Dept. of Computer Science, Systems, and Industrial Engineering University of Rome "Tor Vergata", Via del Politecnico, 1 - 00133 Rome office: D1 - 21 phone : +39 06 7259 7714 |