Riguarda come i registri sono collegati al bus:

  if wb_cyc = '1' and wb_stb = '1' then - accedendo al registro se wb_we = '1' then - iscritto al registro? my_reg < = wb_dat_i; - aggiorna il contenuto del registro altro - leggendo dal registro wb_dat_o < = my_reg; - restituisci il contenuto del registro end if; end if;  

Se tralasci la parte dell'hardware che può leggere il registro, il tuo registro è di sola scrittura. Allo stesso modo, se si tralascia la parte dell'hardware che può scrivere nel registro, allora è di sola lettura.

A volte ha senso avere solo una "direzione" del flusso di dati. Pensa a un DAC o un percorso dati ADC.

Inoltre, a volte ha senso che lo stesso indirizzo restituisca qualcosa di diverso dai dati che hai scritto su di esso. Pensa ai microcontrollori più comuni; le loro periferiche tendono ad avere un unico indirizzo che è un "comando" per le scritture e uno "stato" per le letture.

Un altro esempio sono i flag di interrupt: leggi il registro degli interrupt per vedere quale periferica ha interrotto il programma , quindi scrivi un "1" sullo stesso bit per cancellare il flag di interruzione. Un modo per rendersene conto è il seguente:

  wb_dat_o < = (others = > '0'); if wb_cyc = '1' and wb_stb = '1' then - register access if wb_we = '1' quindi - scrivi nel registro? clear_int < = wb_dat_i (0); altro - leggere dal registro? clear_int < = '0'; wb_dat_o < = esecuzione di & int_enabled & int_active; end if; end if;  

Qui puoi vedere che sto impostando un flag su qualunque cosa si trovi nella posizione del bit 0 nel caso di scrittura (e non mi interessa di qualunque altra cosa possano aver scritto), mentre nel caso di lettura sto costruendo una parola di stato composta da singoli bit che la periferica sta guidando.

a parte: sto anche mantenendo esplicitamente clear_int a zero nel caso di lettura. È solo una buona pratica di codifica assicurarsi che tutti i segnali siano assegnati in tutti i percorsi di codice in HDL. Nella migliore delle ipotesi, non farlo rende il codice sciatto. Nel peggiore dei casi puoi dedurre latch. Nota che faccio qualcosa di simile con wb_dat_o prima ancora di inserire il caso di accesso al registro.

Tieni presente che questi sono solo esempi per illustrare il punto e che un testo ben scritto programma verrà descritto più attentamente e approfonditamente. Tieni anche presente che sono le 8 del mattino qui e non ho ancora preso il caffè. :-)

Immagino tu stia parlando di registro in qualche parte periferica, parte del chip del processore o collegato ad esso in qualche modo.

In un registro di sola lettura i dati provengono da alcuni esterni (dal punto di vista del processore) e l'hardware associato, come la ricezione di dati seriali da parte di una UART. Quindi l'hardware si collega all'ingresso di te FF e le sue uscite si connettono (ad esempio) al bus del processore.

Per un registro di sola scrittura la situazione è inversa, il processore si collega (direttamente o indirettamente) al Gli ingressi di FF e le uscite di FF si collegano ad alcuni circuiti esterni. Un esempio è un convertitore da digitale ad analogico.

Una cosa che ti suggerirei di provare a fare, sebbene purtroppo molti progetti non lo facciano in modo coerente, è di dividere i registri scrivibili in categorie "latching" e "action", con l'aspettativa che la lettura di un registro latch sempre restituisce il valore scritto, mentre una lettura dell'indirizzo di un registro di azioni dovrebbe essere considerata come la lettura di un registro di sola lettura indipendente.

Ad esempio, supponiamo che il tuo sistema abbia otto latch che rilevare eventi esterni. Se questi latch si trovano in un registro a 8 bit che può essere letto o scritto direttamente dalla CPU, o che può essere impostato esternamente in modo asincrono, se il codice utente osserva che i bit 0 e 2 sono impostati (il che significa che il registro legge 0x05) e desidera per azzerare il bit 0 lasciando impostato il bit 2, provare a scrivere 0x04 nel registro proprio come un evento farebbe impostare un altro bit avrebbe lo sfortunato effetto di cancellare il latch associato a quell'altro evento, facendolo perdere . Se invece si avesse un indirizzo di "lettura" che riporta lo stato dei latch, un indirizzo di "scrittura zeri" che consente di cancellare i bit selezionati, ed eventualmente un indirizzo di "scrittura" che consente di impostare i bit selezionati, allora questi problemi non si verificherebbe.

Per le cose che la CPU dovrebbe effettivamente controllare (invece di prendere semplicemente nota - come nel caso dei flag di interrupt), ma dove la capacità della CPU di controllarle può essere limitata da fattori esterni, si dovrebbe separare ciò che la CPU richiede da ciò che è in grado di fare. Ad esempio, se si suppone che un'uscita di controllo del motore venga disattivata in modo asincrono da un ingresso esterno di "spegnimento del motore", quell'ingresso non dovrebbe semplicemente cancellare il blocco dell'uscita "controllo del motore" impostato dalla CPU. Invece, la CPU dovrebbe avere un latch che dice se vuole che il motore sia acceso e quel latch non dovrebbe essere modificato da fattori esterni. Un secondo latch attivato dall'esterno dovrebbe indicare se è arrivato un segnale di arresto del motore; l'uscita del motore dovrebbe quindi essere pilotata solo quando la richiesta della CPU dice "go" e il latch "shutdown" non è scattato, consentendo così alla CPU di avere "comandi" separati per "avviare questo dispositivo che aveva precedentemente richiesto di essere spento, presumendo che non esista alcun errore "e" riconoscere / cancellare la condizione di errore ".

Progettare l'hardware per separare ciò che il computer richiede da ciò che l'hardware esterno è attualmente autorizzato a fare non dovrebbe essere difficile, e tenere queste cose separate per principio aiuterà a evitare bug che possono verificarsi quando la CPU, nel tentativo di scrivere una cosa, scrive accidentalmente qualcos'altro.