Présentation du projet F-CPU
par Yann GUIDON
à l'ISIMA le 16 octobre 2003 à 14h

 

 


I Presentation sommaire

- Yann Guidon et les autres contributeurs du projet - F-CPU - ne pas oublier le tiret ! :-) - existence "officielle" - http://www.f-cpu.org (avec www) un peu mort .... - http://f-cpu.seul.org : le site de travail - les mailing lists : f-cpu à seul point org et f-cpu_france à april.org - Le découpage : * Le "Libre Hardware" existe-t-il ? * Le projet F-CPU * F-CPU : le modèle * FC0 : une implémentation * La réalisation * Les sujets de projets (avec questions-réponses entre chaque partie)

II Le "Libre Hardware" existe-t-il ?

- A quoi sert la liberté ? à créer et donc accélérer l'amélioration de l'état de l'art. - Quel est le prix de la liberté ? on a ce qu'on paie. - L'analogie entre HW et SW est-elle possible ? - copyright, droits d'auteurs, brevets, secrets industriels .... - la mentalité des informaticiens - la tradition des électroniciens - le copyleft : GPL appliqué au "matériel" - "Free quelquechose" : ne pas confondre libre et gratuit !!! - il faudrait trouver un moyen pour que ce ne soit jamais confondu mais la confusion semble arranger trop de personnes. - Le terme "libre" n'est pas ambigu. - Quel terme employer ? - quasiment toutes les combinaisons ont été employées à partir de Free, Open, HW, Core, IP, ..... - "Design" décrit mieux que "hardware" - documents de référence : Ressources inestimables : http://opencollector.org/ et http://opencollector.org/Whyfree/ Graham Seaman @ Oekonux2001 : "Free Hardware Design - Past, Present, Future" http://opencollector.org/Whyfree/freedesign.html "A History of Free Hardware Design" (Local) http://opencollector.org/history/index.html RMS on Free Hardware (1999) : http://linuxtoday.com/news_story.php3?ltsn=1999-06-22-005-05-NW-LF F-CPU @Oekonux2001 : "Freedom for the devices : Philosophy, Dogma or Religion ?" http://opencollector.org/Whyfree/oekonux03.html (Local) - la portabilité : l'écueil du domaine, le Graal pour le Libre - les standards : "à quoi bon, tant que ça marche ?" - exemple du projet "Manticore" (générateur vidéo dans un FPGA) - le cas d'Alliance (http://www-asim.lip6.fr/recherche/alliance/) - la dépendance des constructeurs - GHDL (http://ghdl.free.fr/) (local) est-il LA solution ? - en attendant : http://f-cpu.seul.org/new/VHDL-HOWTO.f-cpu (Local) - Les licences "Free HW" sont-elles possibles ? - Le copyright s'applique indubitablement aux codes sources - par contre la position par rapport aux brevets et autres protections est nébuleuse - chacun a sa propre opinion : BSD, GPL, LGPL, nouvelle licence ? - Et une licence "SW" a-t-elle un sens en HW ? - voir http://opencollector.org/hardlicense/ - réussite du modèle ou réussite financière ? OpenCores (http://www.opencores.org/) ? (un portail et des services remplacent-ils le développement ?) Silicore http://www.silicore.net/ Leon : http://www.gaisler.com/ http://www.chipanalyst.com/mpr_public/editorials/edit15_03.html Une quantité incroyable d'initiatives "Open/libre/free" : http://opencollector.org/summary.php3 (Local) - Brevets exemple de soucis de tous les jours :
Legal Notice

ALTERA, QUARTUS, CYCLONE, APEX, etc. are Trademarks of Altera Corporation
XILINX, WEBPACK ISE, SPARTAN, etc. are Trademarks of Xilinx Inc.
MODELSIM is a Trademark of Mentor Graphics Corporation
PIC is a Trademark of Microchip Technology Inc.
Microsoft Windows is a Trademark of Microsoft Corporation
Acrobat Reader is a Trademark of Adobe Systems Incorporated

I have no idea if implementing this core will or will not violate patents,
copyrights or cause any other type of lawsuits.
I provide this core AS IS, without any warranties.
If you decide to build this core, you are responsible for any legal resolutions,
such as patents and copyrights, and perhaps others ....
This source files may be used and distributed without restriction provided that
all copyright statement are not removed from the files and that any derivative
work contains the original copyright notices and the associated disclaimer.

