DEATH Le 01/05/2021 à 20:54 Salut,
Avec le code Mandelbrot au DSP (voir autre sujet) une question m'est tout de suite venu : va t il y avoir un bug vu que j'écris dans la mémoire "externe" au DSP (la DRAM quoi).
Dans les différentes docs il est indiqué que l'écriture externe peut être corrompue si le DSP n'effectue pas une lecture avant de faire une écriture et en plus il faut ajouter une instruction pour activer le scoreboard afin d'être sûr que la lecture est bien terminé avant de lancer l'écriture...
Plus précisément il est indiqué que le DSP peut éventuellement voir le cycle DBGL précédent et provoquer une corruption des données en cas d'écriture s'il n'y a pas eu assez de cycle après le dernier BG (au moins 1cycle)
ça n'est pas très très clair dans les documentations, mais il me semble qu'il s'agit de son propre signal BG et non celui d'un autre processeur.
Ce qui voudrait dire qu'il faut éviter de faire des écritures successives ou une écriture juste après une lecture ou alors il faut bloquer le DSP en faisant intervenir le mécanisme du scorboard
Le code DSP de DOOM est rempli de cette méthode et à bien y réfléchir je me demande si c'est utile.
En tout cas je n'ai vu aucune corruption de données sur le code Mandelbrot au DSP.
Précision, je ne prend aucune précaution particulière pour faire l'écriture, je fais un simple STORB Rn,(Rn) sans rien ni avant ni après pour éviter le bug, sauf un ADDQ 2 instructions plus loin pour incrémenter le registre (Rn) concerné.
Pour le bug de lecture/écriture au DSP il est bien réel, je suis tombé dessus en développant sur le DSP. Une routine qui marchait parfaitement bien au GPU s'est mise à avoir des comportements bizarres au DSP. Il a fallu que je force le scoreboard en faisant des OR Rn,Rn.
Ca s'est empiré quand j'ai rajouté une routine sous interruption au DSP. J'ai dû protéger des lectures successives pour éviter des corruptions. Sans interruptions ça fonctionnait.
Le truc c'est que c'est pas systématique. Je pense que si tes STORB Rn,(Rn) sont suffisamment espacés dans le temps (plusieurs cycles), ça passe.
DEATH Le 01/05/2021 à 22:19 Oui les STOREB sont très espacés et en plus il y a une instruction plus loin qui touche un des registres du STORB donc je suppose que le mécanisme du scorboard bloc le DSP à ce moment si le cycle mémoire n'est pas fini.
Ce que je comprends c'est qu'il faut que le signal BG du DSP (DBGL) soit fini depuis au moins 1 cycle pour pouvoir faire une écriture fiable.
ça ne me semble pas être un si gros problème non ? Je veux dire, d'une part le DSP ne devrait en principe n'être dédié qu'au son, donc peu de raison qu'il viennent faire des écritures externe et d'autre part un cycle mémoire externe ne dure pas si longtemps que ça.
Peut être quoi, 5-6 cycles d'horloge, le signal BG ne doit donc pas rester actif si longtemps.
En cas d'interruption il faut vraiment pas avoir de chance pour tomber au mauvais moment et en plus faire des écritures.
Par contre c'est une autre histoire si on exécute du code en externe vu que là le DSP est constamment sur le BUS
