ben c'est vrai que c'est pas facile.
Heureusement que pour ma première installe,
quelqu'un m'a aidé ! ensuite, j'ai continué
tout seul, en lisant le book et en faisant
gaffe, et ça a marché. Je ne le recommande
pas au premier newbie venu, ça demande du
temps et le goût spartiate, mais ça marche
et ça démystifie beaucoup de chose, ça
m'a rendu fier comme un coq sur le coup :-)
demandez sur la tribune, j'en ai oublié
la Red Hatte :-)
Par contre, un newbie sera dégoûté à vie,
s'il n'est pas déjà découragé par la taille
du Book (17K lignes).
moi j'ai juste un vieux graveur plextor et
j'ai installé la LFS de LM de mars,
ben j'ai mis 18h en tout ! les noms des fichiers
étaient presque tous altérés, je me suis fait
avoir, quoi (alors que l'archive TAR était
OK, mais alors pourquoi avoir foutu 2x la même
chose ???)
mais en tout cas, j'ai pu booter, j'avais
pris la précaution de charger le BOOK de la
3.2.
l'avis d'un mec qui est sensé s'y connaitre :
(du moins, qui a pas trop séché ses cours)
- esthétiquement : cool, il y a un quelque chose, sobre et pas exubérant.
- bruit : comme écrit plus haut, ça doit pas être amusant :-(
* je recommande l'utilisation de ventilos "silencieux" :
je ne suis pas spécialiste mais j'en ai un dans un tiroir.
de fabrication Suisse, 100 balles, pas un bruit, mais le
format et le débit ne sont peut-être pas adaptés.
* En plus, des disques durs identiques côté à côte,
ça crée des problèmes en basses fréquences car les vitesses
de rotation proches peuvent engendrer des harmoniques.
-> découpler les éléments mobiles en les éloignant,
les orientant de manière perpendiculaire et mettre des
amortisseurs en mousse pour éviter que les vibrations
ne se propagent dans la boite et fassent résoner tout
avec.
- Electriquement : la CEM (Compatibilité ElectroMagnétique,
ou l'interaction entre appareils par les champs magnétiques,
les champs électriques et les ondes électromagnétiques)
ne semble pas idéale. D'une part, la densité (34cm^3) est
telle que les champs ont une forte intensité. Je ne vois aucun
blindage entre les différentes cartes. De plus, le néon
"crache" plein de saloperies HF et le plexiglas laisse passer
(ou entrer, selon ce qui gêne le plus) les champs
magnétiques et électromagnétiques externes. Là, la solution
c'est de mettre une grille métallique fine, connectée à la masse.
Ca laisse passer une partie de la lumière mais la longueur d'onde
(même à 1GHz) des perturbations ne peut pas passer.
J'ai aussi appris en cours cette année que le meilleur "isolant
électromagnétique" est le feuillard en cuivre, s'il est correctement
posé. Il doit former une boucle autour de l'appareil pour que le
champ électromagnétique induise un champ inverse dans la boucle,
les deux champs vont donc s'annuler (c'est le principe du câble
coaxial :-D). Le cuivre conduit beaucoup mieux le courant que
l'aluminium ou l'acier, la perte (par effet Joule) du champ induit
dans le blindage est plus faible et le blindage est bien plus
efficace.
Pour terminer sur "le bon boulot bien fait par des ingénieurs
qui connaissent leur métier", je conseille de jeter un coup
d'oeil sur la fabrication des serveurs (SUN, DEC-ALPHA...).
Par exemple, un ALPHAserver DS20 est une vraie oeuvre d'art,
pas comme les PC... Blindage dans les règles de l'art,
circuit imprimé multicouche (pas du 4 couches "made in China"),
composants de qualité, bref, ça vaut le prix que ça vaut.
Pour le prix de la folie, j'ai probablement une photo de
boite PC en légo, vue au 17C3 à Berlin (rencontre CCC de décembre 2000).
Il y avait aussi la photo de la boite de PC dans le pack de bière,
trouvé il y a qqs jours en glandant sur un site...
l'URL doit être trouvable en demandant aux moules, je crois que DVA était là.
Quant à mon pécé à moi, demandez à trollhunter dans quel état lamentable il est...
Sans dec', utiliser NT et netscape et se dire défenseur du 100% GPL c'est du foutage de gueule.
déjà, Nicole est sous W95 et attends de la voir pour comprendre. Déjà c'est pas une linuxienne "hacker" mais elle sait quand même faire la différence entre ce qui est libre et ce qui l'est pas. Le petit problème c'est qu'entre envoyer des cartons de papiers à Boston pour la revue de presse de la FSF et organiser 2-3 assos loi 1901 sur le libre, elle a pas le temps de configurer sa babasse.
Regarde-moi : je développe seulement du code sous GPL avec Linux, et quoi ? j'ai la flemme de configurer ma babasse pour le net alors je boote sous W95/netscape 4.51. ET ALORS ?
9wm ro>><<or ! The 9wm Page @ http://dhog.g7.org/dhog/9wm.html
Ca se compile en lisant le Readme, ca prend 50KO et c'est tout.
Ensuite, si vous mettez une JPG d'1MO en fond d'ecran (avec xv -root -quit image.jpg) c'est votre probleme.
plop !
je sais que tu ne le pensais pas comme ça en l'écrivant mais ...
Ceci dit, c'est sympa de se fatiguer a faire des coeurs libres, ca manquait. Mais ne faites pas l'erreur de viser le processeur de station de travail, ca n'interesse en fait que les geeks soft qui ne comprennent pas l'absurdite du projet. Faites de bon coeurs: micro-controlleurs petits et efficaces, traitement du signal pour telephone GSM, cable modem, que sais-je... Des coeurs qu'on peut melanger dans un chip pour faire un systeme complet (SoC).
mon sang n'a fait qu'un tour. J'ai même cru que c'était un apât à troll. Comme disait Kadreg, c'est trop gros mais ça explique pourquoi j'arrive pas à l'avaler.
Phrase #1
* ce n'est pas le seul coeur libre et il en existe de nombreux et qui fonctionnent déjà. Voir dans les facs, sujets de doctorat divers, opencores.org, opencollector.org... là où F-CPU frappe (à faire en mal) c'est sur "l'ambition". Le but est justement de faire sauter les limitations existantes, sur l'extensibilité du code et sur la modernité de l'architecture (ce n'est pas un Nième clone MIPS/DLX/SPARC...)
Phrase #2
* on fait l'erreur qu'on veut bien faire et quand on s'en rend compte, on assume. Et si on veut faire un CPU de station de travail, on le fait (cf 3)). Merci pour les "geek soft qui n'y comprennent rien à l'absurdite du projet" qui essaie juste de leur rendre la vie plus surmontable et de répérer les erreurs des pauvres ingés sous-payés d'Intel (c'est même pas de l'ironie, voir http://www.faceintel.com/(...)). D'après toi si autant de "geek soft" sont intéressés (le projet serait mort sinon) c'est parcequ'ils en ont marre d'être considérés comme des "cons de geeks" par "ces multinationales qui pensent ce qui est préférable pour nous". On dirait que tu n'as jamais eu affaire à un service de support informatique, ce qui est faux, puisque tu bosses à Tensilica. Mais justement, comme tu es dans une boite, tu peux presque parler d'égal à égal avec une autre boite, pas comme tout le monde. Bienvenue dans le monde réel.
Phrase #3 : là c'est le ponpon. Je me serais tu si il n'y avait pas celle-là.
* Non mais tu vois un "geek" (même non soft) faire du DSP pour GSM dans son garage ? pourquoi pas le convertisseur AD RF pendant que tu y es, avec une chambre à épitaxie près de le machine à laver ? J'en ai rien à battre et je fais ce qui m'intéresse. Sans oublier qu'avec la guerre des brevets constante et navrante entre tous les fabricants, la situation de ce milieu PUE et n'est pas près de devenir vivable avant 10 ans (pour les téléphones portables). Et puis il y a suffisamment de grosses et petites compagnies pour saturer le marcher et forcer les prix à la baisse, ce qui (à part la fragmentation du marché et l'incompatibilité et la fermeture des appareils et formats) justifie d'attendre avant de nous jeter dans l'arène en brandissant la GPL.
Phrase #4 : la petite couche de finition...
* Le terme SoC n'existait pas quand F-CPU a été créé. On appelait plutôt ça un "microcontrôleur" ou à la rigueur un "système intégré" mais maintenant on nous met du "SoC" à toutes les SoCes. Et puis vous imaginez quoi faire avec ? F-CPU est un microprocesseur, point barre. Il est fait pour en faire ce que vous voulez dans la limite des termes de la GPL et de la charte F-CPU.
Le message est : on ne fait pas F-CPU pour épargner le boulot des grosses boites et leur offrir gratuitement du travail prémaché. Je sais qu'il y en a qui se l'imaginent, mais tant qu'à le faire, autant se faire payer. J'ai eu un mal fou pour arriver à faire comprendre à Michael Riepe, le contributeur pour les unités critiques, d'assouplir légèrement ses conditions de licence. Mais faut pas pousser de l'autre côté non plus ! F-CPU est fait par et pour les utilisateurs, pas pour le bon plaisir de ceux qui le récupèrent.
2) positionnement : l'un et l'autre ne sont pas incompatibles.
quoique pour l'instant, le ctrl DMA et quelques autres accessoires soient un peu en dehors du but central du projet.
D'ailleurs, on en a très peu discuté, ce qui empêche quiconque de s'avancer.
Pour ce qui est de la surface : il y a des arguments pour et contre un circuit large.
- d'un côté les transistors et les fils deviennent de plus en plus petits, et surtout presque la moitié des transistors servent à latcher des données entre deux étages de pipeline.
- de l'autre côté plus un circuit est petit et plus il peut aller vite et être moins cher (cf ARM). Sans parler du débogage.
Pour sûr FC0 (l'implémentation en cours de réalisation) sera un terrain de foutebaule comparé à un ARM à technologie égale. Mais la comparaison s'arrête là : d'abord c'est du 64 bits avec 64 registres, la fréquence visée est plus grande (il faut 2 cycles pour une adition), les buffers mémoire sont différents...
Donc à chacun de voir, et en plus F-CPU est même fourni avec les sources, donc chacun peut tourner les boutons dans le sens qu'il l'entend : enlever des unités inutiles, changer la taille des registres et des unités, ...
Et puis à quoi bon comparer puisque les intentions sont complétement différentes ?
3) c'est vrai que ça va vite, mais un des seuls avantages du PII par rapport au P5 est qu'il a un bus séparé pour accéder à la L2 externe. Associé à un algo de préfetch dont j'ai eu l'occasion de juger de l'efficacité, j'ai été bluffé du speedup. Le but est de faire ça avec la RAM externe "privée" afin de 1) raccourcir et accélérer les transferts entre le coeur et la RAM offchip 2) bénéficier des "stream hints" inclus dans le code, au lieu de dépenser du HW et du développement dans une machine à reconnaitre les flux de données.
4) j'en ai rien à foutre aujourd'hui : je bosse sur F-CPU qui est descendant des RISC.
5) tout à fait : 1 bit pour indiquer si c'est SIMD et 2 bits pour dire la taille. c'est présent dans toutes les instructions qui opèrent sur des données et c'est bien pratique :-) En changeant la signification des 2 bits de taille on peut faire du code en largeur 128 256 512 1024....
ça change de ces putains d'extensions et de préfixes qu'on trouve dans d'autres architectures (hmmmm.... non.)
Pour le web, voir les urls présentées précédemment.
Je ne sais pas exactement, on ne peut pas savoir tant que le coeur n'est pas terminé. on en est au 1/3 ou au 1/4 pour l'instant (estimation au pif).
pour estimation, la synthèse du multiplieur a donné plus de 4096 bascules. Rajouter 4096 bits de mémoire multiport (3R2W) pour le banc de registres. Ajouter la cache L1 (split data+instruction, 256 bits par ligne). Ajouter les LSU et le fetcher (256*8 bits mutliports chacun). Ajouter environ une 50aine de buffers 64 bits pour différents étages du pipeline...
Voilà pour la partie "mémoire". Pour la partice combinatoire, il faut compter environ 6*64 portes logiques par étage de pipeline.
Une estimation à la louche me dit qu'il est possible de faire tenir FC0 en entier sur une CELARO à 1 cabinet avec une quinzaine de cartes "accélération" et une ou deux cartes S(D)RAM pour stocker les programmes. Comme on est en superpipeline, la machine tournera à vitesse maximale. Avec un peu d'astuce on peut même "mapper" certaines fonctions comme le Xbar sur le fond de panier. Mais certaines fonctions sont difficiles à mapper, comme le banc de registre qui utilisera probablement une carte entière... Bref, j'ai eu 6 mois pour réfléchir à ce sujet et ça me botte toujours :-) Il y a d'ailleurs un screenshot qqpart qui montre que j'ai "émulé" l'unité logique à 6MHz il y a plus d'un an...
moi qui suis considéré (par les autres) comme "l'organisateur" du projet (pasque j'ai les doigts qui ont de l'endurance et que ça fait maintenant 3 ans que je suis dans ce "radeau de la méduse"), ben j'apprends des choses tous les jours. Soit je les découvre, soit je les invente :-)
Par exemple, aujourd'hui, je me suis rendu compte qu'en utilisant une fonctionalité considérée comme "optionnelle" (le fabricant peut implémenter l'instruction ou la simuler par soft), on peut réduire jusqu'à 90% la taille des tables en ROM destinées à l'autotest de la puce... dingue :-)
de toute façon, à notre niveau, rien n'est inutile : j'irai pas cracher sur un FPGA. Quoiqu'il faudra qu'il soit balèse car rien que le multiplieur, le banc de registre et la cache L1 prennent "de la place".
Pour ce qui est d'un "bug killer", j'essaierai de reprendre contact avec mon ancien employeur qui fait des FPGA très ... spéciaux. RV à DATE2002 sur le stand Mentor, près de la machine qui ressemble à une méga-photocopieuse :-)
l'article en question dans le prochain LM il sera... :)
Tu veux parler de celui sur VHDL ou sur la DCT ? pour info, ça risque pas pour la DCR car j'ai pas encore fini le code (il faut tout vérifier, une erreur arrive si vite) et il faut encore réécrire tout le texte en français. Quant au code, il y a beaucoup de redondances car je montre toutes les étapes de la transformation, alors il ira sur le CD
Ah oui j'oubliais, il faut faire qqs illustrations, donc je dois prendre mon tgif pour dessiner au moins le graphe de dépendances de données...
<avis perso>De toute façon, vu que la plupart votent n'importe comment, ça correspond pas à grand'chose. Ah, si ! Ça sert à faire des concours de quéquettes sur la tribune :) </avis perso>
hmmmm je préviens les autres moules qu'il y a un joli début de troll par ici ? :-)))
Alliance, j'avais un peu regardé, il y a longtemps, j'avais dû faire les tutoriels, et je m'étais un peu amusé avec les générateurs de multiplicateurs. J'en avais même compilé un avec le compilo de Synopsys (c'était sur HP-UX). La simulation marchait, par contre, je crois pas qu'il était synthétisable.
Alliance est inutilisable dans un workflow à la fois simple et standard. Pour cela je préfère Simili pour la simulation car il ne souffre pas des mauvais choix de programmation de l'équipe CAO d'ASIME. Vous connaissez le coup du malloc spéculatif ? http://tnemeth.free.fr/fmbl/linuxsf/41-1.html(...) Il y a des fois où je crois qu'il a été inventé ici ...
Pour ce qui est des générateurs, on ne peut même pas les utiliser : F-CPU a des contraintes trop fortes, principalement le pipeline dont le chemin critique fait environ 6 portes logiques à 4 entrées. Un allemand (Michael Riepe) nous a concocté quelques unités d'exécutions de la mort : additionneur 64 bits à deux étages et MAC 64*64+64 à 8 étages ! (6 étages en 2*32 bits en parallèle (SIMD), 4 en 16 bits...).
Par contre ce qui fait vraiment chier c'est pour avoir un bon synthétiseur LIBRE et c'est pour ça que Alliance, malgré tous ses gros défauts, restera une alternative de dernier recours si on arrive pas à se débrouiller. Pour cela il faudra "sauter" l'étape de synthèse et attaquer directement au niveau netlist. Par contre, même si la librairie de cellules logiques d'ALLIANCE semble convenir (ses règles de dessin devraient passer dans toutes les fonderies), ses performances sont relativement ... indéterminables.
(Même en étant malhonnête par nécessité, on ne trouve pas de version pirate :)
Comme tu le dis, à quoi ça servirait si en plus il faut payer le Spartan ?
Pour l'instant on privilégie la portabilité du code. On fait de la compilation/simulation pure en VHDL'93 standard et sans chichi, en utilisant Vanilla VHDL et surtout Simili de http://symphonyeda.com/(...) qui permet de prendre son pieds même sous Linux.
Ainsi, le source (comme celui de Linux et autre GNU) peut être utilisé partout où la norme VHDL'93 est décemment respectée (détail important, puisque je suis en DEA au département ASIME où est conçu Alliance [ voir http://asim.lip6.fr/alliance.html(...) ] qui n'est pas ce qu'on pourrait appeler la panacée de la compatibilité et du workflow propre).
Par contre Cadence nous permet d'utiliser gratuitement ncsim. Encore eusse-t-il fallu que je trouvasse le temps de lire leur doc (50MO, ça dit qqn ?)
[^] # Re: au XXI ème siècle ?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Recherche des bogues et fuites de mémoire. Évalué à 1.
j'ai moins de problèmes avec, qu'avec le C.
C sapulpaté mais je suis obligé de passer par là :-(
et ton post n'a pas parlé de
LISP
SMALLTALK
EIFFEL
ADA
COBOL
PASCAL
FORTRAN
et tous ces langages qui ne servent que dans les livres...
franchement, moi maintenant je m'éclate au VHDL :-P
ça c'est un langage de mecs qui pensent et qui FONT de VRAIES choses.
non mais, moi aussi je peux troller ;-)
[^] # Re: VIVE LA LFS
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Linux From Scratch 3.2 dans les bacs. Évalué à 2.
Heureusement que pour ma première installe,
quelqu'un m'a aidé ! ensuite, j'ai continué
tout seul, en lisant le book et en faisant
gaffe, et ça a marché. Je ne le recommande
pas au premier newbie venu, ça demande du
temps et le goût spartiate, mais ça marche
et ça démystifie beaucoup de chose, ça
m'a rendu fier comme un coq sur le coup :-)
demandez sur la tribune, j'en ai oublié
la Red Hatte :-)
Par contre, un newbie sera dégoûté à vie,
s'il n'est pas déjà découragé par la taille
du Book (17K lignes).
[^] # Re: Pour ceux que ça intéresse...
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Linux From Scratch 3.2 dans les bacs. Évalué à 3.
moi j'ai juste un vieux graveur plextor et
j'ai installé la LFS de LM de mars,
ben j'ai mis 18h en tout ! les noms des fichiers
étaient presque tous altérés, je me suis fait
avoir, quoi (alors que l'archive TAR était
OK, mais alors pourquoi avoir foutu 2x la même
chose ???)
mais en tout cas, j'ai pu booter, j'avais
pris la précaution de charger le BOOK de la
3.2.
Linux, c'est bien quand ça marche :-)
# petite expértise piphomaitrique
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Project Frozen... C'est un PC, ça ?. Évalué à 7.
l'avis d'un mec qui est sensé s'y connaitre :
(du moins, qui a pas trop séché ses cours)
- esthétiquement : cool, il y a un quelque chose, sobre et pas exubérant.
- bruit : comme écrit plus haut, ça doit pas être amusant :-(
* je recommande l'utilisation de ventilos "silencieux" :
je ne suis pas spécialiste mais j'en ai un dans un tiroir.
de fabrication Suisse, 100 balles, pas un bruit, mais le
format et le débit ne sont peut-être pas adaptés.
* En plus, des disques durs identiques côté à côte,
ça crée des problèmes en basses fréquences car les vitesses
de rotation proches peuvent engendrer des harmoniques.
-> découpler les éléments mobiles en les éloignant,
les orientant de manière perpendiculaire et mettre des
amortisseurs en mousse pour éviter que les vibrations
ne se propagent dans la boite et fassent résoner tout
avec.
- Electriquement : la CEM (Compatibilité ElectroMagnétique,
ou l'interaction entre appareils par les champs magnétiques,
les champs électriques et les ondes électromagnétiques)
ne semble pas idéale. D'une part, la densité (34cm^3) est
telle que les champs ont une forte intensité. Je ne vois aucun
blindage entre les différentes cartes. De plus, le néon
"crache" plein de saloperies HF et le plexiglas laisse passer
(ou entrer, selon ce qui gêne le plus) les champs
magnétiques et électromagnétiques externes. Là, la solution
c'est de mettre une grille métallique fine, connectée à la masse.
Ca laisse passer une partie de la lumière mais la longueur d'onde
(même à 1GHz) des perturbations ne peut pas passer.
J'ai aussi appris en cours cette année que le meilleur "isolant
électromagnétique" est le feuillard en cuivre, s'il est correctement
posé. Il doit former une boucle autour de l'appareil pour que le
champ électromagnétique induise un champ inverse dans la boucle,
les deux champs vont donc s'annuler (c'est le principe du câble
coaxial :-D). Le cuivre conduit beaucoup mieux le courant que
l'aluminium ou l'acier, la perte (par effet Joule) du champ induit
dans le blindage est plus faible et le blindage est bien plus
efficace.
Pour terminer sur "le bon boulot bien fait par des ingénieurs
qui connaissent leur métier", je conseille de jeter un coup
d'oeil sur la fabrication des serveurs (SUN, DEC-ALPHA...).
Par exemple, un ALPHAserver DS20 est une vraie oeuvre d'art,
pas comme les PC... Blindage dans les règles de l'art,
circuit imprimé multicouche (pas du 4 couches "made in China"),
composants de qualité, bref, ça vaut le prix que ça vaut.
Pour le prix de la folie, j'ai probablement une photo de
boite PC en légo, vue au 17C3 à Berlin (rencontre CCC de décembre 2000).
Il y avait aussi la photo de la boite de PC dans le pack de bière,
trouvé il y a qqs jours en glandant sur un site...
l'URL doit être trouvable en demandant aux moules, je crois que DVA était là.
Quant à mon pécé à moi, demandez à trollhunter dans quel état lamentable il est...
# OUéééééé !
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Arrêt brutal des victoires en justice des "Majors". Évalué à -1.
ben quoi, j'ai pas le droit d'être content ? :-)
[^] # Re: Foutage de gueule
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche GPLinux, Debian 'grand public' 100% libre. Évalué à 0.
déjà, Nicole est sous W95 et attends de la voir pour comprendre. Déjà c'est pas une linuxienne "hacker" mais elle sait quand même faire la différence entre ce qui est libre et ce qui l'est pas. Le petit problème c'est qu'entre envoyer des cartons de papiers à Boston pour la revue de presse de la FSF et organiser 2-3 assos loi 1901 sur le libre, elle a pas le temps de configurer sa babasse.
Regarde-moi : je développe seulement du code sous GPL avec Linux, et quoi ? j'ai la flemme de configurer ma babasse pour le net alors je boote sous W95/netscape 4.51. ET ALORS ?
YG
# yeah !
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche GPLinux, Debian 'grand public' 100% libre. Évalué à -5.
[^] # Re: Autre question bête
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Accord Sun, Ximian et Wipro. Évalué à -5.
# plop !
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Auchan et l'OpenSource. Évalué à -10.
je sais je ne devrais pas me moquer puisque
j'ai commencé avec ça mais... je sais que
je ne demanderai pas conseil à IdealX :-P
[^] # "trop gros, marchera pas" (phrase connue)
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Serveurs HP Serie A et L sous Linux Debian. Évalué à -5.
la prochaine fois, il fera mieux.
le troll c'est aussi le feeling...
# mouais...
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Serveurs HP Serie A et L sous Linux Debian. Évalué à 8.
c'est eux qu'ont fait tout le gros boulot :-/
et HP récolte les pépettes !
[^] # ====> Moment <i>je pète un plomb</i> <====
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 1.
je sais que tu ne le pensais pas comme ça en l'écrivant mais ...
Ceci dit, c'est sympa de se fatiguer a faire des coeurs libres, ca manquait. Mais ne faites pas l'erreur de viser le processeur de station de travail, ca n'interesse en fait que les geeks soft qui ne comprennent pas l'absurdite du projet. Faites de bon coeurs: micro-controlleurs petits et efficaces, traitement du signal pour telephone GSM, cable modem, que sais-je... Des coeurs qu'on peut melanger dans un chip pour faire un systeme complet (SoC).
mon sang n'a fait qu'un tour. J'ai même cru que c'était un apât à troll. Comme disait Kadreg, c'est trop gros mais ça explique pourquoi j'arrive pas à l'avaler.
Phrase #1
* ce n'est pas le seul coeur libre et il en existe de nombreux et qui fonctionnent déjà. Voir dans les facs, sujets de doctorat divers, opencores.org, opencollector.org... là où F-CPU frappe (à faire en mal) c'est sur "l'ambition". Le but est justement de faire sauter les limitations existantes, sur l'extensibilité du code et sur la modernité de l'architecture (ce n'est pas un Nième clone MIPS/DLX/SPARC...)
Phrase #2
* on fait l'erreur qu'on veut bien faire et quand on s'en rend compte, on assume. Et si on veut faire un CPU de station de travail, on le fait (cf 3)). Merci pour les "geek soft qui n'y comprennent rien à l'absurdite du projet" qui essaie juste de leur rendre la vie plus surmontable et de répérer les erreurs des pauvres ingés sous-payés d'Intel (c'est même pas de l'ironie, voir http://www.faceintel.com/(...)). D'après toi si autant de "geek soft" sont intéressés (le projet serait mort sinon) c'est parcequ'ils en ont marre d'être considérés comme des "cons de geeks" par "ces multinationales qui pensent ce qui est préférable pour nous". On dirait que tu n'as jamais eu affaire à un service de support informatique, ce qui est faux, puisque tu bosses à Tensilica. Mais justement, comme tu es dans une boite, tu peux presque parler d'égal à égal avec une autre boite, pas comme tout le monde. Bienvenue dans le monde réel.
Phrase #3 : là c'est le ponpon. Je me serais tu si il n'y avait pas celle-là.
* Non mais tu vois un "geek" (même non soft) faire du DSP pour GSM dans son garage ? pourquoi pas le convertisseur AD RF pendant que tu y es, avec une chambre à épitaxie près de le machine à laver ? J'en ai rien à battre et je fais ce qui m'intéresse. Sans oublier qu'avec la guerre des brevets constante et navrante entre tous les fabricants, la situation de ce milieu PUE et n'est pas près de devenir vivable avant 10 ans (pour les téléphones portables). Et puis il y a suffisamment de grosses et petites compagnies pour saturer le marcher et forcer les prix à la baisse, ce qui (à part la fragmentation du marché et l'incompatibilité et la fermeture des appareils et formats) justifie d'attendre avant de nous jeter dans l'arène en brandissant la GPL.
Phrase #4 : la petite couche de finition...
* Le terme SoC n'existait pas quand F-CPU a été créé. On appelait plutôt ça un "microcontrôleur" ou à la rigueur un "système intégré" mais maintenant on nous met du "SoC" à toutes les SoCes. Et puis vous imaginez quoi faire avec ? F-CPU est un microprocesseur, point barre. Il est fait pour en faire ce que vous voulez dans la limite des termes de la GPL et de la charte F-CPU.
Le message est : on ne fait pas F-CPU pour épargner le boulot des grosses boites et leur offrir gratuitement du travail prémaché. Je sais qu'il y en a qui se l'imaginent, mais tant qu'à le faire, autant se faire payer. J'ai eu un mal fou pour arriver à faire comprendre à Michael Riepe, le contributeur pour les unités critiques, d'assouplir légèrement ses conditions de licence. Mais faut pas pousser de l'autre côté non plus ! F-CPU est fait par et pour les utilisateurs, pas pour le bon plaisir de ceux qui le récupèrent.
Y'a pas marqué "BSD".
[^] # Re: Un bon article
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 1.
1) ça montre qu'on est du "milieu" :-)
2) positionnement : l'un et l'autre ne sont pas incompatibles.
quoique pour l'instant, le ctrl DMA et quelques autres accessoires soient un peu en dehors du but central du projet.
D'ailleurs, on en a très peu discuté, ce qui empêche quiconque de s'avancer.
Pour ce qui est de la surface : il y a des arguments pour et contre un circuit large.
- d'un côté les transistors et les fils deviennent de plus en plus petits, et surtout presque la moitié des transistors servent à latcher des données entre deux étages de pipeline.
- de l'autre côté plus un circuit est petit et plus il peut aller vite et être moins cher (cf ARM). Sans parler du débogage.
Pour sûr FC0 (l'implémentation en cours de réalisation) sera un terrain de foutebaule comparé à un ARM à technologie égale. Mais la comparaison s'arrête là : d'abord c'est du 64 bits avec 64 registres, la fréquence visée est plus grande (il faut 2 cycles pour une adition), les buffers mémoire sont différents...
Donc à chacun de voir, et en plus F-CPU est même fourni avec les sources, donc chacun peut tourner les boutons dans le sens qu'il l'entend : enlever des unités inutiles, changer la taille des registres et des unités, ...
Et puis à quoi bon comparer puisque les intentions sont complétement différentes ?
3) c'est vrai que ça va vite, mais un des seuls avantages du PII par rapport au P5 est qu'il a un bus séparé pour accéder à la L2 externe. Associé à un algo de préfetch dont j'ai eu l'occasion de juger de l'efficacité, j'ai été bluffé du speedup. Le but est de faire ça avec la RAM externe "privée" afin de 1) raccourcir et accélérer les transferts entre le coeur et la RAM offchip 2) bénéficier des "stream hints" inclus dans le code, au lieu de dépenser du HW et du développement dans une machine à reconnaitre les flux de données.
4) j'en ai rien à foutre aujourd'hui : je bosse sur F-CPU qui est descendant des RISC.
5) tout à fait : 1 bit pour indiquer si c'est SIMD et 2 bits pour dire la taille. c'est présent dans toutes les instructions qui opèrent sur des données et c'est bien pratique :-) En changeant la signification des 2 bits de taille on peut faire du code en largeur 128 256 512 1024....
ça change de ces putains d'extensions et de préfixes qu'on trouve dans d'autres architectures (hmmmm.... non.)
Pour le web, voir les urls présentées précédemment.
[^] # Re: article
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 1.
Je ne sais pas exactement, on ne peut pas savoir tant que le coeur n'est pas terminé. on en est au 1/3 ou au 1/4 pour l'instant (estimation au pif).
pour estimation, la synthèse du multiplieur a donné plus de 4096 bascules. Rajouter 4096 bits de mémoire multiport (3R2W) pour le banc de registres. Ajouter la cache L1 (split data+instruction, 256 bits par ligne). Ajouter les LSU et le fetcher (256*8 bits mutliports chacun). Ajouter environ une 50aine de buffers 64 bits pour différents étages du pipeline...
Voilà pour la partie "mémoire". Pour la partice combinatoire, il faut compter environ 6*64 portes logiques par étage de pipeline.
Une estimation à la louche me dit qu'il est possible de faire tenir FC0 en entier sur une CELARO à 1 cabinet avec une quinzaine de cartes "accélération" et une ou deux cartes S(D)RAM pour stocker les programmes. Comme on est en superpipeline, la machine tournera à vitesse maximale. Avec un peu d'astuce on peut même "mapper" certaines fonctions comme le Xbar sur le fond de panier. Mais certaines fonctions sont difficiles à mapper, comme le banc de registre qui utilisera probablement une carte entière... Bref, j'ai eu 6 mois pour réfléchir à ce sujet et ça me botte toujours :-) Il y a d'ailleurs un screenshot qqpart qui montre que j'ai "émulé" l'unité logique à 6MHz il y a plus d'un an...
YG qui a dormi 3h cette nuit !!! houra :-)
[^] # Re: Très interessant
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à -2.
/un CISC/de la merde/
[^] # Re: Très interessant
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 3.
mais j'ai survolé : ça m'a l'air que du bon !
merci pour le lien !
[^] # Re: Bon bon bon
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 7.
moi qui suis considéré (par les autres) comme "l'organisateur" du projet (pasque j'ai les doigts qui ont de l'endurance et que ça fait maintenant 3 ans que je suis dans ce "radeau de la méduse"), ben j'apprends des choses tous les jours. Soit je les découvre, soit je les invente :-)
Par exemple, aujourd'hui, je me suis rendu compte qu'en utilisant une fonctionalité considérée comme "optionnelle" (le fabricant peut implémenter l'instruction ou la simuler par soft), on peut réduire jusqu'à 90% la taille des tables en ROM destinées à l'autotest de la puce... dingue :-)
Et pour ceux qui ont pas trouvé le lien sur notre site crade (webmaster wanted), vous pouvez vous abonner sur le site web de l'APRIL à http://lists.april.org/wws/info/f-cpu_france(...)
bien que les discussions techniques se passent sur la liste anglaise ( http://archives.seul.org/f-cpu/f-cpu/(...) )
Pour le reste, j'ai bien lardé cette page avec plein d'autres URL... 'a ka lire :-)
[^] # Re: debut de troll ?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à -2.
moui c'est ça : avec kadreg dans le coin, ça va bientôt faire ====>pika<==== partout...
[^] # Re: article
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 1.
Pour ce qui est d'un "bug killer", j'essaierai de reprendre contact avec mon ancien employeur qui fait des FPGA très ... spéciaux. RV à DATE2002 sur le stand Mentor, près de la machine qui ressemble à une méga-photocopieuse :-)
[^] # Re: vi
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à -1.
Tu veux parler de celui sur VHDL ou sur la DCT ? pour info, ça risque pas pour la DCR car j'ai pas encore fini le code (il faut tout vérifier, une erreur arrive si vite) et il faut encore réécrire tout le texte en français. Quant au code, il y a beaucoup de redondances car je montre toutes les étapes de la transformation, alors il ira sur le CD
Ah oui j'oubliais, il faut faire qqs illustrations, donc je dois prendre mon tgif pour dessiner au moins le graphe de dépendances de données...
[^] # Re: article
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à -2.
hmmmm je préviens les autres moules qu'il y a un joli début de troll par ici ? :-)))
[^] # Re: un projet sous le coude
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 3.
je confirme. c'est comme ça que j'ai réussi à faire parler un afficheur LCD. Pas très longtemps mais il a dit "crrcrcrsrrc".
Pour ceux qui s'ennuient, je conseille : une pile 9V et un tas de DEL. prendre une DEL, la mettre aux bornes de la pile, reprendre une autre DEL...
</poésie>
[^] # Re: article plus général
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 0.
</déconne>
[^] # Re: article
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 2.
Alliance est inutilisable dans un workflow à la fois simple et standard. Pour cela je préfère Simili pour la simulation car il ne souffre pas des mauvais choix de programmation de l'équipe CAO d'ASIME. Vous connaissez le coup du malloc spéculatif ? http://tnemeth.free.fr/fmbl/linuxsf/41-1.html(...) Il y a des fois où je crois qu'il a été inventé ici ...
Pour ce qui est des générateurs, on ne peut même pas les utiliser : F-CPU a des contraintes trop fortes, principalement le pipeline dont le chemin critique fait environ 6 portes logiques à 4 entrées. Un allemand (Michael Riepe) nous a concocté quelques unités d'exécutions de la mort : additionneur 64 bits à deux étages et MAC 64*64+64 à 8 étages ! (6 étages en 2*32 bits en parallèle (SIMD), 4 en 16 bits...).
Par contre ce qui fait vraiment chier c'est pour avoir un bon synthétiseur LIBRE et c'est pour ça que Alliance, malgré tous ses gros défauts, restera une alternative de dernier recours si on arrive pas à se débrouiller. Pour cela il faudra "sauter" l'étape de synthèse et attaquer directement au niveau netlist. Par contre, même si la librairie de cellules logiques d'ALLIANCE semble convenir (ses règles de dessin devraient passer dans toutes les fonderies), ses performances sont relativement ... indéterminables.
Bienvenue dans le monde libre.
YG (tiens je suis maintenant à 19 XP ???)
[^] # Re: article
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 1.
Comme tu le dis, à quoi ça servirait si en plus il faut payer le Spartan ?
Pour l'instant on privilégie la portabilité du code. On fait de la compilation/simulation pure en VHDL'93 standard et sans chichi, en utilisant Vanilla VHDL et surtout Simili de http://symphonyeda.com/(...) qui permet de prendre son pieds même sous Linux.
Ainsi, le source (comme celui de Linux et autre GNU) peut être utilisé partout où la norme VHDL'93 est décemment respectée (détail important, puisque je suis en DEA au département ASIME où est conçu Alliance [ voir http://asim.lip6.fr/alliance.html(...) ] qui n'est pas ce qu'on pourrait appeler la panacée de la compatibilité et du workflow propre).
Par contre Cadence nous permet d'utiliser gratuitement ncsim. Encore eusse-t-il fallu que je trouvasse le temps de lire leur doc (50MO, ça dit qqn ?)