THIS SOURCE FILES ARE PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
(extrait de http://www.opencores.org/tmp/cvsget_cache/cpugen/cpugen_tutorial.pdf) Le cas ARM : http://opencollector.org/news/Archives/EST/Sun/981897682.html http://www.eet.com/story/OEG20010126S0026 (local) Le cas MIPS Le cas Microchip Transmeta vs. Intel : la même gymnastique que Intel vs AMD vs .... http://opencollector.org/news/Archives/2000/Jan/948905785.html (local) - y a-t-il vraiment tant de différences entre le "Libre" et le "Propriétaire" ? - Quels moyens faut-il ? http://www.f-cpu.org/EDAserver.html (local) - Il n'y a pas vraiment de consensus sur tous ces sujets, chacun fait sa "cuisine" dans son coin. donc pas d'émergence ni de structuration d'un mouvement. Donc pas d'équivalent de la FSF pour le HW Donc pas d'équivalent à GCC pour faire un "linux" - discussions publiques : http://linuxfr.org/2003/03/02/11564.html http://linuxfr.org/2003/02/10/11317.html http://linuxfr.org/2002/10/25/9945.html http://linuxfr.org/2002/06/16/8659.html http://linuxfr.org/2002/06/12/8622.html http://linuxfr.org/2002/05/21/8325.html http://linuxfr.org/2002/11/30/10480.html http://linuxfr.org/2002/01/08/6553.html http://linuxfr.org/2002/05/21/8325.html http://linuxfr.org/2001/07/10/4191.html http://linuxfr.org/2001/05/28/3665.html http://linuxfr.org/2001/04/28/3354.html http://linuxfr.org/2000/12/29/1657.html http://linuxfr.org/2000/12/29/1656.html Article sur F-CPU dans Linux Magazine (Local)

III Le projet F-CPU

- F-CPU signifie "Freedom CPU" - "(to) Design and let (to) design" - F-CPU est très orienté vers le Logiciel Libre dans son ensemble, pas seulement Linux. - "Liberté" signifie aussi, dans ce contexte, de permettre à n'importe qui de contribuer et d'utiliser le projet, sans barrière d'entrée autre qu'avoir un ordinateur et savoir s'en servir. Donc de mettre la haute technologie à la portée de chacun. - Ambition et utopie, effet de groupe. - rôle innovant et fédérateur (qui n'a pas bien survécu, en attendant la prochaine vague) - Les termes de distribution : GNU GPL + Licence F-CPU - diffusion des sources si fabrication/production - essayer d'éviter que les fichiers soient "contournés" - Brochure - Manuel à http://f-cpu.seul.org/cedric/unstable/ note : les instructions en virgule flottante ne sont pas encore complétement intégrées - présentations : 19c3 17c3 - Organisation du groupe autour de la mailing list - contributeurs : ingénieurs ou amateurs, professionnels ou non, essentiellement en France et en Allemagne mais aussi connu dans les autres pays. - la "constitution" :
             To develop and make freely available an
architecture, and all other intellectual property necessary
to fabricate one or more implementations of that architecture,
with the following priorities, in decreasing order of importance:

       1. Versatility and usefulness in as wide a range of
             applications as possible
       2. Performance, emphasizing user-level parallelism and
             derived through intelligent architecture rather
             than advanced silicon process
       3. Architecture lifespan and forward compatibility
       4. Cost, including monetary and thermal considerations
- Objectif : durer 50 ans (tant qu'à faire, 2x plus qu'Alpha) - non-objectif : F-CPU est un coeur de microprocesseur, pas de lien avec ce qui est autour (pas de F-carte_mère etc.) - Contraintes : - extensibilité maximum - corollaire : simplicité - performance élevée - aucun problème de "propriété intellectuelle" - développement facile, sans moyens à l'échelle "industrielle" - Les moyens : logiciels "Open Source" et, lorsqu'il est possible d'y avoir accès, propriétaires. - Solution : créer une architecture à partir de zéro, ou presque : on sait ce qui fonctionne et ce qui a échoué - RISC vs CISC - delayed branch - load/store etc. - Taile des données : - l'exemple PDP11/VAX (16 -> 32 bits) puis 286->386 (DOS->win32) - le passage (très lent) de 32 à 64 bits - IPV6 : 128 bits - peut-on éviter un fossé lors d'un prochain passage ? oui : il ne faut pas creuser de fossé --> processeur à taille de données indéterminée - Cela ne sert à rien de faire un CPU 32 bits : il y a une quantité innombrable de processeurs 32 bits, de tous les types, et même "libres". même s'il est possible de "forker" le développement de F-CPU, le projet central se concentre sur le 64+ bits. - Taille des pointeurs : - Calcul en parallèle : SIMD - Organisation interne : - on ne peut pas prévoir à plus de qqs années l'évolution des architectures - la topologie du système global ne peut pas être imposée par le processeur - Puissance : il a intérêt à être puissant sinon personne n'aura de raison de l'utiliser (même s'il est libre ou économique) - On ne peut pas créer d'architecture super-optimisée pour une application car il n'y a pas d'objectif précis à court terme. L'idée de départ est un processeur de station de travail mais il doit pouvoir être décliné à toutes les sauces.

