Quand les risques structurels se produisent-ils dans les architectures pipelinées?

Je cherche des exemples relativement simples de cas où des risques structurels se produisent dans une architecture en pipeline.

Le seul scénario auquel je peux penser est lorsque la mémoire doit être accessible pendant différentes étapes du pipeline (c'est-à-dire, l'étape de récupération des instructions initiales et l'étape de lecture / écriture de la mémoire ultérieure).

Je pense qu'il y a beaucoup plus de risques structurels dans des architectures plus complexes, telles que superscalaires. Est-ce un danger structurel lorsqu'une instruction est envoyée à une unité d'exécution mais est mise en file d'attente parce que l'unité est en cours d'utilisation?

Si cela est hautement spécifique à l'architecture, supposez simplement MIPS ou quelque chose de similaire.

Dans une implémentation scalaire, un risque structurel peut exister si le matériel d'exécution spécifique n'est pas entièrement canalisé. Pour certaines opérations (par exemple, la multiplication et en particulier la division), le coût de mise en œuvre d'un pipeline complet peut ne pas être considéré comme valable pour la fréquence attendue de l'opération.

Dans une implémentation superscalaire, un risque structurel peut exister car toutes les unités d'exécution ne peuvent pas effectuer toutes les opérations. Par exemple, la prise en charge du lancement de l'exécution de quatre opérations de mémoire ou de quatre multiplications à chaque cycle serait relativement coûteuse lorsqu'elle se limiterait à un problème à quatre larges étant donné qu'un type d'opération différent est probablement disponible.

Les limites de port d'enregistrement en lecture et en écriture de fichiers peuvent également présenter des risques structurels. Bien qu'il soit possible de fournir suffisamment de ports de lecture et d'écriture pour prendre en charge le pire des cas, les coûts des ports de fichiers d'enregistrement pour satisfaire le pire des cas (même avec l'avantage en termes de complexité de conception de ne pas avoir à gérer spécialement des cas exceptionnels) peuvent être considérés comme sans valeur les avantages lorsque les mauvais cas sont suffisamment rares ou non critiques. Par exemple, certaines implémentations dans le désordre utilisent la capture d'opérande (saisie d'opérandes qui deviennent disponibles entre le moment où l'opération entre dans le planificateur et le moment où elle est planifiée pour être exécutée) et fournissent moins de ports de lecture de registre que nécessaire pour une opération pleine largeur (qu'il s'agisse d'opérandes disponibles plus tôt sont lus lorsque l'opération entre dans le planificateur ou lorsque l'opération est planifiée pour être exécutée).

(Même pour une implémentation dans l'ordre, la transmission des résultats et l'utilisation d'opérations avec un opérande source de registre unique pourraient rendre moins nécessaire la prise en charge de quatre ports de lecture de registre pour un problème bidirectionnel.)

De même, la banque est souvent utilisée pour les caches (et a été proposée pour les fichiers de registre). Par exemple, dans le cas courant, il est peu probable que deux accès correspondent à la même banque sur 16 banques. Le stockage bancaire est nettement moins cher que l'ajout de ports d'accès. Le potentiel de conflits bancaires représente un risque structurel.