Quando si verificano pericoli strutturali nelle architetture pipeline?

Sto cercando alcuni esempi relativamente semplici di quando si verificano pericoli strutturali in un'architettura pipeline.

L'unico scenario che mi viene in mente è quando è necessario accedere alla memoria durante le diverse fasi della pipeline (ovvero, la fase di recupero dell'istruzione iniziale e la fase di lettura / scrittura della memoria successiva).

Sto pensando che ci siano molti più pericoli strutturali in architetture più complesse, come ad esempio superscalar. Si classifica come un pericolo strutturale quando un'istruzione viene inviata a un'unità di esecuzione ma viene messa in coda perché l'unità è in uso?

Se questo è altamente specifico per l'architettura, allora basta assumere MIPS o qualcosa di simile.

In un'implementazione scalare, può esistere un pericolo strutturale se l'hardware di esecuzione specifico non è completamente pipeline. Per alcune operazioni (ad esempio, la moltiplicazione e in particolare la divisione), il costo dell'implementazione della pipeline completa potrebbe non essere considerato utile per la frequenza prevista dell'operazione.

In un'implementazione superscalare, può esistere un pericolo strutturale poiché non tutte le unità di esecuzione possono eseguire ogni operazione. Ad esempio, supportare l'avvio dell'esecuzione di quattro operazioni di memoria o quattro moltiplicazioni ogni ciclo sarebbe relativamente costoso se limitato a un problema di quattro dimensioni dato che è probabile che sia disponibile un diverso tipo di operazione.

Anche i limiti delle porte di lettura e scrittura dei file di registro possono comportare rischi strutturali. Sebbene sia possibile fornire abbastanza porte di lettura e scrittura per supportare il caso peggiore, i costi delle porte dei file di registro per soddisfare il caso peggiore (anche con il vantaggio in termini di complessità di progettazione di non dover gestire in modo speciale casi eccezionali) non possono essere considerati validi i benefici quando i casi negativi sono sufficientemente rari o non critici. Ad esempio, alcune implementazioni fuori servizio utilizzano l'acquisizione di operandi (acquisizione di operandi che diventano disponibili tra il momento in cui l'operazione entra nello scheduler e il momento in cui è pianificata per l'esecuzione) e forniscono un numero inferiore di porte di lettura del registro rispetto a quelle necessarie per l'operazione a larghezza intera (indipendentemente dal fatto che gli operandi disponibile in precedenza vengono letti quando l'operazione accede allo scheduler o quando l'operazione è pianificata per l'esecuzione).

(Anche per un'implementazione in ordine, l'inoltro dei risultati e l'uso di operazioni con un singolo operando di origine registro potrebbero rendere meno necessario il supporto di quattro porte di lettura del registro per problemi a due vie.)

Allo stesso modo, il banking è spesso usato per le cache (ed è stato proposto per i file di registro). Ad esempio, nel caso comune, è improbabile che due accessi mappino sulla stessa banca su 16 banche. Lo storage bancario è sostanzialmente meno costoso dell'aggiunta di porte di accesso. Il potenziale di conflitti bancari rappresenta un rischio strutturale.