| DocumentationRootretour à l'arborescence des catégories » Documentation techniqueEnsemble des informations pouvant être utiles au développement » Lynx docRestranscription de la documentation d'origine » Processeur/ROM » Cycles d'horloge du processeur «««« ( /^\ ) »»»» INFOS SUR LA CATEGORIE Créée le : 2009-09-20 17:00:00 Par : vince INFOS SUR LA PAGE Titre : Cycles d'horloge du processeur Sous Titre : Langue : FRA Source : http://www.monlynx.de/lynx/lynx4.html Auteur : vince Posté par : vince Cycles d'horloge du processeurEtant donné que le nombre de cycles du processeur pour chaque instruction est défini dans la spécification VTI, le nombre de "ticks" systèmes utilisés par chaque cycles du processeur sont définis ici. Certains vont nécessiter un nombre fixe de ticks, d'autres sur un nombre variable qui sera fonction de l'instruction précédente, certains autres auront besoin d'un nombre variable (et parfois non déterministe) de ticks basé sur le fonctionnement d'autres parties du système matériel. En plus, le processeur peut être mis en pause par les accès vidéos ou de raffraîchissement et il peut encore être interrompu par les timers et par le port série. L'objectif de la liste de ces variations possibles du nombre de cycles du processeur est de prévenir le développeur que les cycles du processeur ne peuvent pas être utilisés comme des éléments de mesure du temps. Sous certaines circonstances, l'environnement pourra être suffisament contrôlé pour autoriser une mesure de temps par le software (lecture initiale de la bande magnétique) mais en général cette pratique est à éviter. 1) RAM en mode page Les puces de RAM utilisées dans le système ont un mode de travail par page dans lequel le signal de contrôle (RAS) n'est pas répété à chaque accès mémoire. Ca permet d'avoir un cycle plus court que le cycle normal. Le prérequis pour utiliser un cycle en mode de page est que l'accès courrant soit dans la même plage de 256 adresses que l'accès mémoire précédent. Bien que le fait de comparer les adresses courrantes et précédentes soit l'une des meilleures méthodes pour déterminer si un cycle de mode de page est utilisé, ça prends souvent autant sinon plus de temps que de répéter le signal de contrôle. Par conséquent, le mode de page est souvent inutilisé par les développeurs processeur. Nous utilisons la méthode qui consiste à décoder l'opcode courrant pour voir si le prochain cycle peut être un cycle en mode page et on observe alors les atres états pertinents du système à la recherche d'une raison de NE PAS allouer un cycle de mode page. Bien que cette méthode ne soit pas 100% efficace pour permettre toutes les opportunités de mode page, ses besoins en silicium sont faibles et quand ils sont conçus convenablement, ils ne permettent pas d'accès incorrects aux cycles en mode page. Le processeur se sert de la circuiterie de mode page pendant sa lecture des opcode. Toutes les écritures et toutes les lectures de données sont faits avec des cycles mémoire normaux. L'opcode de lecture en mode page prends 4 ticks, un lecture ou une écriture normale en RAM prends 5 ticks. 2) Accès matériels, DTACK Les accès du processeur au matériel nécessite un signal de confirmation (DTACK) du matériel afin que le processeur puisse travailler. Ces accès processeur peuvent être séparés en deux classes. La première est pour le matériel qui est toujours disponible et l'autre est pour le matériel qui devient disponible à un moment sans lien avec le processeur. Pour le matériel qui est toujours disponible, le DTACK peut être généré depuis décodage d'adresse et ne rallonge pas le cycle au dela d'un cycle de lecture ou écriture en RAM (5 ticks). Les écritures sur Suzy sont considérées comme "toujours disponibles", peu importe si Suzy est réellement disponible au moment donné. Pour le matériel qui est éventuellement disponible, (certaines parties de Suzy et certaines parties de Mikey), le DTACK est généré comme une combinaison issue du décodage d'adresse, parfois le signal de colonne et matériel particulier peut alors être accédé. Ce cycle requiert un nombre minimum de 5 ticks et un maximum de 128 ticks (le maximum constaté actuellement est de 40 ticks). Le maximum n'est pas lié au processeur, c'est pour empêcher la sous alimentation du cache de raffraichissement vidéo. Toutes les écritures sur Suzy sont "aveugles" en ceci que le cycle d'écriture est toujours long de 5 ticks et n'obtient pas de DTACK en retour. Suzy acceptera les données immédiatement et ensuite les dispatchera en interne comme demandé. Le délai maximum pour ce placement interne est de 6 ticks (sauf pour l'écriture sur la cartouche). C'est moins que l'intervale minimum pour deux écritures séquentielles sur Suzy donc des collisions ne surviendront pas.Certaines parties matérielles dans Mikey sont construites à partir de RAM double port adressées de façon cyclique. Ces DPRAM ont un temps de latence maximal égal à leur temps de cycle (1.25µs). Certaines parties matérielles de Suzy sont aussi conçues avec de la RAM double port. Ces RAMs ne sont pas cycliques mais leurs temps de latence sont légèrement variables (+1 tick, -0) à cause de la synchronisation d'horloge. Les adresses accessibles par le CPU dans Mikey et Suzy ne sont pas toutes lisible ou inscriptibles. Voire l'annexe (annexe 2) pour les détails. (ou aussi la table des adresses ICI) 3) Résumé des Ticks par Cycle Processeur Cycle Min. Max. 4) Latence NMI du processeur Le chemin du signal NMI depuis la patte de Mikey à la patte du CPU interne contient des délais d'horloge. Ca peut rendre discutable l'utilisation de cette patte dans l'environnement de débogage. Heureusement pour nous, Howard et Craig ont aménagé le matériel de diagnostique pour toujours l'utiliser de manière efficiente. Voir les spécifications de la carte Howard pour plus d'informations. 5) Délai d'acceptation des requètes de bus de Suzy La latence maximale allouable pour Suzy est imposée par les besoins du circuit DMA vidéo. Comme compromis entre des piles FIFO dans le buffer DMA vidéo de Mikey et des performances réduites dans Suzy, nous avons positionné la latence maximale entre une demande de Bus et son acceptation à 2.5µs. Le temps entre une requète de bus de Mikey et la mise à disposition du bus par Suzy est dépendante de l'état du process en cours d'exécution à l'intérieur de Suzy. Le process le plus long dure 30ticks. En ajoutant la charge correspondant à l'acceptation de la requète de bus et à la mise à disposition on obtient un total de 40 ticks. (Source : http://www.monlynx.de/lynx/lynx4.html) «««« ( /^\ ) »»»» | ||||||||||||||||||||||||
-= DevLynx, un site par vince pour vous =- |