Après 12 ans de silence, le projet Freedom CPU vient de redémarrer. Il a commencé par se doter d'un nouveau site tout propre, avec wiki, blog et (Ôh!) un git, mais surtout le projet repart de zéro en gardant juste le meilleur du travail réalisé autour de l'An 2000. En effet, le FC0 est une architecture RISC qui n'a pas beaucoup vieilli, alors que l'environnement, l'industrie et les applications ont radicalement changé.
Mais pourquoi relancer ce projet alors que ce microprocesseur n'a aucune chance d'équiper mon desktop ou laptop ?
D'abord parce que le desktop n'est plus là où la bataille fait rage (Intel a plus peur d'ARM que d'AMD). En 15 ans, la performance brute a plafonné et est devenue secondaire, alors la consommation et le parallélisme sont devenus primordiaux.
Ensuite parce qu'aujourd'hui encore plus qu'en l'An 2000, la liberté des plateformes est réellement en jeu, au point que même RMS sort (enfin !) de sa réserve. La France vient de passer une loi légalisant le pompage en masse des données sur Internet, mais demain, devrons-nous être forcés d'installer un mouchard/boîte-noire à la maison ?
Et puis les outils ont énormément évolué en 15 ans. Le simulateur GHDL est solide, on trouve facilement des FPGA de haute densité à des prix raisonnables, et on peut même faire de la synthèse du code VHDL sous Linux ! (j'en ai même vu y arriver)
Enfin, et surtout, parce que le YASEP1 commence à être assez mûr mais il est limité à 32 bits. L'architecture du F-CPU est complémentaire, et selon les besoins on peut choisir la bonne architecture, et pourquoi pas les faire travailler ensemble : le petit 32 bits travaillant comme microcontrôleur temps réel, le grand 64 bits comme processeur d'application.
Il est donc temps de réunir ces deux projets.
Une des nombreuses leçons apprises ces dernières années est que l'architecture elle-même compte assez peu et c'est l'environnement de développement et la masse critique qui contribuent le plus à son succès (sinon on serait débarrassés des x86 depuis des lustres). Pour cela, le F-CPU va partager l'environnement de développement du YASEP et bénéficier de l'expérience acquise depuis dix ans.
Avec un outil entièrement écrit en JavaScript, c'est clairement la "génération Arduino et Raspberry Pi" qui est ciblée, car les nouveaux arrivants sont plus sensibles à l'ouverture et la facilité d'utilisation (et pas juste la gratuité) que les ingénieurs expérimentés. Qui a envie de faire de l'administration système pour installer plusieurs outils obscurs avant de pouvoir enfin commencer à coder ? Peu de personnes ont actuellement cette patience, surtout avec les kits de développement qui deviennent de plus en plus faciles à utiliser.
Maintenant que les sites web sont remis en état de marche, l'étape suivante consiste à réécrire YGWM, l'environnement fenêtré en JavaScript. Écrit au début en mode "vite fait ça marche à peu près", il faut tout remettre au propre, corriger quelques bugs, et séparer les éléments spécifiques du YASEP afin que l'interface puisse fonctionner pour n'importe quel famille de processeur.
-
Pour faciliter le développement des outils, un petit processeur‐jouet a été conçu : le YASEP — Yet Another Small Embedded Processor. De « jouet », le YASEP a grandi pour devenir un microcontrôleur original, cohérent, accessible et ne nécessitant quasiment aucune installation de logiciel, grâce à son site Web presque magique. ↩
Aller plus loin
- Le site web de F-CPU (1730 clics)
- Article Linuxfr sur le YASEP (395 clics)
- RMS : pourquoi nous avons besoin de hardware libre (243 clics)
- Le site du YASEP (364 clics)
- Ébauche d'un tutoriel qui explique les arcanes de YGWM (148 clics)
# Yann Guidon
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Il y a bien 10 ans, j'étais allé au diner de Linuxfr au Flam's. Comme je le fais le plus souvent possible, je me suis mis près de
gensgeeks que je ne connaissais pas. C'est une façon de faire que je n'ai jamais regretté car cela m'a permis de faire connaissance de personnes extraordinaires. Ce soir là, j'ai fait connaissance de Yann Guidon. Il a sorti son PC de dessous la table et m'a montré comment il concevait les circuits électroniques et compilait le VHDL. C'est tout un pan de l'informatique que je découvrais, émerveillé.Si vous avez l'occasion de vous faire expliquer comment on conçoit des circuits électroniques complexes, ne la ratez pas. Cela fait partie de la culture que nous devrions tous avoir.
Yann, tu devrais faire des conférences/cours/TP sur ce sujet que je juge actuellement beaucoup trop confidentiel.
[^] # Re: Yann Guidon
Posté par Yann Guidon (site web personnel) . Évalué à 6.
Merci Pierre, j'apprécie beaucoup, et cela fait plus de 10 ans puisque F-CPU a participé à RMLL2002, donc il y a déjà 13 ans…
Concernant les cours/TP, j'y pense depuis longtemps. L'année dernière j'ai eu la possibilité de proposer des conférences pour une école d'ingés infos, mais le boulot m'a rattrapé et je me suis aperçu que je ne pouvais pas faire les deux à la fois, car je suis trop investi, surtout dans les sujets qui me passionnent. Les conférences étant non rémunérées, le choix a malheureusement été vite fait :-( Mais je ne perds pas espoir. Si c'est pour intervenir de temps en temps, et cela ne me prend pas trop de temps à préparer, je suis toujours partant.
[^] # Re: Yann Guidon
Posté par Tonton Th (Mastodon) . Évalué à 4.
/me pertinente. C'est un peu tard (quoique… :) pour le THSF 2015, mais l'année prochaine, Yann, tu seras le bienvenu à Toulouse.
[^] # Re: Yann Guidon
Posté par Yann Guidon (site web personnel) . Évalué à 4.
comme tous les ans ;-)
Je bosse "officiellement" sur http://ygdes.com/WizYasep/ et fin 2015 j'aimerais avoir une 2è génération encore plus puissante. C'est grâce à ces projets que j'aiguise les outils pour le YASEP et F-CPU. J'ai utilisé l'environnement du YASEP pour réaliser un vrai projet pro et je vais continuer de l'améliorer car c'est vraiment pratique !
Mais pour l'instant, ce qui paie mes factures c'est des ptits jobs comme https://www.facebook.com/101308076630787/videos/848924055202515/ et je me bats pour concilier les développements pro et perso. Au moins ça reste dans mon domaine, mais ça me saoule d'avoir plus de réputation dans le domaine des LEDs que des microprocesseurs -_-'
[^] # Re: Yann Guidon
Posté par Le Gab . Évalué à 2.
J'ai un linux mag avec un dossier sur VHDL et l'interview de Yann. :)
Mais à défaut de rencontrer l'ami Yann, y a t-il des ressources en lignes assez accéssibles sur le sujet?
[^] # Re: Yann Guidon
Posté par Yann Guidon (site web personnel) . Évalué à 1.
J'ai interviewé l'auteur de GHDL, c'est bien de cela qu'il s'agit ?
Allons bon, voilà maintenant que j'ai l'air inaccessible ? :-D
J'ai un atelier pas loin de la Porte de Pantin, il suffit de me contacter…
Pour les ressources, il y en a plein partout, le dossier VHDL que tu mentionnes est un petit pied à l'étrier.
# typo
Posté par Yann Guidon (site web personnel) . Évalué à 3.
écrire ou dormir, il faut choisir !
"pourquoi pas les faire travailler ensemble"
(désolé, j'avais pourtant relu et rerelu)
[^] # Re: typo
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Cartes FPGA
Posté par karteum59 . Évalué à 6.
Ce qui serait vraiment sympa (dans l'optique d'avoir plus de testeurs/contributeurs), ce serait que le FCPU puisse tenir sur un Xilinx Spartan6 LX9 pour fonctionner sur des cartes FPGA low-cost comme ceci ou ceci.
[^] # Re: Cartes FPGA
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est vraiment petit 1500 slices, 16 multiplication c'est pas mal par contre.
"La première sécurité est la liberté"
[^] # Re: Cartes FPGA
Posté par karteum59 . Évalué à 3.
Je manque d'expérience en ce domaine pour juger.
Sinon, il y a aussi le modèle à base de LX25 pour 105$… Plus réaliste ?
[^] # Re: Cartes FPGA
Posté par Yann Guidon (site web personnel) . Évalué à 2.
Oui c'est déjà un peu mieux :-)
Un F-CPU est quand même plus à l'aise avec plus de RAM et de bande passante. Par exemple http://m-labs.hk/m1.html commence à devenir confortable.
Actuellement je planche sur l'utilisation de http://emcraft.com/products/255 et un collègue prépare une version plus puissante (jusqu'à 4GB de DDR667). Là, ça commencera à devenir intéressant :-)
[^] # Re: Cartes FPGA
Posté par Yann Guidon (site web personnel) . Évalué à 5.
Pour les cartes low-cost avec un petit FPGA, c'est le YASEP qui convient. Il peut être configuré en 16 ou 32 bits et la densité d'instruction est meilleure, alors que le F-CPU est prévu pour des calculs sur 64 bits. Une telle largeur peut ralentir le CPU s'il faut passer par un bus mémoire plus étroit…
Au moins, en utilisant un environnement de conception unifié (pour configurer le matériel en fonction du code à exécuter, puis pour le simuler), l'architecture du cœur devient moins importante. Il sera bientôt facile d'essayer un morceau de code sur différentes architectures pour voir la taille du code généré, la vitesse d'exécution, les options à activer, les éventuelles extensions à créer… et juste avec des Logiciels Libres (car tout en Affero GPL V3, sauf les synthés proprios).
Ainsi ne se posera plus vraiment la question originale "Ce qui serait vraiment sympa, ce serait que le FCPU puisse tenir sur un XYZ". On code le cœur de l'application voulue puis on essaie avec différents paramètres (taille des registres, taille cache, type de cœur…), on simule, on profile, et on garde ce qui donne le meilleur encombrement de FPGA à performance donnée. Ou ce qui donne la meilleur performance brute. Ou ce qui consomme le moins. Ou…
# VHDL sous Linux?
Posté par Sylvain Briole (site web personnel) . Évalué à 3.
Je vois bien du côté du non-libre (e.g. ALTERA ou Xilinx), mais en libre?
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . Évalué à 7.
Ah, j'ai dit "sous Linux", j'ai pas parlé de libre (omission stratégique).
On a attendu presque une décennie pour que les outils proprios daignent être portés presque correctement sous nunux…
Donc effectivement, un outil de synthèse-placement-routage libre est un des derniers points critiques pour que ce soit complètement libre. Il est envisageable de générer des .edif avec un synthé open source, un jour, mais tout le reste dépend réellement du fabricant du FPGA, c'est un domaine ultra-propriétaire.
La seule solution est de créer des FPGA "Libres". Mais là cela dépasse largement mes attributions.
En attendant, le "moindre mal" consiste à accepter un petit bout de propriétaire, à condition que 1) on ne peut pas faire autrement 2) on évite au maximum d'utiliser des features trop spécifiques 3) on peut passer à la concurrence sans effort. Tout cela fait qu'il est possible de basculer partie par partie vers du réellement Libre lorsqu'il devient disponible, sans que cela freine l'ensemble du projet.
[^] # Re: VHDL sous Linux?
Posté par reynum (site web personnel) . Évalué à 2.
Choisir un FPGA qui ai de bonnes caractéristiques et faire un reverse engineering dessus, c'est pas valable comme solution ?
kentoc'h mervel eget bezan saotred
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . Évalué à 5.
Ben oui mais non…
Cela obligerait à s'investir dans une seule architecture propriétaire. Ce n'est pas bien pour la pérennité d'un projet. Pour libérer les utilisateur, il faut leur laisser le choix, donc leur permettre de passer d'une solution à une autre sans trop d'efforts.
Et puis on ne sait jamais ce qu'il pourrait arriver à la famille de puces qu'on a choisi. Il y a quelques années, la startup SiliconBlue avait sorti un FPGA sympa (bien que lent) et s'est faite racheter par Lattice, qui s'est empressé de jeter leur travail par la fenêtre. C'est mignon… Peu après, Actel s'est fait racheter par Microsemi et heureusement ils n'ont pas déconné avec, mais qu'est-ce qui les en aurait empêché ?
Aussi ce n'est pas dans les attributions du projet, qui est de concevoir un CPU et de libérer les utilisateurs. Et puis il faut choisir entre le reverse et la création. Il y a un projet qui a plus ou moins réussi à reverser (partiellement) un FPGA Xilinx mais idéalement, il faudrait (pour tout le monde) un FPGA Libre. Là, c'est un projet d'encore plus grande envergure que F-CPU…
Durs choix.
[^] # Re: VHDL sous Linux?
Posté par reynum (site web personnel) . Évalué à 2.
En fait oui au début (d'où le fait d'en choisir un qui ai un bon rapport prix/performance), une idée sous-jacente était de créer des outils permettant de plus facilement faire du reverse de FGPA et qui permettront ainsi de plus facilement d'en découvrir d'autres.
De plus comme il y a presque que 2 constructeurs de FPGA, Xilinx et Altera une fois qu'on en a reverse un les autres de la même marque devraient avoir beaucoup de points communs.
Ce n'était pas mon propos car j'essayais d'être réaliste ;-)
kentoc'h mervel eget bezan saotred
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . Évalué à 1.
Pour le reverse de bitstream, il y a eu qqs efforts, dont celui-ci mentionné sur un blog pointé plus bas :
http://www.fabienm.eu/flf/compiler-debit-sous-jessie-debian/ (il est dit que ça n'a pas bougé depuis 2008…)
Cependant, disposer d'un bitstream ne suffit pas, il faut ensuite faire toute la suite d'outils (synthèse, placement, routage, etc.) et cela nous éloigne trop de la conception d'architecture de CPU.
Et même si le reverse d'une puce permettait d'en reverser d'autres de la même famille, le temps d'y arriver, le fabricant aurait largement eu le temps d'introduire une nouvelle génération…
Mais depuis le temps qu'on en parle, il faudra bien y arriver un jour. I want to believe :-D
En attendant, j'ai deux CPU sur le feu et des clients qui attendent leur cartes /o\
[^] # Re: VHDL sous Linux?
Posté par reynum (site web personnel) . Évalué à 3.
Tu as bien raison, ça fait vivre.
J'espère que tu as prévu une protection thermique ;-D
kentoc'h mervel eget bezan saotred
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . Évalué à 2.
Promis, la prochaine fois j'installe des composants "plage de température industrielle" et pas commerciale. Comment ça, ça sent le vécu ? :-D
[^] # Re: VHDL sous Linux?
Posté par reynum (site web personnel) . Évalué à 4.
Tant que ça ne sent pas le brûlé ;-)
kentoc'h mervel eget bezan saotred
[^] # Re: VHDL sous Linux?
Posté par Astaoth . Évalué à 1.
Y a GHDL, et GTKWave pour voir les courbes des signaux de tes tests. Et bien sûr Emacs pour coder ton micro-processeur.
Emacs le fait depuis 30 ans.
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . Évalué à 3.
Je suis une nouille, je ne trouve jamais la touche Meta sur mon clavier alors j'utilise nano ;-)
Mais effectivement, GHDL et GTKWave sont vraiment des outils indispensables. Ce que je conçois avec fonctionne souvent dès le premier coup quand je le mets dans un FPGA. Je fais souvent le parallèle entre GCC et GHDL, l'un ayant permis la conception de Linux, l'autre permettant des processeurs libres. L'un comme l'autre changent toute la donne.
# Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 19 avril 2015 à 07:38.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: trop tard
Posté par Yann Guidon (site web personnel) . Évalué à 4.
Je suis d'accord sur le début.
Par contre la conclusion est excessivement simpliste.
# Graphique
Posté par claudex . Évalué à 6.
Attention, AMD a, pour l'instant, encore une avance sur les cartes graphiques, c'est ce qui leur fait gagner le marché des consoles (plutôt que d'avoir une solution non intégrée Intel et nVidia). Et là, pour les cartes graphiques libres, c'est un peu le désert en ce moment.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Graphique
Posté par Yann Guidon (site web personnel) . Évalué à 5.
Les cartes graphiques libres pour PC, effectivement, n'ont pas eu beaucoup de chance. Le seul truc à peu près valable a été opengraphics.org qui a fabriqué une belle carte à FPGA. Son générateur de timing programmable est une jolie invention.
Mais aujourd'hui le projet OpenGraphics s'est recentré sur https://github.com/jbush001/NyuziProcessor qui est un cœur de GPU open source.
Au fait il y avait un bruit comme quoi Samsung aimerait bien racheter AMD. De news à ce sujet ?
[^] # Electrochoc au pays du matin calme...
Posté par Rafael (site web personnel) . Évalué à 10.
Samsung s'est récemment émancipé, passant de "gros acteur has-been en voie d'extinction", à la position de leader technologique (mémoire UFS 2.0 jusqu'à 128Go, process de gravage 14nm maitrisé en volume dans son coin quand les autres galèrent, dalles AMOLED QuadHD consommant moins qu'en FullHD) pouvant même se permettre d'abandonner le jusque très récemment incontournable Qualcomm comme producteur de ses puces ARM haut de gamme pour ses flagships.
Samsung n'est pas qu'un médiatique producteur de smartphones. Ils savent produire des puces, des rams et des écrans. Justement, pour que les dalles mobiles restent fluides en très haute résolution, il manque aux procs samsung des GPU plus puissants.
Un rapprochement entre AMD/ATI et samsung aurait effectivement du sens, si NVIDIA, sentant le vent éventuellement tourner, n'avait pas pris les devant avec une possible collaboration orientée vers la production de puces gpu nvidia par samsung en techno FinFET 14nm selon le KoreaTimes.
Qui croire ?
Manifestement, AMD est à la ramasse techologiquement (en efficacité énergétique) et reste fort dépendante de TSMC pour la production (tout comme Nvidia jusqu'à ce jour, qui en souffre moins car ses puces sont thermiquement plus efficaces). TSMC peine à descendre en dessous de 20nm. En conséquence, les rats quittent le navire. Les rats sont nombreux, et les bateaux rares, donc les places vont être chères.
Nvidia cherche à gagner des parts de marché dans les procs à jeu d'instruction ARM dans le mobile, voulant jouer elle même la carte de l'efficacité des GPU, avec si possible la si_désirée finesse de gravure de 14nm, promesse de tant de succès. Le jeu du GPU qui pète des flammes, elle veut le jouer pour elle, et utiliser cette techno pour se faire sa place au soleil du marché des puces mobiles à jeu d'instruction ARM.
Pour l'heure, le marché, qui semblait figé encore récemment, semble se retourner. Apple mange dans la main de Samsung et paie sans doute le prix fort pour bénéficier en priorité de cette finesse de gravure, afin de ne pas se laisser déborder sur les plans de la vitesse et de la consommation. Cette excellence technologique est à même de garder le positionnement premium qui permet des tarifs de vente élevés. Si il n'y a que le design et le logiciel, le soufflé finira par tomber, et le staff d'Apple n'a pas tardé à prendre position.
Seuls Samsung (ainsi que GlobalFoundries qui a très vite scellé sa license samsung) et Intel maîtrisent le 14nm. Intel a effectivement sorti des puces Broadwell (x86) en 14nm, mais se débat sur le marché du mobile. Samsung a sorti ses Exynos 14nm en volume, démontrant son savoir faire technologique.
Il y a ceux qui peuvent le 14nm, et ceux qui regardent, ou qui paient.
Du coup, Qualcomm, très dépendant de TSMC, est en difficultés aussi, et ses actionnaires sentant le sapin pour la division CPU (TSMC bloqué à 20nm, chauffe des Snapdragon 810, obligation de re payer des licenses ARM pour le 64bit insuffisamment anticipé, perte partielle du sans doute plus gros client (Samsung), obligation de payer le prix fort de Samsung pour obtenir du 14nm) pressentent une scission de la compagnie entre les divisions CPU et modem mobile (toujours efficace sur le marché 4G).
Objectivement, Samsung dispose des arguments pour choisir ses clients (au prix fort) et ses partenaires. Racheter AMD ne lui poserait pas trop de problèmes (2 Milliards de $ de capitalisation boursière) mais il faudrait pour cela que le transfert technologique lui permette d'animer les dalles mobiles AMOLED à très haute résolution au moins aussi bien que ne lui permettrait le même type de transfert technologique de la part de NVIDIA.
Personnellement, j'ai sorti le popcorn. J'attends la suite du feuilleton, c'est pire que le Trône de fer. C'est passionnant, car manifestement en basculant de Qualcomm vers ses Exynos, le coût de production des Galaxy S6 aurait augmenté par rapport à l'iPhone 6, certes, mais la démonstration technologique permet à Samsung de maîtriser une part du prix de la production de son principal concurrent, Apple… Les dominos changent le sens dans lequel ils semblaient devoir tomber le mois dernier…
Mon avis: AMD racheté par Samsung ? Peut-être, car le prix est bas et les synergies sur les GPU (même en perte de vitesses) sont complémentaires. Que faire alors de la division CPU x86 en perte de vitesse également? Samsung a les atouts en main pour choisir et négocier. Les actionnaires de AMD doivent être prêts à tout pour sauver leurs billes, dans une perspective industrielle et de marché complètement défavorable. Samsung n'a qu'à les laisser venir montrer leurs cartes, à savoir, de quelles technologies GPU novatrices et CPU à jeu ARM (propre, pas la license ARM de base) AMD peut elle se prévaloir ? Dans tous les cas je ne donne pas cher de la peau d'AMD, qui a peut être encore des cartes à jouer dans ses labos de recherche pour que la synergie AMD/Samsung reste gagnant/gagnant. J'aimerais bien, mais je n'y crois pas. AMD, c'est 2x10⁹ de dollars de capitalisation. Samsung Electronics, telle que côtée à Londres (maia aussi à Séoul, à Berlin et Dusseldorf), c'est 214x10⁹ de dollars, 100 fois plus gros. Plus gros, et c'est sans parler les autres divisions de Samsung, qui courent de l'assurance aux climatiseurs, aux TVs, chimie, pharmacie, marine, automobile, il y en a de partout.
Le pays du matin calme a les moyens de nous étonner. Sa devise n'est-elle pas "Profiter largement à l'humanité" ?
[^] # Re: Electrochoc au pays du matin calme...
Posté par Yann Guidon (site web personnel) . Évalué à 3.
Je plussoie férocement.
Excellente lecture matinale !
# Court circuit
Posté par Guillaume Maillard (site web personnel) . Évalué à 5.
Désolé d'avance pour ce commentaire loin du "oh merveille".
Sortir un site de web de l'agonie est pour moi loin d'une prouesse, de plus faire comme ci des projets beaucoup plus avancés qui ont occupés une grande équipe d'ingénieurs et faire croire que faire dans son garage un processeur utilisable est tout simplement le plus gros pipo de l'année.
Avec vos FPGA vous n'irez nulle part, sinon AMD, INTEL, ARM et autres ne s’embêteraient pas à faire travailler des milliers de personnes pour améliorer leurs technologies et construire des usines hors de prix.
Un processeur open source 64bits ET performant existe : OpenSPARC (http://www.oracle.com/technetwork/systems/opensparc/index.html)
Personne pour vous le fabriquer, vous le livrer et vous fournir une belle carte mère qui va avec.
C'est une réalité technique et financière.
Si vous voulez vraiment quelque chose utilisable, arrêter de rever/coder/VHDLer, trouver plutôt des financements (quelques dizaines de millions) pour fabriquer votre variante de l'OpenSPARC et tous les chipsets nécessaires.
[^] # Re: Court circuit
Posté par Tonton Th (Mastodon) . Évalué à 2.
Ah oui, mais bon, Oracle, euh, comment dire…
[^] # Re: Court circuit
Posté par Guillaume Maillard (site web personnel) . Évalué à 3.
C'est des nuls, leurs processeurs ne fonctionnent pas correctement?
La licence libre de l'OpenSPARC n'est pas assez libre?
[^] # Re: Court circuit
Posté par Tonton Th (Mastodon) . Évalué à 6.
Je ne sais pas, tous mes
sparc64sont des originaux de chez Sun. Mais, entre autres choses, je reproche à Oracle d'avoir fossoyé (volontairement ou non ?) toutes les documentations techniques que l'on trouvait à l'époque sur les CPU et logiciels Sun.Je n'ai pas encore regardé ça en détail, mais la FAQ ne me semble pas très claire…
[^] # Re: Court circuit
Posté par bobo38 . Évalué à 3. Dernière modification le 19 avril 2015 à 23:20.
Oui, j'ai pensé à ça également après ma seconde lecture de l'article. Je pensais au LEON : http://fr.wikipedia.org/wiki/LEON
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . Évalué à 10.
Bonjour Guillaume et désolé d'avance pour ce commentaire loin du "oh le méchant troll". Au contraire, cela m'a mis de bonne humeur ce matin en le lisant :-) Et cela me donne aussi l'occasion de remettre quelques notions à leur place.
En effet. Vous êtes tellement plus fort que moi. J'aurais même dû mettre plus de temps et en faire moins. Mais j'ai été pris d'un accès d'efficacité. Peut-être un signe de geekonécrophilie. Promis, je me contrôlerai la prochaine fois.
où ai-je écrit cela ? Est-ce que je poste en étant somnambule ?
Si c'est pour faire référence au projet F-CPU tel qu'il s'est ankylosé en 2004, ce n'est pas la peine. Ce que je reprends c'est l'ISA et la microarchitecture du FC0 (dont je suis l'auteur majeur, alors je réutilise mon boulot, go and sue me). Le problème est que ce travail est indissociable de toute l'aura qui lui a donné vie. Et il y a aussi des gens qui ont aidé à l'époque, rien de plus normal que de les recontacter et de voir si on peut mieux s'organiser cette fois-ci. Si d'autres personnes sont intéressées et peuvent en bénéficier, encore mieux !
Ah aussi pour l'argument de la taille des équipes, ça ne marche pas toujours. Le fameux mémo d'IBM est un exemple
http://www.computerhistory.org/revolution/supercomputers/10/33/62
http://ibm-1401.info/Proposed-Supercomputer-Short-Tour.html
Evidemment cela n'implique pas qu'une équipe minimale fonctionne toujours (les exemples sont trop nombreux). Mais la taille devient souvent un handicap, à cause de l'inertie, de la politique, de la bureaucratie et du protocolisme.
Je suis déçu.
Outré.
Mon égo est blessé.
Cela manque… d'Ambition.
De Grandeur.
D'Envergure.
Le projet F-CPU est allé présenter ses travaux 4 fois à Berlin au CCC. Il a souvent été comparé au GNU Hurd, qui lui a fourni du code (je l'ai même vu planter).
Non, je suis désolé mais le F-CPU c'est le pipo de la décennie.
Mais de la décennie passée. F-CPU est un fantasme qui a été créé en 98 et entretenu entre autres par des personnes comme vous, une hallucination collective nourrie des frustrations d'innombrables geeks qui voulaient tout mais sans avoir à faire d'efforts. Quant il s'agissait de demander, de décréter, de bikeshedder, de troller, il y avait tout le temps quelqu'un. L'avis de tout le monde devenait parole d'évangile. Mais pour coder ?
Aujourd'hui, c'est fini. Cela fait depuis 2004 qu'il n'y a plus eu une seule contribution. Personne n'a levé le petit doigt en 10 ans. Je reprends mes billes et je les lance dans une autre direction. Peu importe si ça ne plaît pas à certains, rien ne les oblige à aimer, je ne force personne. Ils peuvent imaginer ce qu'ils veulent, pour ensuite montrer que c'est faux ou impossible, c'est vieux comme la rhétorique, ça les regarde.
ça dépend, puisqu'apparemment vous n'avez pas compris où je voulais aller.
Mais chaque chose à sa place. Le problème avec l'effet d'échelle est qu'il est impossible d'être bon en tout. On fait appel à moi parce que justement, ce que des gens veulent n'existe pas dans le commerce, probablement parce que les noms que vous citez ne bougeront pas le petit doigt en-dessous de dix millions de pièces.
Et si j'ai besoin des produits mainstream, je les achète. S'ils ne me conviennent pas, je me débrouille. Et tant pis si je me fais parfois traiter de traître à la cause parce que j'utilise des Raspberry Pi et sai pa libre(tm) :-D
oh, j'ai compris, c'est un concours de celui qui aura la plus grosse liste de CPU dont l'auteur aura mis le code source sur le net et démerdez-vous(tm)
Ah, là on commence à toucher le cœur du sujet, pour de vrai. D'ailleurs c'est marrant, cela fait 12 ans (Ô coïncidence) que je travaille sur ce petit détail et j'en ai fait mon activité professionnelle. Pour l'instant, je ne suis pas trop loin de ma roadmap et je vois déjà que, d'ici quelques temps, mon ch'ti 32-bits risque de ne pas suffire, avec les clients que j'ai. J'ai besoin de pouvoir répondre à un spectre de demandes de plus en plus large.
Vous mentionnez OpenSPARC, je suppose qu'il y a une certaine utilisation, un certain besoin, un certain environnement… un contexte particulier pour vous. Et je n'ai jamais dit que "mon projet est universel" et qu'il répondra à vos besoins personnels. Ce n'est plus le F-CPU de l'An 2000. Je vais peut-être choquer des gens mais je reprends mes billes parce que cela correspond à mes besoins. Ensuite si ça plaît à d'autres, j'en suis enchanté. On bénéficie du partage (normalement).
Ensuite si vous avez vraiment besoin de SPARC 64 bits, j'ai justement une Ultra10 (modèle Elite3D) qui a besoin d'un nouveau propriétaire. À venir prendre métro Hoche, Pantin. J'aime pas benner, alors à votre bon cœur. Merci pour elle !
en d'autres termes : "si on veut avancer, il vaut mieux s'immobiliser". Jolie logique. Tiens, je vais suivre votre conseil et retourner sous Windows :-)
Jolie logique, encore une fois. Et naïve ! On croirait presque qu'il suffirait de copier-coller le code source et ça marche et c'est concurrentiel. Je vois d'ici des milliers de startups qui vont fleurir d'ici demain.
Et puis quel intérêt ai-je à coller à vos attentes ? (Vous êtes dans la gestion, je suis dans l'industriel) Et qu'ai-je à faire d'une architecture ancrée dans le début des années 80 ? Et quel marché y a-t-il pour une architecture supportée juste par Solaris (donc intéressante uniquement pour les "grands comptes" pour maintenir leur "legacy" donc marché proche de l'inexistant, en dehors d'Oracle) ou Linux (c'est pas sexy, sauf pour les nerds) ? Et si c'est si facile, pourquoi ne le faites-vous pas ? Je suis sûr qu'on vous prêtera sans discuter dix millions d'Euros pour aller concurrencer Oracle. Il y a des milliardaires qui ont un grand sens de l'humour :-)
Cordialement !
[^] # Re: Court circuit
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 20 avril 2015 à 17:24.
Par curiosité, quel est le résultat de ces 12 années?
Par curiosité, quelle est cette roadmap?
Par curiosité, c'est quoi de "ch'ti 32-bits"? C'est libre? On peut en avoir un?
Ca serait pas la démonstration qu'être libre ne suffit pas, même pour un projet concret? Donc quelle cible pour ce CPU libre?
Je comprend Guillaume, car pour le moment, on a surtout du vent (un site web et rien d'autre) dans la dépêche, rien de nouveau (comme avec Hurd), donc bon, si il y a de quoi nourrir déjà une personne et des utilisateurs d'un CPU 32-bit (libre?), des cartes-mères (libres?), ça serait bien de nous tenir au courant!
J'avoue : je n'ai rien compris au site de YASEP, savoir ce qu'on pouvait avoir comme produit (libre?). Une dépêche en parle mais comme un "processeur‐jouet", et une recherche Google ne m'aide pas beaucoup (avec le site que je ne comprend pas et la dépèche LinuxFr comme truc pertinent, ha ouais, quand même ça doit être sacrément caché comme truc révolution, pour les initiés?), pas l'impression d'y trouver du vrai matériel et/ou une communauté. Bref, c'est où le concret qui va apporter quelque chose à l'humanité?
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . Évalué à 10.
(pardon pour le retard)
J'ai tout repris depuis zéro, en recommençant par le bas : faire des circuits imprimés, souder du QFP et du 0402 en série, gérer les clients, sous-traitants et fournisseurs, chiffrage… Je suis ainsi passé de "savoir" (l'époque de la sortie de fac où je tentais d'avancer sur F-CPU) à "savoir faire" en tant qu'électronicien indépendant, avec la réputation que quand j'accepte un projet, ça marche. bien.
Ce serait bien si ma réputation était de concevoir des microprocesseurs, mais on me demande surtout des systèmes avec des LEDs. Au début c'était gentil, maintenant c'est tellement énorme qu'il faut tendre du triphasé comme là https://www.facebook.com/video.php?v=821620654599522
Heureusement j'arrive à faire converger lentement mes intérêts. Résultat : http://ygdes.com/WizYasep/ est mon premier "produit sur étagère" à utilisations multiples, que je compte faire évoluer comme une sonde d'émulation. La génération 2 va apporter plus de puissance pour début 2016, et sera la base du processeur d'I/O de F-CPU (cf http://wiki.f-cpu.org/doku.php?id=f-gpu )
maitriser tous les process de fabrication de circuits numériques, en passant par l'analogique, le routage PCB, la gestion de projet… pour créer des plateformes aussi libres que possible d'ici 5 ou 10 ans. J'ai mes propres outils de FPGA depuis 5 ans, après avoir usé du microcontrôleur "tout fait". Maintenant, un FPGA de base me coûte presque un peu plus cher mais est 100x plus flexible donc je perds moins de temps à essayer de contourner par logiciel les limitations des architectures, je crée l'architecture autour du projet. De fil en aiguille j'ajoute des fonctions au YASEP, lorsque je rencontre des limites, ce qui fait que l'architecture est maintenant très très flexible. Ces outils vont bientôt intégrer l'architecture du F-CPU, ce qui permet de répondre à encore plus de besoins, sans être limité par le choix d'une puce toute faite.
le 32 bits est le YASEP, il est "petit" parce qu'il peut descendre à 16 bits sans effort, il est sous Affero GPL (je vois pas ce qu'il y a de plus libre, au sens FSF) et on peut en avoir un là : http://yasep.org/VHDL/
Le passage au jeu d'instructions définitif, il y a un an, a cassé pas mal d'outils, que je n'ai pas eu le temps de reconstruire, je préfère reprendre tout le code depuis 0 que de patcher à tout va.Donc pour l'instant c'est "bancal".
Pour ce qui est du site avant qu'il soit "cassé" par les évolutions un peu trop anarchiques, il a permis à un visiteur de créer ceci :
L'histoire est là : http://news.yasep.org/post/2013/07/26/There-is-always-crazier-than-you.
Donc je suis encore plus convaincu qu'en fournissant aux gens des bons outils, libres et accessibles, ils font du bon boulot, et je suis décidé à continuer à développer le système à fenêtres en JavaScript. Il a d'ailleurs rempli son rôle initial, qui était de permettre d'affiner le jeu d'instructions en le confrontant à une utilisation de plus en plus détaillée. A l'inverse, on avait écrit le jeu d'instructions du F-CPU "en l'air", sans rien pouvoir tester, donc sans vraiment savoir si chaque instruction avait vraiment un sens ou était correctement formée ou utilisée… ou même pratique.
En "portant" F-CPU sur l'environnement créé pour le YASEP, on va pouvoir revoir en détail le jeu d'instruction et le nettoyer pour qu'il soit efficace.
Regardez attentivement la page sur laquelle vous lisez ces mots. Observez les réactions, les incompréhensions, les attentes, les réalités de chacun…
J'ai fait le YASEP souvent à l'inverse de F-CPU. J'ai avancé seul, sous le radar, et je suis allé plus loin que F-CPU est allé "en communauté". Mais là, j'aimerais que plus de personnes participent. J'ai déjà quelques collaborations et une roadmap.
Autre chose ?
[^] # Re: Court circuit
Posté par Guillaume Maillard (site web personnel) . Évalué à 7.
Merci pour longue et élégante réponse!
Je ne mets en cause aucuns de vos besoins ni talents. Vivre de la création de CPUs customs est déjà un bel exploit (même si je suis plus tourné vers le monde du logiciel, souder du PIC, programmer un FGPA et faire tout un tas de sales choses à base de fer à souder, je maîtrise aussi).
Ce que je fais juste remarquer est qu'aujourd'hui, le problème d'un CPU opensource est principalement un problème économique car nécessite une grande équipe d'ingénieurs bien pointus et des moyens importants pour (faire) fabriquer le processeur, les chipsets et la carte mère. Un géant comme Apple s'y risque à peine.
Seul ou en bande organisée, mode travail du soir, je ne vois pas comment vous irez plus loin que du softcore en FPGA à quelques centaines de mégahertz.
Si on écarte vos niches industrielles, un processeur pertinent aujourd'hui doit au minimum dépasser les performances d'un téléphone de 3 ans d'âge.
Même si cela peut déplaire de l'entendre, un OpenSPARC en l'état est techniquement loin devant .
Personnellement, si un processeur "libre" 64 bits à plus de 40 GFlops existait aujourd'hui, je serais le premier à l'utiliser et travailler à temps plein sur son optimisations pour système comme Linux, FreeBSD ou HaikuOS.
Pour répondre au "si c'est si facile, pourquoi ne le faites-vous pas ?".
Je dirais que c'est exactement mon propos : c'est extrêmement difficile économiquement.
Polémique à part, il serait peut être bon de communiquer plus concrètement sur en quoi les puces de AMD/Intel/ARM ou projets comme LowRISC ou OpenSPARC sont inadaptées/obsolètes/lentes/chères par rapport à vos besoins/envies.
Cordialement,
```
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . Évalué à 7.
Bonjour,
Dire que j'en vis serait une exagération, mais à chacun sa vocation.
Ça dépend.
Une puce peut être conçue par une poignée de personnes expérimentées car les moyens de production et de conception sont maintenant le plus souvent séparés. Intel est la dernière exception.
hmmmm raté. Ils ont racheté des concepteurs de CPU pour faire leur propre ARM. La fabrication est ensuite sous-traitée à Samsung et/ou TSMC, je sais plus.
Souvenez-vous tout ce que vous avez pu réaliser à 10MHz. On est allés sur la lune avec moins que ça. Donc cela dépend vraiment de ce dont vous avez besoin. S'il faut aller plus loin, effectivement, il faut refaire toute l'équation économique, mais vous oubliez encore un détail : avant d'aller à 100MHz, il faut déjà que ça fonctionne et que tout l'environnement soit correctement dimensionné. Le souci de F-CPU est qu'il n'y avait rien autour. Donc je comprends qu'un CPU à 20MHz puisse sembler "ridicule" mais 1) il sert à quelque chose 2) c'est une étape qui permet d'aller plus loin, pas à pas. Cela veut dire qu'on maitrise toutes les technos en amont et en aval.
Pertinent pour quoi ? performance ? consommation ? écosystème logiciel ? Tout dépend du domaine. Et plus il y a de choix, mieux c'est.
40 GFLOPS ? d'où sortez-vous cela ?
Vous vous rendez compte que vous parlez d'un système qui concurrence ce genre de machine ? http://de.nec.com/de_DE/emea/products/hpc/sx-series/index.html
Alors demandez un système d'évaluation à NEC ? :-)
Mais honnêtement, que comptez-vous faire de 40 GFLOPS ? jouer à Crysis ? zoomer dans Mandelbrot toute la journée ?
Je ne pense pas qu'il soit bon, d'une part, de dire qu'une autre architecture n'est pas bien (la pensée négative n'est pas très utile), d'autre part de parler de mes besoins. Cela n'apporte rien à personne.
Ce qui est intéressant par contre c'est de montrer ce qui est possible et ce que j'ai fait, car d'autres personnes peuvent en bénéficier. On ne sait jamais. Évidemment je trouverai toujours les mêmes vieilles réponses inutiles mais parfois, un gars peut réserver une super surprise… La dernière fois était un code de Mandelbrot.
de même
[^] # Re: Court circuit
Posté par Guillaume Maillard (site web personnel) . Évalué à -1.
Quand je lis "CPU", je pense microprocesseur et non microcontrôleur.
Au risque de choquer encore, en 2015, un processeur c'est plutôt du 64 bits et des performances qui permettent de faire des choses basiques confortablement. Typiquement : affichage de pages HTML avec des mégas de javascript et décodage de vidéos H264, le tout sans mettre à genoux la machine.
Un CPU 16/32bits à 7 MHz, c'était génial en 1986 dans un Amiga qui avait des chipsets "mortels" pour l'époque.
En 2015, un bon micro contrôleur genre PIC32MZ2048ECH064 fait 11$ et tourne à 200MHz.
Pour la vélocité, 40 GFLOPS (SP), c'est assez standard. Un petit tour au supermarché et pour moins de 500€ vous l'aurez dans ordinateur complet.
Si l'on peut se fier à http://www.ocaholic.ch/modules/smartsection/item.php?itemid=1005&page=6 un processeur Intel Core i5 dépasse les 40 GFLOPS, et les i7 sont à plus de 100 GFLOPS.
Les bêtes de courses que sont les cartes graphiques dépassent pour 49€ les 150 GFLOPS (nVidia GT 610) et les grosses à 400 € (GT 970) dépassent les 3000 GFLOPS.
Le NEC SX a l'air sympathique mais un peu hors budget
Je comprends très bien que pour allumer des leds, quelques mégaHz suffisent et que cela vous permet de vous amuser à utiliser un FPGA en mode CPU.
Pour rebondir sur les affichages géants à base de leds que vous pilotez de belle manière, est-ce que la solution de considérer les leds comme un écran et de créer l'interface HDMI aurait été viable?
Cordialement,
[^] # Re: Court circuit
Posté par lasher . Évalué à 6.
Un CPU au sens de von Neumann, c'est une unité centrale de traitement. Du moment que tu as un jeu de registres, une UAL, un bus de contrôle, un autre de données (qui va en mémoire) et un bus d'E/S, tu as un CPU. Point.
Pour tout le reste, ce que je comprends de ce que tu dis c'est que tu veux un CPU multi-cœur, multithreadé, avec instructions vectorielles. Tes 40 GFLOPS en simple précision, tu ne les obtiens que parce que les codes concernés sont réguliers dans les accès de données, et que tu utilises un truc genre AVX qui permet d'effectuer une opération vectorielle sur 2 groupes de 8 éléments SP. Bref, tu parles de processeurs qui sont considérés comme haute-performance. Moi aussi j'adore ces trucs, c'est même mon métier de savoir les exploiter correctement.
Ça ne veut pas dire que tous les processeurs devraient fonctionner ainsi. En fait, l'une des raisons qui a fait que l'Atom et ses potes ont commencé commercialement, c'est bien à cause/grâce à l'OLPC, qui certes utilisait une IP proprio (clone x86 par AMD ou VIA, ARM, etc.), mais qui était abordable. La fréquence était de l'ordre de 400MHz (jusqu'à 1GHz pour les modèles haut de gamme), ce qui est relativement peu. L'important était la consommation d'énergie et de puissance, histoire d'avoir une durée de vie de batterie maximale.
Tiens, une dernière remarque: la première version de Blue Gene (BG/L) était basée sur des nœuds de type PowerPC à 700 MHz. La raison était toute simple : bien qu'IBM sut faire des processeurs bien plus rapides, la mémoire, elle, ne suivait pas. Et comme l'important dans un supercalculateur, c'est le parallélisme et des latences basses bien plus que la vitesse individuelle d'un cœur de calcul, ils ont préféré avoir un système dont la technologie était quasiment complètement synchrone : le bus mémoire tournait lui aussi à 700 MHz, et les réseaux d'interconnexion entre nœuds de calculs avaient une latence qui pouvait suivre ce genre de fréquence aussi. Au final, un aller-retour entre un processeur PowerPC et la RAM prenait exactement le nombre de cycles attendus pour charger une ligne de cache (32 octets, avec un bus de 32 bits → 8 transferts = 8 cycles). En couplant cela avec des instructions de préchargement, on avait des « quasi-garanties » de ne jamais avoir de bulles dans le pipeline, sauf en cas de vraie dépendance (read-after-write), et sauf mauvaise génération de code par le compilateur bien sûr. Pourtant, le POWER5 existait déjà, et offrait une puissance brute supérieure à ce pauvre PowerPC 440 (qui est une forme de processeur embarqué).
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . Évalué à 2.
En effet, il est important de comparer ce qui est comparable.
Un CPU SX est massivement vectoriel et parallèle. Faisons le calcul : à 2GHz, pour obtenir 64GFLPOPS, il faut 32 FLOP par cycle. Aucun CPU conventionnel n'y arrive, avec un tel parallélisme, et encore moins ne peut le soutenir à 90% pendant toute la durée d'exécution d'un programme. Dire "un i7 ou ma carte graphique y arrive" ne marche pas, car ce sont des multicœurs et les overhead de communication et tout le reste vont réduire la puissance effective.
Maintenant il est vrai que la consommation, le coût et la facilité de programmation sont des critères bien plus importants que la puissance brute. Même si cela ne l'est pas pour tout le monde. Dans une société abreuvée des derniers gadgets superpuissants, on en oublie à quoi sert vraiment cette puissance. Qu'est-ce qu'elle nous apporte ?
[^] # Re: Court circuit
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Je ne sais pas si c'est vrai, mais il semble que le taux d'usage des cpu dans les petits cluster x86 (~100 machines) ne dépasse pas 10% de taux d'occupation à cause de l'attente des transfert réseau.
En gros, dans les clusters x86, cela serait la latence des IO qui coince.
"La première sécurité est la liberté"
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . Évalué à 1.
Oui la latence I/O est vraiment critique. C'est pour cela que les ordis vectoriels sont encore utilisés : ils sont capables de réduire les effets de la latence de plusieurs manière.
Mais encore une fois cela dépend vraiment beaucoup du type d'algorithme, de la manière dont il est codé, et de comment il est utilisé, pour ne citer que quelques raisons de sous-efficacité…
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . Évalué à 3.
le souci avec le logiciel est qu'il a tendance à absorber toute les ressources dont il dispose. Et les utilisateurs s'habituent au confort. C'est dur à changer, les habitudes :-D
Le JavaScript n'est pas un langage parallèle, même si les WebWorkers sont un pas en avant. Le (dé)codage vidéo par contre est fait pour être "accélérable" et donc utiliser des circuits parallèles et plus ou moins spécialisés. Sinon, mplayer fait du bon boulot.
Mais cela reste deux applications différentes, avec deux caractéristiques de données, d'exécution, d'algorithme, de structures, de comportements très différents. Donc les solutions idéales sont différentes. Et des types d'applications, il y en a des millions ! Comment un programme en JavaScript pourrait-il utiliser 50GFLOPS ? (nombre totalement aléatoire, pour montrer qu'il n'a pas été fait pour ça, on prendrait du FORTRAN sinon, et que chaque langage a son domaine plus ou moins précis)
Pour ce qui est de F-CPU, il y a deux choses intéressantes à retenir : c'est d'abord un "vrai" 64 bits, pas un bricolage… Une partie de l'inspiration venant du DEC Alpha. Donc c'est prêt pour des grosses applications. Pour les "plus modestes", je planche sur une version réduite à 32 bits parce que honnêtement, le 64 bits est souvent overkill pour plein de trucs. Et en plus, des chemins de données plus larges ralentissent la fréquence d'horloge (idem quand on passe de 16 à 32 bits, c'est mécanique) et ça consomme plus si on n'utilise pas les bits de poids fort, par exemple (plein de changements d'états des fils qui ne servent pas vraiment). En tout cas, FC0 (le cœur de base) est prévu pour une bonne performance single-thread, soit le cas d'utilisation "JavaScript".
D'un autre côté, le jeu d'instructions du F-CPU est capable de gérer des données arbitrairement larges. Donc il peut être fabriqué avec des registres 256 bits ou 1024 bits, comme ça vous chante. Normalement, le logiciel ne nécessite même pas d'être recompilé s'il est correctement codé. On se retrouve dans le cas qu'on appelle de nos jours "GPU" ou "GPGPU". Les registres SIMD hyperlarges peuvent être réalisés de façon brute ou vectorielle ou entre les deux, selon les contraintes. Et rien n'empêche d'implémenter autant de cœurs qu'on le désire (à vous de vous débrouiller pour qu'ils ne meurent pas de faim, parce que ça consomme de la bande passante, ces bêtes-là)
C'est pour cela que j'ai resorti F-CPU de l'armoire : il est un bon cœur single-tread pour exécuter des applications classiques, et peut être étendu pour des applications intensives plus spécifiques. Contrairement à ce qu'il se passe sur un PC, il n'y a même pas besoin de changer d'environnement de programmation ou même d'outil, le jeu d'instruction reste identique et ainsi un programme peut être baladé d'un cœur à un autre, en fonction des instructions ou ressources d'exécution qu'il demande.
Quel ordinateur actuel migre dynamiquement un programme dans la carte graphique lorsqu'il se met à accéder intensivement à la mémoire vidéo ?
Il faut prendre les moyens de ses ambitions ;-)
Parce que ce n'est pas tout d'amonceler des unités de calcul sur une puce, il faut aussi ventiler toutes les données, et là, en dehors d'une utilisation purement vidéo, une carte vidéo ne donnera pas son plein rendement. La mémoire pose un problème énorme. Seymour Cray avait mis en place la règle que pour chaque FLOP, il fallait un mot de stockage et de bande passante… (un mot étant autour de 64 bits). Si on regarde l'exemple "(GT 970) dépassent les 3000 GFLOPS.", il y a juste 4GO de RAM, pas 3T mots… Pas étonnant que cela ne coûte "que" 400€.
D'un autre côté, un SX ne convient évidemment pas pour regarder une vidéo de youtube quand on est aux toilettes.
Quel problème essayez-vous de résoudre, pour quelle circonstance, pour quel type de LED, quel prix, quel coût de développement, quelle réutilisabilité/flexibilité… pour quel client ?
Dans les méga-écrans, de nombreux paramètres non triviaux interviennent, comme par exemple la distance. Un hypothétique signal HDMI (plusieurs paires torsadées avec un encodage totalement dingue à ultra-haute fréquence) arrivera à un endroit, pas forcément au milieu de la surface (les architectes et artistes n'ont que faire des contingences électroniques). Puis, après un peu de "magie" (transformer le HDMI en signal intelligible par les LEDs) il faut transporter ces signaux sur des dizaines de mètres (quand ce n'est pas centaines).
C'est le transport et la conversion qui posent problème. Pour le transport, le plus fiable, économique et efficace c'est Ethernet 100BaseT et il existe des modules qui convertissent directement du RJ45 en un flux de données encapsulées par UDP. Donc directement utilisables par un FPGA.
Pour la video, l'idée serait qu'on doit transformer du HDMI en Ethernet, mais pourquoi se casser la tête alors que tout ordi qui se respecte dispose déjà d'un port Ethernet ? Un hub et c'est réglé, pas besoin de se prendre le chou à convertir. De plus, programmer une socket UDP est très facile.
La carte WizYasep est donc flexible, réutilisable, reconfigurable, indépendante du système d'exploitation ou du type d'ordinateur, la fréquence de rafraîchissement est réglable… et le coût total du système est inférieur à une version nécessitant une conversion HDMI vers Ethernet. J'allais oublier : en cas de BSOD/KP, les visiteurs ne sont pas accueillis avec des disgracieux messages systèmes ;-)
[^] # Re: Court circuit
Posté par Guillaume Maillard (site web personnel) . Évalué à 0.
Humm… "Allo Intel, arrêtez vos bricolages avec vos Core i7 à 3 GHz, soyez un peu pro et flashez des softcores dans des FPGAs…"
Ce n'est pas parce que Yasep est réalisé en mode "pour le fun" qu'il faut se ridiculiser en tirant à boulets rouges sur ceux qui font (beaucoup) mieux que soit.
Je suis le premier à dire que ce que vous faites avec un FPGA est du super boulot, mais faut pas s'y croire pour autant.
Sinon, faut aller bosser chez AMD, ils doivent être preneur de technos qui ont le potentiel de leur donner un fort avantage concurrentiel.
Concernant les hypothétiques performances, j'attends avec impatience de voir le résultat du décodage H264.
Je n'ose même pas imaginer un benchmark entre un node.js sur processeur Intel "Brico" vs Yasep/FCPU !
Pour fun, un processeur Very-VLIW taillé pour digérer du code provenant d'un bytecode Java,
ca me parle beaucoup plus. Question de goûts.
La GT970 n'a pas besoin de 3 To de mémoire car elle mouline presque toujours les mêmes données (celle de la scene 3D)
pour l'afficher à diverses positions, angles, etc…
Ce n'est pas à quoi je pensais. J'envisageais plutôt de considérer la "grille" de led comme un écran standard.
Cad pouvoir utiliser le plein potentiel d'un ordinateur pour générer les animations, lire de la vidéo plutôt que de tout coder en dur dans un automate à état sur un processeur atypique.
[^] # Re: Court circuit
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il reste les anciennes couches sur les proc actuels. Intel les as justement viré sur les Xeon PHI. D'ailleurs, Intel voulait repartir de zéro avec l'Itanium et a du bricoler en urgence le jeux amd64 pour ne pas se faire manger… Sinon, le 8086 était le proc le plus pourris, bien plus merdique à programmer que le Z80 ou le 6502. Mais ce n'est pas toujours la meilleure solution qui gagne ;-)
Personnellement, je suis admiratif des ingénieurs d'Intel. C'était pas forcément évident de relever tous les challenges qu'ils ont eu depuis 40 ans… certes, ils ont les moyens.
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . Évalué à 3.
Bonjour,
Pour l'instant, c'est vous qui vous ridiculisez en tirant des conclusions sur des bases erronées (quelle qu'en soit la raison).
D'abord, je ne tire à boulets rouges sur personne ou rien : j'arrête depuis longtemps de me plaindre, ce qui explique le long hiatus de F-CPU, afin de mettre au point mes propres systèmes libres. Je les fais pour moi, mon boulot et parce que je le peux, et si ça intéresse ou aide d'autres, tant mieux, qu'ils se servent, c'est fait pour.
D'autres font mieux que moi, chacun son domaine, et quand je bosse, je prends ce qu'il faut pour le client, en laissant la philosophie derrière, car on me paie pour que ça marche(tm). Si un projet implique une techno que je ne maitrise pas ou qui ne m'intéresse pas, je peux confier le dossier à un collègue plus compétent. Je n'ai donc pas de comptes à régler avec Intel ou autre. Bon, je suis pas content de la fondation Raspberry Pi (ça se fait pas de foutre les clients dans la merde) et les prochaines cartes WizYasep remplaceront les Pi que j'ai déjà installés, donc râler est une perte de temps et d'énergie.
Ensuite, si vous relisez cette page, vous verrez que le YASEP est un tout petit 16-32 bits. Le comparer à un i7 à 3GHz est absurde, et vous me prêtez encore des intentions que j'ai déjà longuement contredites dans ce thread (qui commence à devenir long aussi). Et Intel fait ce qu'il veut, c'est le DOJ ou les actionnaires que ça regarde.
Aussi, Sytoka Modon a bien compris, lui, que lorsque je parle de "bricolage", c'est bien de l'architecture x86 et ses évolutions depuis le 8080 donc je parlais. Je ne vais pas répéter ce qui fait la réputation de cette architecture horrible, et même s'il y a eu des améliorations avec x86_64, ça reste… une horreur. J'ai arrêté de lire les interminables manuels avec l'arrivée du PII.
Enfin, vous citez "c'est d'abord un "vrai" 64 bits," et vous parlez du YASEP alors que le début de la phrase spécifie bien "Pour ce qui est de F-CPU". Ce n'est pas un bon moyen pour faire avancer le Schmilblick (euphémisme inside).
Ce qui revient à quoi, en pratique, matériellement ? Si la sortie vidéo standard est utilisée, donc il faut décoder le HDMI avant de l'envoyer par RJ45 vers les cartes wizyasep (qui sont conçues pour être plus puissantes que les cartes PixelPusher du commerce). C'est un appareil cher à concevoir en plus.
Ensuite si vous tenez vraiment à passer par l'écran du point de vue du logiciel alors allez lire dans la mémoire du framebuffer pour construire les paquets UDP.
Quel problème tenez-vous donc à résoudre ?
Les vidéos sont généralement pré-encodées dans un format adapté. Mais cela importe peu puisque chaque carte, qui contrôle une zone d'écran, reçoit les données en temps réel par Ethernet. Tant que l'ordre des pixels est bon, dans un paquet valide, la source importe peu pour cette carte. Ce peut être de la 3D temps réel, du H264, une caméra, un VJ,… Pour la carte c'est juste des octets à transformer en purée de bits.
Pardon ? Me suis-je exprimé si mal ? Ai-je mal compris ? Comment coderais-je "en dur dans un automate à état sur un processeur atypique" des vidéos comme celle-ci (un zoom très profond dans Mandelbrot qui dure 30s)
https://www.facebook.com/101308076630787/videos/848924055202515/
Des fois que ce ne soit pas encore assez clair : la carte wizyasep reçoit un flux UDP par réseau 100Base-T pour envoyer les valeurs de pixels sur une vingtaine de sorties séries asynchrones avec des timings très précis. La surface totale de l'écran est divisée en sections, avec chacune leur propre carte WizYasep. La source des données peut être n'importe quel type de machine qui streame les données sur le réseau. Un PC sous l'OS de votre choix ou une minicarte embarquable sous Linux (mon choix car plus fiable).
On va peut-être y arriver un jour.
[^] # Re: Court circuit
Posté par zurvan . Évalué à 2.
moi je trouve (comme sans doute beaucoup ici) que votre projet est super cool, même si ses possibilités dépassent mes maigres connaissances. Chacun a sa pierre à apporter à l'informatique libre quoi qu'il en soit.
Vous connaissez peut-être le Mist, c'est un boîtier fpga qui permet de recréer beaucoup de vieux ordinateurs (pour le coup bien ancrés dans les années 80) : atari st, amiga, c64, amstrad cpc, apple II, nes et beaucoup d'autres
http://www.harbaum.org/till/mist/index.shtml
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Court circuit
Posté par Guillaume Maillard (site web personnel) . Évalué à 3.
Mist est un peu différent, il s'agit d'émuler un existant (veillo mais à la pointe en son temps) avec des technologies récentes (FPGA).
On est plutôt dans le monde du reverse engineering, de la copie et des frontières de la légalité…
Créer un Amiga à partir d'une feuille blanche en 1986 nécessitait beaucoup plus d’efforts et de talents que de le copier avec le confort des outils actuels (logiciels et matériels).
L'Amiga restera pour moi la techno la plus révolutionnaire (à l'époque évidemment) que j'ai dans les mains ces 30 dernières années. Le prochain sera peut être un Occulus Rift :)
# VHDL ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 20 avril 2015 à 08:53.
Si le projet à 12 ans et qu'il a été débuté en Europe il n'y a rien d'étonnant à le voir écrit en VHDL. Il est vrai que GHDL est un très bon outil pour simuler du VHDL (je l'utilise tout les jours), mais il est lent. Tout comme icarus est lent pour le Verilog.
VHDL et Verilog ne sont pas des langages conçues à l'origine pour faire de la synthèse FPGA, se ne sont que des langages de simulation.
Quitte à reprendre tout de zéro, pourquoi ne pas passer sur les nouveaux langages de synthèse comme Clash, Migen ou surtout Chisel ?
Ces langages sont conçues pour la synthèse (synchrone) et permettent de développer des «IP» de manière beaucoup moins verbeuses en limitant les copier/coller. Et il n'est plus nécessaire de se taper du VHDL/Verilog pour les testbench.
Avec Chisel par exemple il est possible de générer
- soit un code synthétisable en verilog pour les outils privateurs habituels (ISE, Quartus, …)
- soit un modèle C++ pour la simulation. Le modèle C++ pour la simulation est nettement plus rapide que les simulateurs GHDL ou Icarus. On peut même envisager de «faire tourner» un programme sur le modèle en simulation (à quelques centaines de kilohertz au lieu des MégaHertz certes, mais c'est tout de même pas mal pour de la simulation).
Les outils du FPGA sont vieux. ils s'encroûtent. il faut faire la révolution et libérer les FPGA avec de nouveaux outils/langages !
J'ai plus qu'une balle
[^] # Re: VHDL ?
Posté par Yann Guidon (site web personnel) . Évalué à 4.
Pour ce qui est de GHDL, je suis d'accord pour le souci de la vitesse. Il parait qu'un backend LLVM est en chantier mais c'est loin d'être disponible. C'est pour cela que j'ai écrit des extensions à GHDL, dont une qui permet de centupler la vitesse de certains calculs : http://ygdes.com/GHDL/int_bool/ (voir Linux Mag il y a qqs années)
Donc j'aime GHDL pas pour la vitesse mais sa flexibilité. On peut lui ajouter des extensions en C et régler beaucoup de ses limitations. Bon aussi, la vitesse c'est quand même pas mal mais par rapport à l'état des outils en 2000-2002, on revient de loin ! Et, sans vouloir en rajouter sur le troll permanent Verilog vs VHDL, VHDL dispose depuis le début de possibilités énormes que Verilog rattrape seulement…
même pas. Au début VHDL servait juste à décrire les circuits (c'était requis pour fournir des composants à l'armée US). C'est naturellement qu'on a cherché à exécuter cette description, pour vérifier le fonctionnement, et on en est arrivé à la synthèse, il y a déjà bien longtemps. Aujourd'hui, la synthèse marche bien (tm) donc je ne vois pas de souci à utiliser VHDL. Même s'il est casse-coquille quand il s'y met. Il peut me prendre le chou pour des trucs basiques tout en me permettant de faire des choses super alambiquées et puissantes :-D
Il manque MyHDL dans la liste, à moins qu'il ait été renommé. J'ai vu aussi Migen (ayant des contacts avec
lekerneldepuis la présentation de http://ygdes.com/HSF2009/HSF2009_GPL.html ).Mais ce sont encore des langages de niche, non standardisés, en plein développement, il faudrait donc qu'un de ceux-cis prenne le dessus et devienne mainstream. Très peu de personnes parlent ces méta-langages alors que VHDL est enseigné en université et écoles supérieures. Pour un projet qui se veut "accessible", cela réduirait donc le nombre de personnes pouvant potentiellement contribuer. Surtout qu'il faudrait en plus installer des outils avec leurs dépendances, ce qui limite encore les utilisateur dans leur choix de système d'exploitation.
Ensuite, faire un simulateur C n'est pas vraiment un souci. Le piège est de vouloir "simuler vite" trop tôt, avant que l'ISA soit bien exploré et validé. C'est pour ça que je passe par un modèle en JavaScript. Même si c'est lent. Mais tant que l'ISA est en phase de définition, le temps de simulation reste encore inférieur au temps de codage… bon ensuite on peut se taper quelques délires aussi :-D http://news.yasep.org/post/2013/07/26/There-is-always-crazier-than-you.
Et le code JS peut générer et exporter des fichiers pour d'autres outils ou langages. De là, il n'y a qu'un pas pour générer automatiquement des vecteurs de tests. Pas qui a déjà été franchi pour le YASEP.
[^] # Re: VHDL ?
Posté par Yann Guidon (site web personnel) . Évalué à 3.
PS: merci pour le lien vers le blog, j'adore !
[^] # Re: VHDL ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 20 avril 2015 à 11:47.
C'est ouvert aux rédacteurs si tu veux soutenir la lutte n'hésites pas ;)
Pour MyHDL c'est vrai que je l'ai oublié, mais il est légèrement différent des trois cités. Les trois que j'ai cité se concentrent sur la conception de design synchrones, alors que MyHDL se veut un simple remplaçant de VHDL/Verilog en python. Ce qui est aussi très intéressant !
J'ai plus qu'une balle
[^] # Re: VHDL ?
Posté par Yann Guidon (site web personnel) . Évalué à 1.
J'aimerais soutenir, je suis à fond dans la lutte, mais je ne sais pas si écrire pour ce blog l'aidera vraiment :-D
# RiscV et LowRisc
Posté par SebastienV . Évalué à 6.
Dans la gamme des nouveaux jeux d'instructions, il y a le RiscV développé à Berkeley. Ce jeu d'instruction a l'air relativement équilibré et reste suffisamment ouvert pour permettre toutes sortes d'implémentations (du simple pipeline à 5 étages aux machines Out-Of-Order).
Ce jeu d'instructions devrait être utilisé dans le projet LowRisc pour faire un processeur physique qui soit accompagné de son code HDL si on fait confiance aux personnes qui manufacturent ce circuit.
[^] # Re: RiscV et LowRisc
Posté par Yann Guidon (site web personnel) . Évalué à 3.
En lisant le manuel de l'ISA de RiscV, j'arrêtais pas de me dire "Mais WTF ?" surtout à cause des formats d'instructions super longues qu'il prévoit. D'un autre côté, on voit bien que l'expérience des générations précédentes a été très bénéfique, surtout pour la densité de codage, par exemple la réduction la taille des instructions "classiques" de 32 à 30 bits sans vraiment réduire l'efficacité.
Toutefois, je cherche les réelles innovations. RiscV est très "poli", soigné, mais reste à la base une évolution logique de premiers MIPS, une architecture qui a 30 ans maintenant. J'aurais aimé voir plus de remise en question de certains principes de base, par exemple les mécanismes d'accès à la mémoire (qui sont restés les mêmes depuis le tout début). Les techniques d'écriture ou de lecture de la mémoire, ainsi que les sauts de programme, posent des soucis qui font boule de neige lorsque le cœur grossit, causant des délais de toutes sortes et occupant encore plus de place dans les circuits (prédiction de branchement, logique pour flusher le pipeline…)
F-CPU a exploré une alternative, YASEP va encore plus loin. On est au 21è siècle ou pas ? Ah oui mais on reste encore cloués à des méthodes et outils des années 80-90…
[^] # Re: RiscV et LowRisc
Posté par SebastienV . Évalué à 1. Dernière modification le 20 avril 2015 à 20:25.
Disons que les bits de libres te permettent de bidouiller des extensions contrairement au MIPS où l'espace d'instructions était totalement bouché. Heureusement par contre qu'il y a une spécification pour la partie entière et flottante. On peut donc se baser sur du GCC, LLVM et binutils pour utiliser des langages de plus haut niveau.
Il n'y en a pour ainsi dire pas. Ils comptent sur une base 'polie' pour pouvoir se faire des innovations du point de vue microarchitecture.
Les compilos C adorent les machines load/store. Je ne pense pas qu'il faille chercher plus loin. Quand on prend l'exemple du MSP430, GCC n'utilise pas le quart du tiers de tous les modes d'adressage disponible (après, bon le backend MSP430 de GCC est pas top-top), dans ce cas c'est vraiment de la place perdue sur le silicium.
[^] # Re: RiscV et LowRisc
Posté par Yann Guidon (site web personnel) . Évalué à 3.
Bonjour,
La version la plus à jour de la doc est là :
http://ygdes.com/~whygee/yasep2014/#!doc/reg-mem
Par contre d'autres parties du site sont cassées, c'est pour ça que j'ai laissé la version 2013 sur yasep.org. Bonne lecture !
[^] # Re: RiscV et LowRisc
Posté par SebastienV . Évalué à 2.
Effectivement pas mal comme idée, accéder à la mémoire par indirectement par registres. Ca me fait penser au PIC16F84 qui a un système similaire, il a un registre d'adresse et de données indirect. Point de vue compacité de code c'est pour moi similaire à une architecture load/store. Il faut relativement souvent fournir l'adresse également.
Tu n'es pas trop à l'étroit ? parce que 5 registres (10 si tu fais du parking) ça me parait un peu court. Mais c'est vrai que tu as la mémoire a coté pour bosser. Quelle est la latence d'accès à la mémoire vs les registres ?
J'ai pas cherché/trouvé le code VHDL pour voir comment tu avais architecturé ton pipeline par contre. Tu as une URL ?
[^] # Re: RiscV et LowRisc
Posté par Yann Guidon (site web personnel) . Évalué à 6.
bonsoir,
Seymour Cray faisait comme ça dans les années 60 : http://ygdes.com/CDC/cdc6600.html
Il y avait 7 registres données et 7 registres adresses, mais ces derniers, plus nombreux, étaient plus efficaces car le numéro de registre indiquait si c'était pour lire ou écrire. L'architecture mémoire du YASEP est différente donc j'ai dû simplifier. Tant que la latence mémoire reste faible, ça va encore, mais si on doit accéder à de la DRAM, il faudra coder plus astucieusement (mais ça a été fait pour ça au début, l'utilisation de SRAM interne rapide n'était même pas envisagée au début).
Oui mais le PIC16F n'a qu'un seul registre indirect. C'est absolument horrible. Les architectures suivantes en ont ajouté d'autres, parce qu'une pile câblée c'est gentil mais comment on fait du multiprocessing ? (réponse : on rame grave)
tout à fait.
C'est évidemment très short, mais au début c'était pas mieux. J'étais parti sur 8 registres et 4 paires A/D mais je me suis rendu compte que l'accès à la mémoire était plus important, donc j'ai gratté sur 2 registres normaux. Je continue de réfléchir à une architecture à 32 registres adressables pour lever cette limite :-)
Ensuite, le YASEP n'est pas fait pour du gros calcul mais pour du contrôle, donc si vous avez déjà utilisé un PIC16F vous avez déjà l'esprit suffisamment flexible (ou mal tourné) pour vous en sortir. Et puis il faudra faire un bon compilo.
sur les FPGA ProASIC3, avec le microYASEP (qui tourne à 20 MIPS) l'accès à un blockRAM interne est quasi immédiat.
Ensuite, rendre visible la mémoire au travers des registre, cela a deux avantages lorsque le système mémoire devient compliqué :
Cela permet de séparer les différents espaces mémoire. Avec 5 registres, on peut configurer la puce pour avoir 5 blocks différents, avec des propriétés et des attributions spécifiques. C'est super pratique, pas de contrôleur de bus qui va devoir multiplexer les bus, ou adapter les longueurs et les latences…
Cela permet aussi, grâce au parallélisme, de masquer par logiciel les latences de certains espaces mémoire. Un peu comme quand on codait le CDC6600. C'est de l'entrelacement logiciel. Il suffit de connaitre une adresse suffisamment à l'avance pour l'envoyer sur le registre d'adresse, on intercale ensuite un peu de boulot d'autre chose, et quand c'est fini, la donnée est disponible en lecture dans le registre de donnée. Donc même s'il y a plusieurs cycles de latence pour lire une DRAM externe, le cœur n'est pas bloqué, sans utiliser de mémoire cache ni de "Out Of Order".
oui, http://yasep.org/VHDL/
L'architecture du microYASEP est aussi expliquée par cette image http://archives.yasep.org/JMLL2012/slides/microYASEP1.png et détaillé par celle-ci
Le cœur est dans http://yasep.org/VHDL/microYASEP.vhd , c'est moins de 400 lignes qui reprennent bloc par bloc l'image ci-dessus. J'ai conçu ce biniou en 1 semaine, il a fallu un à deux mois pour le mettre au point, et je n'avais pas encore les outils que j'ai à présent. J'avais au moins pu faire une démo des outils fin 2012, avec un morceau de code écrit dans l'interface JS, simulé dedans, puis exporté dans le simulateur VHDL qui affichait exactement la même chose sur un autre écran.
La structure interne est expliquée en détail dans http://archives.yasep.org/JMLL2012/slides/ que je conseille de lire avant d'essayer de déchiffrer le VHDL. Il y a aussi la conf en vidéo et audio (2h) à http://archives.yasep.org/JMLL2012/ (le serveur cafouille un peu, F5 F5 F5 en attendant que je migre autre part)
Encore une fois, c'est grâce à la simplicité du YASEP que j'ai pu avancer seul si loin. La complexité du YASEP est équivalente à peut-être 1/10 de FC0… Mais FC0 ne pourrait pas avancer sans tous les outils que j'ai mis au point pour le YASEP, souvent en pensant à m'en servir pour F-CPU. Il était donc temps de commencer à unifier tout ce bousin :-P
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.