Dans cette catégorie, il existe également GHDL pour le langage VHDL.
Existe-t-il un comparatif entre Verilator et GHDL pour des benchmarks équivalents dans les deux
langages ?
Il n'existe pas de comparatif direct mais Verilator est plus rapide vu qu'il utilise un algorithme de scheduling statique des évenements contrairement à GHDL ou Icarus Verilog qui se base sur une liste d'évènements à venir.
Si verilator n'est capable de prendre en entrée que du Verilog synthétisable, c'est parce qu'il
convertit ce code en un objet en C++ et/ou SystemC
Je suis un peu étonné par cette phrase. Si le code Verilog est converti en C++, pourquoi serions-
nous limité à du code synthétisable ?
C'est un des choix de design de Verilator qui n'est pas lié a SystemC ou C++. Verilator a choisi de ne pas supporter certaines features du langage pour augmenter la rapidité.
Verilator gagne en performance du fait que la granularité des évènements est connue, il évalue le design uniquement sur un changement de clock. Il schedule et optimise les évènements intermédiaires à la compilation plutôt qu'à l'exécution.
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 ?
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é.
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.
Toutefois, je cherche les réelles innovations.
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.
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 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.
F-CPU a exploré une alternative, YASEP va encore plus loin. On est au 21è siècle ou pas ?
Oui, 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 ;)
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.
Il me semble que plus on porte de modifications au niveau mainstream, au moins de patchs on a à maintenir entre différentes versions de l'application et donc ça réduit effectivement les coûts…
Small embedded ça signifie encore un petit microcontrôleur qui peut aller partout. Avec son architecture simpliste,
c'est absolument pas prévu pour des hautes-performances, contrairement au OpenSPARC.
Il y a assez de petits microcontrôleurs bien mieux finis que celui-ci sur OpenCores (genre le OpenMSP430) qui a lui, l'avantage de déjà avoir une toolchain C complète.
Le problème est toujours le même, faire un compromis raisonnable entre la performance, la surface et la consommation. Puis il faut penser à ajouter aussi la composante prix dans le calcul.
Le YASEP rentre facilement dans un FPGA, l'OpenSPARC non à moins de l'estropier….
Même si l'environnement YASEP semble attrayant pour faire du développement de CPU, ça manque de flexibilité sur la manière d'architecturer le pipeline, s'il y en a un…
Oui, parallèle ou série, même combat. Quant à la taille du composant dont tu parles c'est quelques centaines de portes... Pas de quoi fouetter un chat...
Si tu peux les connecter au FPGA. Un convertisseur A/D série SPI marche nickel.
C'est un FPGA, pas un microcontrôleur. Rien ne t'empêche d'avoir une fréquence d'horloge pour le convertisseur très élevée, genre 50 MHz pour des convertisseurs 2x1MSPS.
Tu fais les conversions avec un ADC SPI connecté au FPGA, et tu génères les PWM avec le FPGA.
Si nécessaire, tu mets les régulateurs dans le FPGA ça te permet de réduire la latence au niveau de la régulation et le CPU ne te sert plus qu'à échanger des consignes et à la communication...
Si je ne me trompe pas, les licences GPL/LGPL s'arrêtent à la netlist. Dans ce cas, tu dois encore être compliant avec les licences vu que c'est un travail dérivé.
Après, une fois que tu passes en fondrie, ou sur un FPGA, y a plus rien moyen de prouver. On ne sait pas prouver l'équivalence entre du code HDL et le chip final. Donc, feel free to do whatever you want.
Je suspecte que c'est pour ça que Gaisler Research (CPU Leon2/3/4). On arrêté de lacher les sources pour le LEON4. Malgré le fait que le Leon3 soit GPL, personne n'a émis de travail dérivé (les sources HDL étant internes), on sort avec un chip fini et voilà, plus de GPL.
Hum, le gaspillage de transistor ici faut le chercher, c'est pas passer de 16 a 32 bits qui fait mal à la surface. C'est plutot les joyeusetés genre Branch Predictors, BTB, Out-of-Order...
Ici la principale cible est l'embarqué, cette architecture ne vise pas à s'implanter pour le moment sur les desktop même si ce n'est pas impossible comme on l'a vu avec le cas du Loogson.
L'industrie est malheureusement nécessaire pour appuyer une architecture. Personne n'est assez fou que pour jeter 35000$ minimum pour faire un IC à partir code disponible. Toute la différence entre le SW et le HW est là. Il faut valider le code HDL avant de le mettre en production parce qu'une fois que c'est fait si on s'est planté, on est bon pour tout recommencer.
C'est pour ça que les entreprises en général préfèrent payer cher pour des licences ARM (qui lui est vérifié en profondeur avec des garanties) que des OpenRisc (vérifié par une ou deux personnes sans aucune garantie).
Comparaison performance/prix. On n'en sait encore rien vu qu'on ne connait ni le type d'ASIC employés ni la fréquence du core qui va être atteinte.
Un processeur libre, basé sur une architecture libre. C'est un circuit intégré en soit. Il ne tourne sur rien du tout...
Toutes les applications embarquées sous Linux peuvent etre candidates pour utiliser ce CPU.
Ca fait des années que ce processeur existe. Rien que le fait qu'il soit mis en ASIC est un pas en avant vers une plus grande utilisation. Les sources sont disponibles dont meme dans 1 siècle, avec les outils de synthèse qu'il faut on pourra encore regénérer ce processeur. Il est écrit de menière à ne pas dépendre d'un quelconque fournisseur (FPGA specific ou dépendant des librairies de fondrie).
Ce projet est deja soutenu par des sociétés qui basent leur business sur les opencores en fournissant le support. Ceci dit ce processeur a quand même du mal a percer face aux ARM9 qui sont plus répandus et donc mieux supportés au niveau du port Linux ou GCC.
Il faudrait juste préciser que l'implémentation vise des applications embarquées et aurait des performances similaires aux ARM9. Pas d'infos sur la fréquence d'horloge du core. Surprise surprse :)
On en vient à la question qui tue: Qu'est ce qu'un microcontroleur ???
Un SoC ? Un microprocesseur non x86 ?
Pour moi ça reste un circuit intégré contenant un core, de la flash, de la ram et des périphériques intégrés... Et je vois assez mal Dalvik tourner sur un PIC :)
Sur un FPGA, OK à part que c'est super lent. Les ASIC, il y aura d'autres pour fabriquer des OpenSparc.
Si je ne me trompe pas ça fait un certain temps que la section microelectronique de Sun souffrait de problèmes financier. Je ne serais pas étonné que le developpement s'arrête :(. Oracle ne va probablement pas continuer là ou Sun avait deja du mal...
Dans vim, éditeur convivial, léger et qui est parfaitement en accord avec la philosophie UNIX (faire un truc mais bien ;)), le tabstop vaut deux :). 4 est encore tolérable mais les puissances de 2 au dessus ça ne le fait plus...
C'est à voir, s'il y a une disque SSD/Dur dedans. Si le bootloader sait charger le LK d'Android, il le peut pour n'importe quelle distro...
Toshiba même avec x86 ne respectent pas plus leurs acheteurs. C'est une marque à bannir tant que possible. Pourquoi pas aller vers un Lemote ? C'est du MIPS et tout est libre... même le bootloader (on ne peut pas vraiment parler de BIOS ici)
Et les réseaux citoyens (Wifi, Wimax) pour partager les données c'est bien aussi comme méthode de contournement, échanger les données de façon cryptée hors internet...
Encore plus dur à encaisser pour eux vu qu'il est pas encore interdit d'utiliser le Wifi :)
[^] # Re: Pourquoi seulement du Verilog synthétisable ?
Posté par SebastienV . En réponse à la dépêche Verilator 4.002. Évalué à 4.
Je confirme, cependant ton lien fait référence à un ancien projet qui n'a jamais abouti et qui est à l'abandon.
J'ai rebooté le projet verilator VHDL et je serais curieux d'avoir des testeurs :)
[^] # Re: Pourquoi seulement du Verilog synthétisable ?
Posté par SebastienV . En réponse à la dépêche Verilator 4.002. Évalué à 5.
Il n'existe pas de comparatif direct mais Verilator est plus rapide vu qu'il utilise un algorithme de scheduling statique des évenements contrairement à GHDL ou Icarus Verilog qui se base sur une liste d'évènements à venir.
C'est un des choix de design de Verilator qui n'est pas lié a SystemC ou C++. Verilator a choisi de ne pas supporter certaines features du langage pour augmenter la rapidité.
Verilator gagne en performance du fait que la granularité des évènements est connue, il évalue le design uniquement sur un changement de clock. Il schedule et optimise les évènements intermédiaires à la compilation plutôt qu'à l'exécution.
[^] # Re: Typo
Posté par SebastienV . En réponse à la dépêche Sortie d’Ubuntu 15.04. Évalué à 2.
Dernier paragraphe :
[^] # Re: RiscV et LowRisc
Posté par SebastienV . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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 SebastienV . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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.
# RiscV et LowRisc
Posté par SebastienV . En réponse à la dépêche Le retour de F-CPU, le processeur libre. É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: Réduction des coûts et Open Source
Posté par SebastienV . En réponse à la dépêche Opera Ice, nouveau brouteur à l'interface innovante, avec du Webkit dedans. Évalué à 1.
Il me semble que plus on porte de modifications au niveau mainstream, au moins de patchs on a à maintenir entre différentes versions de l'application et donc ça réduit effectivement les coûts…
[^] # Re: Je ne veux pas casser l'ambiance
Posté par SebastienV . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 7.
Small embedded ça signifie encore un petit microcontrôleur qui peut aller partout. Avec son architecture simpliste,
c'est absolument pas prévu pour des hautes-performances, contrairement au OpenSPARC.
Il y a assez de petits microcontrôleurs bien mieux finis que celui-ci sur OpenCores (genre le OpenMSP430) qui a lui, l'avantage de déjà avoir une toolchain C complète.
Le problème est toujours le même, faire un compromis raisonnable entre la performance, la surface et la consommation. Puis il faut penser à ajouter aussi la composante prix dans le calcul.
Le YASEP rentre facilement dans un FPGA, l'OpenSPARC non à moins de l'estropier….
Même si l'environnement YASEP semble attrayant pour faire du développement de CPU, ça manque de flexibilité sur la manière d'architecturer le pipeline, s'il y en a un…
[^] # Re: DEC, ARM
Posté par SebastienV . En réponse au sondage Le CPU de mon ordinateur principal est un:. Évalué à 6.
Les AMD64, ce sont les Intel ET AMD 64 bits de la famille x86/x86_64.
Les Intel64 ou IA-64 sont les Itanium...
[^] # Re: GPS et trace
Posté par SebastienV . En réponse à la dépêche Journey2web 0.4 : publier ses randos et ses voyages en images. Évalué à 1.
Les Garmin eTrex sont pas trop chers et paraissent pas trop mal supportés.
Plus d'info ici : http://www.gpsbabel.org
# Porter systemd
Posté par SebastienV . En réponse à la dépêche Concours linuxembedded.fr. Évalué à 2.
Il parraît d'après Lennert que ça boote plus vite que le reste :D
[^] # Re: Robotique ?
Posté par SebastienV . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 1.
Oui, parallèle ou série, même combat. Quant à la taille du composant dont tu parles c'est quelques centaines de portes... Pas de quoi fouetter un chat...
[^] # Re: Robotique ?
Posté par SebastienV . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 0.
Si tu peux les connecter au FPGA. Un convertisseur A/D série SPI marche nickel.
C'est un FPGA, pas un microcontrôleur. Rien ne t'empêche d'avoir une fréquence d'horloge pour le convertisseur très élevée, genre 50 MHz pour des convertisseurs 2x1MSPS.
Tu fais les conversions avec un ADC SPI connecté au FPGA, et tu génères les PWM avec le FPGA.
Si nécessaire, tu mets les régulateurs dans le FPGA ça te permet de réduire la latence au niveau de la régulation et le CPU ne te sert plus qu'à échanger des consignes et à la communication...
[^] # Re: GPL/LGPL
Posté par SebastienV . En réponse à la dépêche Levée de fonds pour la production d'un processeur libre. Évalué à 3.
Si je ne me trompe pas, les licences GPL/LGPL s'arrêtent à la netlist. Dans ce cas, tu dois encore être compliant avec les licences vu que c'est un travail dérivé.
Après, une fois que tu passes en fondrie, ou sur un FPGA, y a plus rien moyen de prouver. On ne sait pas prouver l'équivalence entre du code HDL et le chip final. Donc, feel free to do whatever you want.
Je suspecte que c'est pour ça que Gaisler Research (CPU Leon2/3/4). On arrêté de lacher les sources pour le LEON4. Malgré le fait que le Leon3 soit GPL, personne n'a émis de travail dérivé (les sources HDL étant internes), on sort avec un chip fini et voilà, plus de GPL.
[^] # Re: Béotian rahpsody
Posté par SebastienV . En réponse à la dépêche Levée de fonds pour la production d'un processeur libre. Évalué à 5.
Hum, le gaspillage de transistor ici faut le chercher, c'est pas passer de 16 a 32 bits qui fait mal à la surface. C'est plutot les joyeusetés genre Branch Predictors, BTB, Out-of-Order...
[^] # Re: Béotian rahpsody
Posté par SebastienV . En réponse à la dépêche Levée de fonds pour la production d'un processeur libre. Évalué à 7.
Ici la principale cible est l'embarqué, cette architecture ne vise pas à s'implanter pour le moment sur les desktop même si ce n'est pas impossible comme on l'a vu avec le cas du Loogson.
L'industrie est malheureusement nécessaire pour appuyer une architecture. Personne n'est assez fou que pour jeter 35000$ minimum pour faire un IC à partir code disponible. Toute la différence entre le SW et le HW est là. Il faut valider le code HDL avant de le mettre en production parce qu'une fois que c'est fait si on s'est planté, on est bon pour tout recommencer.
C'est pour ça que les entreprises en général préfèrent payer cher pour des licences ARM (qui lui est vérifié en profondeur avec des garanties) que des OpenRisc (vérifié par une ou deux personnes sans aucune garantie).
[^] # Re: Béotian rahpsody
Posté par SebastienV . En réponse à la dépêche Levée de fonds pour la production d'un processeur libre. Évalué à 4.
Comparaison performance/prix. On n'en sait encore rien vu qu'on ne connait ni le type d'ASIC employés ni la fréquence du core qui va être atteinte.
Un processeur libre, basé sur une architecture libre. C'est un circuit intégré en soit. Il ne tourne sur rien du tout...
Toutes les applications embarquées sous Linux peuvent etre candidates pour utiliser ce CPU.
Ca fait des années que ce processeur existe. Rien que le fait qu'il soit mis en ASIC est un pas en avant vers une plus grande utilisation. Les sources sont disponibles dont meme dans 1 siècle, avec les outils de synthèse qu'il faut on pourra encore regénérer ce processeur. Il est écrit de menière à ne pas dépendre d'un quelconque fournisseur (FPGA specific ou dépendant des librairies de fondrie).
Ce projet est deja soutenu par des sociétés qui basent leur business sur les opencores en fournissant le support. Ceci dit ce processeur a quand même du mal a percer face aux ARM9 qui sont plus répandus et donc mieux supportés au niveau du port Linux ou GCC.
[^] # Re: Bien bien
Posté par SebastienV . En réponse à la dépêche Levée de fonds pour la production d'un processeur libre. Évalué à 8.
Quelques autres petites infos,
5 Stages pipeline.
8K I et 8K D Cache (Direct Mapped).
Instruction set largement inspiré du MIPS.
[^] # Re: Qui va fondre la puce ?
Posté par SebastienV . En réponse à la dépêche Levée de fonds pour la production d'un processeur libre. Évalué à 2.
Probablement des asiatiques (TSMC, UMC, ...), mais sans certitudes.
# Bien bien
Posté par SebastienV . En réponse à la dépêche Levée de fonds pour la production d'un processeur libre. Évalué à 5.
Il faudrait juste préciser que l'implémentation vise des applications embarquées et aurait des performances similaires aux ARM9. Pas d'infos sur la fréquence d'horloge du core. Surprise surprse :)
[^] # Re: document officiel de la plainte de Gemalto
Posté par SebastienV . En réponse à la dépêche Revue de presse de l'April pour la semaine 43 de l'année 2010. Évalué à 2.
Un SoC ? Un microprocesseur non x86 ?
Pour moi ça reste un circuit intégré contenant un core, de la flash, de la ram et des périphériques intégrés... Et je vois assez mal Dalvik tourner sur un PIC :)
[^] # Re: Sparc
Posté par SebastienV . En réponse à la dépêche Le rachat de Sun par Oracle : 18 mois plus tard la méfiance s'installe. Évalué à 1.
Si je ne me trompe pas ça fait un certain temps que la section microelectronique de Sun souffrait de problèmes financier. Je ne serais pas étonné que le developpement s'arrête :(. Oracle ne va probablement pas continuer là ou Sun avait deja du mal...
# Tabstop=2
Posté par SebastienV . En réponse au sondage La taille de l'indentation de mon code source (tab ou espace). Évalué à 2.
[^] # Re: Bootloader
Posté par SebastienV . En réponse à la dépêche blogARM.net organise une pétition pour avoir un Linux sur l'AC100. Évalué à 1.
Toshiba même avec x86 ne respectent pas plus leurs acheteurs. C'est une marque à bannir tant que possible. Pourquoi pas aller vers un Lemote ? C'est du MIPS et tout est libre... même le bootloader (on ne peut pas vraiment parler de BIOS ici)
[^] # Re: Chiffrement des données
Posté par SebastienV . En réponse à la dépêche Le Parlement Européen adopte le rapport Gallo pro-ACTA. Évalué à 1.
Encore plus dur à encaisser pour eux vu qu'il est pas encore interdit d'utiliser le Wifi :)