Difference between revisions of "TileEterogenea"
(→Tile eterogenea) |
|||
| Line 8: | Line 8: | ||
Il wrapper della load store unit puo' rilevare il completamento di una transazione osservando i segnali di writeback per le load, e di wakeup/sleep per le store. | Il wrapper della load store unit puo' rilevare il completamento di una transazione osservando i segnali di writeback per le load, e di wakeup/sleep per le store. | ||
| − | La load store unit puo' dare problemi nell'implementazione in caso di un solo thread, per come sono definiti alcuni tipi (thread_mask_t, gli arbitri | + | La load store unit puo' dare problemi nell'implementazione in caso di un solo thread, per come sono definiti alcuni tipi (thread_mask_t, gli arbitri, idx_to_oh, etc...). Questo va verificato. |
L'acceleratore inoltre dovrebbe implementare l'interfaccia di IO *SLAVE*, e collegato alla porta slave del modulo io_interface. | L'acceleratore inoltre dovrebbe implementare l'interfaccia di IO *SLAVE*, e collegato alla porta slave del modulo io_interface. | ||
Nota bene: il core e' solitamente attaccato alla porta master dell'io interface e questo gli consente di inviare richieste di IO (e non di riceverne). L'acceleratore si presuma debba solo ricevere richieste di IO dai core e quindi deve essere attaccato alla porta slave. La porta slave andrebbe quindi usata per modificare dei registri di stato interni all'acceleratore (vedi com'e' fatto nel modulo nuplus_item_interface). | Nota bene: il core e' solitamente attaccato alla porta master dell'io interface e questo gli consente di inviare richieste di IO (e non di riceverne). L'acceleratore si presuma debba solo ricevere richieste di IO dai core e quindi deve essere attaccato alla porta slave. La porta slave andrebbe quindi usata per modificare dei registri di stato interni all'acceleratore (vedi com'e' fatto nel modulo nuplus_item_interface). | ||
Latest revision as of 18:17, 21 December 2018
La tile eterogenea puo' essere costruita a partire dal modulo tile_nuplus esistente.
Si potrebbe copiare la tile_nuplus in un nuovo modulo tile_custom. Dall'interno della tile va mantenuto tutto tranne il nuplus_core.
Il modulo nuplus_core potrebbe essere copiato in custom_core e svuotato di tutta la logica a parte la load store unit. La load store unit andrebbe astratta da un'interfaccia che offre l'accesso di memoria agli acceleratori. La load store unit supporta un numero di transazioni pendenti pari al numero di thread. L'acceleratore potrebbe quindi vedere un'interfaccia che consente da 1 a THREAD_NUMB transazioni concorrenti. Gli accessi di lettura o scrittura sarebbero convertiti in istruzioni nuplus (instruction_decoded_t), di granularita' selezionabile (byte/word/blocco). Il wrapper della load store unit puo' rilevare il completamento di una transazione osservando i segnali di writeback per le load, e di wakeup/sleep per le store.
La load store unit puo' dare problemi nell'implementazione in caso di un solo thread, per come sono definiti alcuni tipi (thread_mask_t, gli arbitri, idx_to_oh, etc...). Questo va verificato.
L'acceleratore inoltre dovrebbe implementare l'interfaccia di IO *SLAVE*, e collegato alla porta slave del modulo io_interface. Nota bene: il core e' solitamente attaccato alla porta master dell'io interface e questo gli consente di inviare richieste di IO (e non di riceverne). L'acceleratore si presuma debba solo ricevere richieste di IO dai core e quindi deve essere attaccato alla porta slave. La porta slave andrebbe quindi usata per modificare dei registri di stato interni all'acceleratore (vedi com'e' fatto nel modulo nuplus_item_interface).
