ARCHITECTURE CT2

(c) Janvier 99, Rodolphe Czuba

1/ PRESENTATION
Comme vous pouvez le voir sur l'image plus bas, l'architecture de la CT2 est construite autour de 2 bus 32-Bit, alors que le Falcon d'origine est, à l'exception du bus DATA entre le VIDEL et la ST-Ram, organisé en 16-Bit. 

Avec la CT2, l'architecture propre aux ST/FALCON qui consiste en une ram unique pour la vidéo et le CPU, est soulagée par la FAST-Ram !
En effet, avec la CT2 vous pouvez faire tourner vos programmes aussi vite en 'True Color' qu'en 16 couleurs, puisque le programme en FAST-Ram n'est plus ralenti par des modes vidéo gourmands ! De plus le mode BURST du 030 est enfin utilisé pour lire 4 LONGS et les cacher en 12 cycles 50 MHz !

L'écriture a été améliorée en 4 cycles 50 MHz au lieu de 6 sur la REV A !

Ainsi, le Falcon devient une simple carte I/O 16-Bits pilotée par la CT2. La ST-Ram devient donc la RAM vidéo et sonore, ce que l'on appelle 'CHIP-Ram' sur AMIGA, c'est à dire la ram utilisée par les chips (BLITTER, SOUND, VIDEO). La FAST-Ram devient donc la ram système à utiliser le plus possible par le CPU. Cette architecture se rapproche de celle d'un PC...

Le coeur de la CT2 est constitué de 2 composants nommés ANNA et THALIE assurant les fonctions suivantes:

ANNA:

THALIE:

 

2/ NOUVELLES REGLES

De nombreux développeurs software doivent changer leur approche du Falcon car dans de nombreux cas l'utilisation de la FAST-Ram par le CPU est bien plus avantageuse que toute autre méthode qu'ils auraient pu mettre en place pour palier à la lenteur de la ST-Ram.
Ceci est particulièrement valable pour ceux qui ont utilisé à tout va le DSP pour des calculs qui sont maintenant, dans une majorité des cas, effectués plus rapidement par le CPU en FAST-Ram. Il convient désormais de n'utiliser le DSP que pour des calculs pour lesquels il a été conçu (matrice, FFT, etc...), en n'oubliant pas que les délais de transferts dans ce dernier sont devenus considérables par rapport à ceux de la FAST-Ram.

De plus, un effort important doit être fait pour coder en LONG et aligner le code (programmeurs en C, mettez vous à l'ASM !) sur, au minimum, des LONGs, ou mieux, des frontières de 16 octets (4 LONGs = 1 ligne de cache).
Ceci est nécessaire si vous voulez profiter au maximum du BURST. Il faut cependant savoir que le 'WRAP AROUND' du 030 est désactivé par le hard de la CT2 pour éviter une baisse de performance avec la majorité des logiciels actuels qui ne respectent pas les alignements 32-Bit sur des lignes de cache. Ainsi le VL-BURST (Variable Length) permet au CPU de ne remplir que la fin de sa ligne de cache sans retourner compléter le début de sa ligne avec du code ou des data à des adresses précédentes.

Par exemple, si vous exécutez du code à l'adresse $01025480, le CPU va burster une ligne compléte de son cache avec le contenu (LONG) des adresses:
$01025480, $01025484, $01025488 et $0102548C.
Si par contre le CPU burst à partir de $01025488, il s'arrêtera après avoir lu le deuxième LONG à $0102548C mais n'ira pas prendre les 2 premiers longs en $01025480 et $01025484 ! Ce qu'il aurait fait avec le WRAP AROUND...C'est dans la plupart des cas 4 cycles (2+2) qui ont ainsi été économisés car il est rare que le CPU ait besoin de ces 2 précédents LONGs, sauf avec certains modes d'adressage assez peu usités...

Pour plus d'informations sur le fonctionnement des caches du 030, veuillez vous reporter au chapitres 6 et 7 du '68030 USER'S MANUAL' de MOTOROLA ou au chapitre 4 du 'MISE EN OEUVRE DU 68030' aux éditions SYBEX (code ISBN 2-7361-0350-5) pour ceux qui ne maîtrisent pas la langue anglaise.

ARCHITEC.GIF
Retour