III Le modèle F-CPU

- Un seul "conteneur" : un registre. - types de données : un registre contient une donnée qui peut être interprétée comme : - un entier sur 8, 16, 32 ou 64 bits (défini par MAX_CHUNK_SIZE) le reste des bits est à 0 - un paquet SIMD remplit tout le registre - un pointeur de taille limitée à MAX_CHUNK_SIZE mais le nombre de bits "utiles" est déterminé par l'implémentation Conférence PARINUX (juin 2002) (local) - modèle des queues de prefetch /usr/src/linux/init/do_mounts.c : Q1: static void __init handle_initrd(void) { ..... pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD); Q2: if (pid > 0) { while (pid != wait(&i)) { Q3: current->policy |= SCHED_YIELD; schedule(); Q4: } Q5: } ..... - fonctionnement du "fetcher" - "cache" N lignes de la cache L1 - chaque ligne est "associée" à un ou plusieurs registres - pour sauter à un endroit, il faut - préfetcher la destination et l'associer à un registre - au moment du saut, une nouvelle ligne est sélectionnée si la condition est remplie - avantage : dans les boucles, pas besoin de recalculer à chaque fois l'adresse - LRU et remplacement des entrées - le buffer du fetcher doit être petit pour être rapide - la gestion des alias doit être efficace (hashage à 2 sens) - Exemples de programmation - if () {} r1 : condition (nul ou non, pair ou impair, ) r2 : adresse du saut loadaddri r2, end_if; ..... if r1==0 jmp r2 ..... end_if: - if () then {} else {} r1 : condition (nul ou non, pair ou impair, ) r2 : adresse du saut r3 : adresse du saut terminal loadaddri r2, end_if; loadaddri r3, else; ..... if r1==0 jmp r2; ..... jmp r3; else: ... end_if: - do {} while () r1 : condition (nul ou non, pair ou impair, ) r2 : adresse du saut loopentry r2; ..... if r1==0 jmp r2; - repeat N {} r1 : condition (nul ou non, pair ou impair, ) r2 : adresse du saut loopentry r2; loadconst r1, N ..... loop r1,r2; (saute sur r2 si r1 n'est pas nul, décrémente r1 en //) - appel de fonctions (sans passage de paramètres) r2 : adresse du saut r3 : adresse de retour call_fonction1: loadaddri r2, leaf_function; ... jmp r2, r3; (garde PC+4 dans r3 et saute sur R3) ... jmp xxx; (retour) leaf_function: ..... jmp r3; - utilisation conjointe de toutes ces structures -> allocation intelligente des registres de saut -> problèmes d'optimisation globale et de linker - load/store : la LSU (Load-Store Unit) - fonctionnement similaire au mécanisme de préfetch mais avec une granularité d'un octet et la possibilité d'écrire dans la ligne pointée - seul mode d'adressage : postincrémenté - Exemples d'optimisation du scheduling au niveau C http://www.f-cpu.seul.org/whygee/dct_fc0/dct_fc0.html (local) - Les instructions GET et PUT permettent de déplacer les parties complexes (scheduling), dangereuses (glitches HW ?), protégées (user/sup) ou dépendant de l'implémentation hors du pipeline principal.

IV FC0

- FC0 signifie : "F-CPU Core 0" - superpipeline - OOOC

V La réalisation

- Sources en VHDL - la portabilité - Structuration des sources - état de la réalisation :
- Le simulateur :

VI Les projets d'étudiants

- FPU - simulation / émulation - étude sur la testabilité (DFT)