--== DEVLYNX ==--

 
 
|
 
 
 
 
Accueil
News
Doc
Mémoire
Recrutement
Faq
Liens
Pseudo :

Mot de passe :


Pas de compte ?

S'inscrire...


Statistiques

Documentation


Rootretour à 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 processeur

Etant 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.
---------------------------------------------------------------------------
RAM mode page (lecture) 4 4
RAM normale (lecture/écriture) 5 5
ROM mode page 4 4
ROM normale 5 5
Matériel disponible (lecture/écriture) 5 5
DPRAM audio de Mikey (lecture/écriture) 5 20
DPRAM de la palette de couleurs de Mikey (lecture/écriture) 5 5
Matériel de Suzy (écriture) 5 5
Matériel de Suzy (lecture) 9 15


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)
«««« ( /^\ ) »»»»

générée en 4 ms
-= DevLynx, un site par vince pour vous =-