Quels sont les états d'attente de la mémoire flash?

J'utilise un microcontrôleur PowerPC freescale. Dans le module de mémoire flash de la fiche technique, le nombre d '"états d'attente de l'accès à la mémoire flash" est configurable.

Ce qui suit est la partie de la fiche technique soulevée ma question, elle est tirée de la description du registre des registres du module PFlash:

Ce champ doit être réglé sur une valeur correspondant à la fréquence de fonctionnement du PFlash et au temps réel d'accès en lecture du PFlash. Des fréquences de fonctionnement plus élevées nécessitent des réglages non nuls pour ce champ pour un fonctionnement correct du flash.
0 MHz, <23 MHz, états d'attente requis = 0 ---
23 MHz, <45 MHz, états d'attente requis = 1 ---
45 MHz, <68 MHz, états d'attente requis = 2 ---
68 MHz, <90 MHz, états d'attente requis = 3 ---

(PFlash est le module contrôleur Platform Platform)

Je comprends que le processeur est plus rapide que le flash, c'est pourquoi des états d'attente sont introduits. Ce que je ne comprends pas, c'est: si le processeur est plus rapide que le flash, alors c'est le processeur qui doit être ralenti pas le flash, mais le paragraphe ci-dessus dit le contraire (ou n'ai-je pas compris cela?), Il dit que dans le cas où le Pflash fonctionne avec des fréquences élevées, alors nous devons le ralentir en lui ajoutant des états d'attente supplémentaires !!

Quel est le problème avec ma compréhension?

Merci

Pour amplifier la réponse de Stevenevh, tout type de logique, lorsqu'il reçoit un signal d'entrée, mettra un certain temps à produire un signal de sortie; la mémoire est souvent très lente par rapport à d'autres logiques. Souvent, il y aura une garantie que le signal de sortie deviendra valide dans un certain laps de temps, mais c'est tout. En particulier, il est possible que le signal change plusieurs fois dans cet intervalle, et il n'y aura aucune indication, avant la fin de cet intervalle, que le signal a atteint sa valeur finale "correcte".

Lorsqu'un microcontrôleur ou microprocesseur typique lit un octet (ou un mot, ou n'importe quelle unité) de mémoire, il génère une adresse et, quelque temps plus tard, examine la valeur produite par la mémoire et agit en conséquence. Entre le moment où le contrôleur génère l'adresse et le moment où il regarde la valeur de la mémoire, il ne se soucie pas quand ni si les signaux de sortie de la mémoire changent. D'un autre côté, si le signal de la mémoire ne s'est pas stabilisé à sa valeur finale au moment où le contrôleur le regarde, le contrôleur va mal lire la mémoire comme ayant conservé la valeur émise au moment où il a regardé. Normalement, le contrôleur examinait la valeur de la mémoire dès qu'il était prêt à en faire quelque chose, mais si la valeur de la mémoire n'était pas prête alors, cela pourrait ne pas fonctionner. Par conséquent, de nombreux contrôleurs ont la possibilité d'attendre un peu plus longtemps lorsqu'ils sont prêts à traiter les données de la mémoire, pour garantir que la sortie de la mémoire est réellement valide. Notez que l'ajout d'un tel retard ralentira les choses (le contrôleur aurait été heureux d'agir plus tôt sur les données de la mémoire), mais n'affectera pas l'exactitude du fonctionnement (sauf si les choses sont ralenties au point que d'autres obligations de synchronisation ne peuvent pas être remplies).

Les états d'attente sont ajoutés au cycle d'accès à la mémoire initié par la CPU. C'est donc bien le CPU qui doit attendre le Flash plus lent. Le contrôleur de mémoire signale "non prêt" à la CPU pendant un certain nombre de cycles (0 à 3), et pendant ce temps, la CPU reste dans son état actuel, c'est-à-dire après avoir écrit l'adresse Flash, mais pas encore lu les données. Ce n'est que lorsque le contrôleur de mémoire signale "données prêtes" que la CPU lira sur le bus de données et poursuivra son instruction (en verrouillant les données dans un registre ou dans la RAM).

Le processeur pourrait avoir besoin de caler sur la mémoire, mais une conception intelligente n'aurait pas besoin de le faire.

Je pense que la technologie clé que vous ne connaissez pas est l' accès en mode rafale / page . Cela permet au bande passante des accès mémoire d'être très proche de la vitesse du processeur (mais probablement Flash est toujours le goulot d'étranglement car je n'ai jamais vu de microcontrôleur basé sur Flash qui fonctionne à> 200MhZ)

Cependant, la latence reste la même. Par exemple, pour les microcontrôleurs STM32F4 que j'utilise, #wait states = floor (clockSpeed ​​/ 30MhZ). Cela signifie que la latence est toujours de 33 ns, quelle que soit la vitesse d'horloge. Il y a un dicton, "L'argent peut acheter de la bande passante, mais la latence est éternelle ..."

Même si la bande passante Flash n'était pas suffisante pour occuper le processeur, vous pouvez facilement concevoir un cache de code qui stocke et prélève des instructions qui devraient s'exécuter. ST a un indice à ce sujet pour leurs microcontrôleurs STM32F4 (168 MhZ):

Grâce à l'accélérateur ART et à la mémoire Flash 128 bits, le nombre d'états d'attente indiqué ici n'affecte pas la vitesse d'exécution à partir de la mémoire Flash car l'accélérateur ART permet d'atteindre une performance équivalente à l'exécution du programme à 0 état d'attente.

En fait, la déclaration suggère également que le mode rafale n'est pas nécessaire et qu'une interface mémoire très large est également suffisante. Mais l'idée est la même (utiliser le parallélisme pour masquer la latence). Sur puce, les fils sont libres, donc une mémoire de 128 bits aurait du sens.