Merci encore pour le lien, je viens de découvrir et installer SRecord :-)
Je vais voir s'il peut ajouter un filtre pour importer/exporter du JSON et mon format .HYX.
En effet, encore eût-il fallu qu'il fût vraiment libre.
Jamais sur le site de gnu.org on ne verra de download conditionné à l'ouverture d'un compte ("je vous ajoute du spam avec tout ça ?") ou de bannières publicitaires.
Ce que je désire lancer avec FHWD.org c'est quelque chose entre gnu.org (concerné par la liberté dans tous ses états) et opencores (qui, même si il héberge gratuitement des designs numériques "open source", ne correspond pas à ma définition de "Libre" puisque déjà il faut s'inscrire pour télécharger quoique ce soit, je pense que c'est même à la limite du site commercial et ça n'a plus rien à voir avec les origines du site).
Donc BAud je ne me sens pas vraiment concerné par h-node.org ou coreboot car ce sont des initiatives logicielles pour pouvoir tourner sur du matériel qui est essentiellement non libre. C'est important pour l'instant car il n'y a plus vraiment d'alternative aux PC (Je viens de confier mes SUN à un collectionneur et mes Alpha ne sont plus en état de marche…). Il faut donc vraiment créer cette alternative et elle ne peut pas se fonder sur du x86 ou du ARM. Pour y arriver, j'essaie de constituer une plateforme permettant à chacun de concocter son propre ordinateur libre, ou d'améliorer celui de son voisin, une sorte de "online Libre computer construction kit"…
http://opencollector.org/ a fermé il y a plus d'un an maintenant, il collectionnait des liens vers des projets d'Open Hardware, cependant c'était juste une collection et pas dans l'idée que les projets puissent fonctionner ensemble. Opencores essaie d'uniformiser un peu mais c'est plus pour faciliter la vie de quelques concepteurs de matériel embarqué ou industriels. Bref, je sens qu'il y a un gros manque.
Bien sur ici on ne parle pas vraiment de hardware libre
Oh si, il s'agit tout à fait de la réelle problématique du Hardware Libre : une limitation arbitraire et à sens unique de la liberté d'utiliser le matériel qu'on achète.
Le Logiciel Libre et le Hardware Libre sont les deux faces d'une même médaille, l'un ne va pas sans l'autre. Oui je me répète ;-)
Beaucoup me disent que je réinvente la roue, ce qui existe déjà "suffit" mais c'est aussi eux qui m'appellent quand "ça marche plus"…
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é…
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 soi*t*.
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).
J'envisageais plutôt de considérer la "grille" de led comme un écran standard.
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 ?
générer les animations, lire de la vidéo
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.
plutôt que de tout coder en dur dans un automate à état sur un processeur atypique.
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).
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.
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
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.
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 ?
Le NEC SX a l'air sympathique mais un peu hors budget
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.
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?
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 ;-)
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 ?
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).
Ca me fait penser au PIC16F84 qui a un système similaire, il a un registre d'adresse et de données indirect.
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)
Point de vue compacité de code c'est pour moi similaire à une architecture load/store. Il faut relativement souvent fournir l'adresse également.
tout à fait.
Tu n'es pas trop à l'étroit ? parce que 5 registres (10 si tu fais du parking) ça me parait un peu court.
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.
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 ?
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".
J'ai pas cherché/trouvé le code VHDL pour voir comment tu avais architecturé ton pipeline par contre. Tu as une URL ?
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
Vivre de la création de CPUs customs est déjà un bel exploit
Dire que j'en vis serait une exagération, mais à chacun sa vocation.
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.
Ç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.
Un géant comme Apple s'y risque à peine.
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.
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.
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.
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 .
Pertinent pour quoi ? performance ? consommation ? écosystème logiciel ? Tout dépend du domaine. Et plus il y a de choix, mieux c'est.
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.
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 ?
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.
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.
Par curiosité, quel est le résultat de ces 12 années?
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 )
Par curiosité, quelle est cette roadmap?
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.
Par curiosité, c'est quoi de "ch'ti 32-bits"? C'est libre? On peut en avoir un?
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 :
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.
ha ouais, quand même ça doit être sacrément caché comme truc révolution, pour les initiés?
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.
par contre je n'ai pas encore vu de plus près les techniques d'accès mémoire pour le YASEP, j'y jetterai un coup d'oeil avec grand intérêt plus tard ;)
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.
Sortir un site de web de l'agonie est pour moi loin d'une prouesse,
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.
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
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
Last week Control Data… announced the 6600 system. I understand that in the laboratory developing the system there were only 34 people including the janitor. Of these, 14 are engineers and 4 are programmers. Contrasting this modest effort with our vast development activities, I fail to understand why we have lost our industry leadership position by letting someone else offer the world's most powerful computer. – Thomas J. Watson, Jr.
It seems like Mr. Watson has answered his own question. – Seymour Cray
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.
est tout simplement le plus gros pipo de l'année.
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.
Avec vos FPGA vous n'irez nulle part,
ça dépend, puisqu'apparemment vous n'avez pas compris où je voulais aller.
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.
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
Un processeur open source 64bits ET performant existe : OpenSPARC
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)
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.
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 !
Si vous voulez vraiment quelque chose utilisable, arrêter de rever/coder/VHDLer,
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 :-)
trouver plutôt des financements (quelques dizaines de millions) pour fabriquer votre variante de l'OpenSPARC et tous les chipsets nécessaires.
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 :-)
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…
Ce n'était pas mon propos car j'essayais d'être réaliste ;-)
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\
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…
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.
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
Clash, Migen ou surtout Chisel ?
Il manque MyHDL dans la liste, à moins qu'il ait été renommé. J'ai vu aussi Migen (ayant des contacts avec lekernel depuis 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 enplus 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: hcl : liste de matériel conforme
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 1.
Merci encore pour le lien, je viens de découvrir et installer SRecord :-)
Je vais voir s'il peut ajouter un filtre pour importer/exporter du JSON et mon format .HYX.
[^] # Re: Computer Construction Kit
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 2.
En effet, encore eût-il fallu qu'il fût vraiment libre.
Jamais sur le site de gnu.org on ne verra de download conditionné à l'ouverture d'un compte ("je vous ajoute du spam avec tout ça ?") ou de bannières publicitaires.
[^] # Re: hcl : liste de matériel conforme
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 1.
Ah donc c'est un 8051 + DSP, pas un DSP de type "8051" ni un µC 8051 affublé d'un MAC :-D
[^] # Re: hcl : liste de matériel conforme
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 1.
?
[^] # Re: et ca marche ?
Posté par Yann Guidon (site web personnel) . En réponse au journal Qualcomm & les drones & Ubuntu. Évalué à 1.
Bombe intelligente, vous dites ?
Il y a 40 ans le problème était déjà à l'ordre du jour, quand ils ont filmé ce petit bijou :
Dark Star (1974): Phenomenology and the End (YouTube)
IA : Intelligence Artificielle. Ou Idiotie Artificielle, c'est selon :-)
# Computer Construction Kit
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 2. Dernière modification le 16 septembre 2015 à 13:33.
Cory Doctorow s'était penché sur la question du "bouclage" des plateformes en 2012 lors de cette présentation au CCC : https://boingboing.net/2012/01/10/lockdown.html
Ce que je désire lancer avec FHWD.org c'est quelque chose entre gnu.org (concerné par la liberté dans tous ses états) et opencores (qui, même si il héberge gratuitement des designs numériques "open source", ne correspond pas à ma définition de "Libre" puisque déjà il faut s'inscrire pour télécharger quoique ce soit, je pense que c'est même à la limite du site commercial et ça n'a plus rien à voir avec les origines du site).
Donc BAud je ne me sens pas vraiment concerné par h-node.org ou coreboot car ce sont des initiatives logicielles pour pouvoir tourner sur du matériel qui est essentiellement non libre. C'est important pour l'instant car il n'y a plus vraiment d'alternative aux PC (Je viens de confier mes SUN à un collectionneur et mes Alpha ne sont plus en état de marche…). Il faut donc vraiment créer cette alternative et elle ne peut pas se fonder sur du x86 ou du ARM. Pour y arriver, j'essaie de constituer une plateforme permettant à chacun de concocter son propre ordinateur libre, ou d'améliorer celui de son voisin, une sorte de "online Libre computer construction kit"…
http://opencollector.org/ a fermé il y a plus d'un an maintenant, il collectionnait des liens vers des projets d'Open Hardware, cependant c'était juste une collection et pas dans l'idée que les projets puissent fonctionner ensemble. Opencores essaie d'uniformiser un peu mais c'est plus pour faciliter la vie de quelques concepteurs de matériel embarqué ou industriels. Bref, je sens qu'il y a un gros manque.
[^] # Re: hcl : liste de matériel conforme
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 4.
plussage
(et pas que pour le poulpage)
[^] # Re: Actualité
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 3.
Oh si, il s'agit tout à fait de la réelle problématique du Hardware Libre : une limitation arbitraire et à sens unique de la liberté d'utiliser le matériel qu'on achète.
Le Logiciel Libre et le Hardware Libre sont les deux faces d'une même médaille, l'un ne va pas sans l'autre. Oui je me répète ;-)
Beaucoup me disent que je réinvente la roue, ce qui existe déjà "suffit" mais c'est aussi eux qui m'appellent quand "ça marche plus"…
[^] # Re: hcl : liste de matériel conforme
Posté par Yann Guidon (site web personnel) . En réponse au journal Free HardWare Designs : le site !. Évalué à 4.
Ah ben tiens, après les ordinateurs libres, va falloir en plus faire des imprimantes libres.
Ironique, si on considère que la FSF a été créé suite à un problème d'imprimante :-D
Qui s'y colle ?
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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: Ah on voit les classes moyennes et hautes qui se détachent
Posté par Yann Guidon (site web personnel) . En réponse au sondage Mon processeur préféré ?. Évalué à 5.
D'après ce que j'ai entendu, le Z80 et le MC68000 ont en commun de travailler par mi-mots.
Le z80 est un 8 bits en interne et l'ALU est sur 4 bits, il faut 2 cycles pour traiter un registre entier.
Le 68000 avait un chemin de données sur 16 bits en interne et nécessitait 2 cycles aussi.
Ensuite… ben voilà, une petite "trivia" pour le week-end :-D
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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 Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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 Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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: RiscV et LowRisc
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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
[^] # Re: Court circuit
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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 Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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: RiscV et LowRisc
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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: Electrochoc au pays du matin calme...
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 3.
Je plussoie férocement.
Excellente lecture matinale !
[^] # Re: VHDL ?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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: Court circuit
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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 ?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 3.
PS: merci pour le lien vers le blog, j'adore !
[^] # Re: VHDL ?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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.