10 questions à l'équipe f-cpu

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
10
fév.
2003
Matériel
Je propose de relancer la section « Interview » de LinuxFr. Les visiteurs de LinuxFr ont la possibilité de choisir les questions qui seront posées à (aux) interviewé(s).

Pour cette nouvelle édition, j'ai choisi l'équipe du projet f-cpu (qui travaille au design d'un processeur libre). J'attends donc vos questions sur f-cpu et vos propositions d'interviewés (francophones, vu le lectorat de LinuxFr) pour la suite. À vos claviers donc. Les questions peuvent concerner des aspects techniques ou politiques, être sur le passé, le présent ou l'avenir, sur les liens avec d'autres projets, sur les envies /motivations des développeurs, leurs coups de coeur/de gueule, etc.

Bien entendu, les développeurs de f-cpu peuvent aussi proposer les questions qu'ils souhaiteraient qu'on leur pose :).

Aller plus loin

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  (site web personnel) . Évalué à 10.

    Qu'est-ce que vous pensez des projets TCPA/LaGrande, Palladium/"next-generation secure computing base" ? L'équipe f-cpu envisage -t-elle d'avoir ou de rajouter des composants spécialement dédiés à la crypto ou aux DRM dans son processeur ?

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  . Évalué à 4.

      Tiens, c'est pas bête, cà ! :-)

      Il serait plutôt marrant et assez inattendu que l'on s'invente notre propre puce fritz + Palladium maison et que l'on file les clefs à la FSF ! Quel résultat cela donnerait-il d'après vous ? Est-ce que les éditeurs se lanceraient à fond dans l'un ou dans l'autre, ou bien cela créerait-il un bordel suffisament confus pour discréditer le projet entier ?

      Bon je précise quand même que cela reste du second degré, et que je n'ai pas plus envie que quiquonque ici de voir un jour un tel projet aboutir ...

      • [^] # Re: 10 questions à l'équipe f-cpu

        Posté par  . Évalué à -7.

        Une puce crypto n'a _AUCUN_ interêt si tu divulgues les clefs, FSF ou pas ;-)

      • [^] # Re: 10 questions à l'équipe f-cpu

        Posté par  . Évalué à 10.

        Moi je trouverai plutot bien qu'il y ait un composant spécifique à la crypto. Que je sache ca n'a rien à voir avec palladium.

        • [^] # Re: 10 questions à l'équipe f-cpu

          Posté par  (site web personnel) . Évalué à 1.

          F-CPU n'est pas manchot quand il s'agit de chiffrer et déchiffrer des données, mais tout se fait en soft en utilisant des instructions qui peuvent tout aussi bien servir au graphisme, au traitement de son ou n'importe quoi d'autre. Les fonctions "crypto" ne sont pas rajoutées si elles n'ont pas une autre utilité, car le coeur commence à devenir assez lourd comme ça.

          Quant à faire une Fritz .... on en est très loin (enfin, l'équipe F-CPU)

          YG

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 2.

      Qu'est-ce que vous pensez des projets TCPA/LaGrande, Palladium/"next-generation secure computing base" ?

      That's sux ! (tm) même si palladium et tcpa ne sont finalement pas identiques.

      L'équipe f-cpu envisage -t-elle d'avoir ou de rajouter des composants spécialement dédiés à la crypto ou aux DRM dans son processeur ?

      Il ya des instructions qui permètent d'accélerer des codes de crypto mais pas plus.

      F-cpu n'est LA réponse à ses puces DRM car n'importe qui veut faire un f-cpu pourra toujours rajouter une puce type tcpa à coté du proc sur le bus IO si il veut. Au mieux, on peut obliger l'utilisation de la GPL pour tout code qui s'attache à l'interface mémoire principal (DRAM). Mais il restera les caches internes pour cacher certaine execution.

      "La première sécurité est la liberté"

      • [^] # Re: 10 questions à l'équipe f-cpu

        Posté par  . Évalué à 2.

        la GPL dans le cadre du projet F-CPU ne touche que le code VLD, les fondeur peuvent trés bien produire des puces equipés sans violer la GPL.

        Apres je perciste a pencer que le TCPA/LaGrande, qui apporte pas mal (plus) des fonctions des cartes a puces peuevent étre trés utiles, et si de plus elles sont bien consue elles n'ont pas grand chose a perdre a étre transparente ( méme si personne ne peut verifier effectivement que le code donné est bien celui utilisé ... ).

        Apers Palladium/next-generation trucs je trouve le principe stupide, et liberticide.

        P.S.
        TCPA n'est qu'un coprocesseur, Palladium/Fritz sera vraisemblablement une extention de la MMU du processeur coupler avec des fonctions de protection mémoire forte, et d'un systéme de certificat et de confience.

        • [^] # Re: 10 questions à l'équipe f-cpu

          Posté par  . Évalué à -2.

          hmmm tel que tu le décris comme une extension de la MMU ca se precise un peu plus (du côté du liberticide), mais d'où est-ce que tu tires cette information ?

          • [^] # Re: 10 questions à l'équipe f-cpu

            Posté par  . Évalué à 6.

            La
            http://www.mail-archive.com/cryptography@wasabisystems.com/msg02579(...)
            et dans le reste de la file
            http://www.mail-archive.com/cryptography@wasabisystems.com/msg02581(...)

            On sait peut de chose de SCP/Palladium, mais toutes les personnes qui si sont penchés sont d'accord pour dire que pour faire ce qu'il decrive cela passe par la mise en place d'un nouveau niveau de prioritée mémoire superieur ou au moin egual a l'OS, le fameux Ring -1 ou Hyper system comme il est dit dans l'un des communiqué de MS ( je crois que le terme est reprit par l'ingenieur de AMI interviewé sur /. au sujet de SCP et TCPA ), méme si apres le reste des fonctions peuvent étre exporté vers un coprocesseur ou une autre puce, cela implique une modification non negligable de l'architecture mémoire du processeur et donc du MMU dont c'est le travail de gerer cela.

            TCPA quand a lui ne s'occupe absolument pas de la mémoire du CPU.

            • [^] # Re: 10 questions à l'équipe f-cpu

              Posté par  . Évalué à 2.

              Personnellement, ca me pose un gros probleme de savoir qu'il existe des logiciels tiers qui sont superieur en terme de securite a celui de l'OS. J'ai du mal a voir l'interet de perdre le controle sur ces taches. Si jamais une faille existe dans ce niveau, tu peux tout faire sur les niveaux du dessous, c'est a dire meme sur l'OS.

              Normalement tu n'as qu'un seul logiciel qui a ces droits : l'OS. Avec TCPA, tu vas voir apparaitre des tas d'applications qui representent chacune un risque potentiel.

              Maintenant le principal interet de TCPA, c'est les "jails", or si tu regardes le projet L4/Hurd, il parait possible de faire la meme chose en pensant juste differemment les OS. Donc je ne vois pas l'interet du TCPA.

              • [^] # Re: 10 questions à l'équipe f-cpu

                Posté par  . Évalué à 1.

                Toi ta rien comprie.

                Je decrie le fonctionnement de SCP/palladium pas de TCPA !!!

                TCPA en gros c'est un coprocesseur genre carte a puce, USIM, il s'occupe absolument pas du CPU, des tache ou de la gestion mémoire, c'est une puce d'extention cryptographique standardisé pas grand chose de plus.

                • [^] # Re: 10 questions à l'équipe f-cpu

                  Posté par  . Évalué à 1.

                  Arf, je me suis encore goure entre TCPA et SCP. Effectivement, je parlais de SCP et pas de TCPA. Et tu as tout a fait raison de dire que TCPA n'est qu'une alternative aux cartes a puce. Desole pour l'erreur.

  • # Question facile (dans les rêves) :

    Posté par  (site web personnel) . Évalué à 10.

    La license logicielle (L)GPL est-elle adaptée au hardware Libre ? Quelles sont les spécificités et risques non couverts par cette license ? Avez-vous des besoins/moyens pour y remédier ?

    • [^] # Re: Question facile (dans les rêves) :

      Posté par  (site web personnel) . Évalué à 10.

      La (l)gpl est adapé à tout ce qui a des sources et qui produit un résultat. Des plans et de sources HDL peuvent donc rentrer dans la catégorie.

      La GPL a le désavantage d'exiger la mise que la puce entière soit en GPL. Ce qui ne sera pas du gout de future utilisateur. En effet, les puces se consoivent aujourd'hui avant tout comme l'on considérait une carte il y a qq temps (cf. Omap de TI avec un ARM 9 pour l'applicatif, un arm7+C54 pour la radio sur le même die !)

      La LGPL est utilisée par LEON un proc sparc v8 de l'ESA ( www.gaisler.com ).

      La GPL avec exception sur certaine interface (bus io) devrait être suffisant. Cela ressemblerait à la licence du noyau linux. Mais cela n'engage que moi dans le projet.

      "La première sécurité est la liberté"

      • [^] # Re: Question facile (dans les rêves) :

        Posté par  (site web personnel) . Évalué à 1.

        Tu as beau dire, mais la GPL en a pris un coup.

        Malheureusement, RMS semble vraiment aussi autiste qu'on le dit
        et j'ai peur qu'on se trimbale la licence GPL très longtemps avant de passer à une licence spécifique F-CPU ou Free Hardware qui justement traiterait AUSSI des problèmes style TCPA.

        YG

        • [^] # Re: Question facile (dans les rêves) :

          Posté par  (site web personnel) . Évalué à 1.

          Malheureusement, RMS semble vraiment aussi autiste qu'on le dit

          J'avais déjà essayer au FOSDEM l'an passé.

          Coté juridique:
          Mais il faut savoir qu'il n'ai pas l'auteur de la GPL.

          Qu'un juriste a confirmer que la GPL pouvait protéger du code HDL.

          Que l'ESA utilise la LGPL pour le Leon.

          Ecrire une licence est extrémement difficile sans risquer de faire des bétises.

          Coté pratique:
          La GPL couvrirait tout le code d'une puce, ce qui n'est pas acceptable, c'est comme si linux interdisait du code non GPL de tourner sous lui.

          On peut tout à fait rajouter des API ou le propriétaire est accepté comme pour le noyau linux, les noyaux temps réel comme ecos et autre...

          TCPA:
          Si notre licence attaque le TCPA ou autre, cela ne sera plus une licence "libre" et les effets pervers pourrait être encore pire (comme rendre la puce inutilisable par un industriel)

          "La première sécurité est la liberté"

  • # Avancement ?

    Posté par  (site web personnel) . Évalué à 10.

    Où en est le projet ? Etes-vous en mesure de produire les specs complètes d'un microcontroleur RISC simple un jour (par exemple) ?

    • [^] # Re: Avancement ?

      Posté par  (site web personnel) . Évalué à 3.

      Cela existe déjà sur opencores.org, cela n'est pas drôle de réinventer la roue. Faire un cpu simple est facile à faire. Pousser les perfs, cela devient carrement plus dure !

      "La première sécurité est la liberté"

      • [^] # Re: Avancement ?

        Posté par  (site web personnel) . Évalué à 2.

        Bon, alors questions : où peut-on se procurer du matos Libre ? (simple)
        ...et à défaut, comment peut-on le produire ? simplement et pas cher...

        • [^] # Re: Avancement ?

          Posté par  (site web personnel) . Évalué à 6.

          Le mieux est de regarder ce qui se fait sur opencores.org. En gros, cela revient à utiliser des cartes à bases de FPGA, ce qui est loin d'être pas chère.

          "La première sécurité est la liberté"

          • [^] # A propos de micro comtrôleur

            Posté par  . Évalué à 8.

            Sur Open core ou open collector, je ne sais plus, j'ai trouvé un projet de coeur compatible Pic de Microchip. Cela m'a intéressé mais j'ai lu que les auteurs avaient peur de violer un certain nombre de brevets.
            C'est dommage, car l'architecture des Pics est assez efficace.
            Personnellement, un Micro avec une architecture Harvard, avec un acces aux données de largeur variable : 1, 8, 12, 16, 24 ou 32 bits, capable d'adresser quelques Meg de Code et de Donnée, Et bien sûr Risc !
            Ce serait le pieds.

            • [^] # Re: A propos de micro comtrôleur

              Posté par  (site web personnel) . Évalué à 0.

              Ouais, mais un PIC-Like en FPGA ça risque d'etre un peu moins rapide, et plus encombrant...

              • [^] # Re: A propos de micro comtrôleur

                Posté par  (site web personnel) . Évalué à 1.

                Et surtout, au prix du PIC (de 4 à 15 Euros) et surtout au niveau de l'OpenSourceFriendship, je ne crois pas qu'on puisse tirer sur Microchip. Leur truc est simple, facile et pas cher, on ne peut pas faire mieux ou plus réduit.

                Là où ça commence à devenir marrant c'est quand l'architecture est plus complexe .... C'est pour ça qu'il y a des dizaines ou centaines de familles de CPU 16 et 32 bits.

                YG

  • # fabrication, conception

    Posté par  . Évalué à 10.

    quelles solutions envisagez-vous pour faire fabriquer un fcpu ?

    Autrement dit, la réutilisation du design de fcpu par un grand fondeur (AMD, VIA) est-elle la seule solution?

    Ou bien fcpu est-il suffisament simple pour utiliser les services de "moyens" fondeurs (par exemple ceux qui fabriquent des puces bon marché pour les cartes graphiques ou pour les chipsets), voir de petits fabricants de puces (je pense notamment aux nouvelles techniques de fabrication de circuits par "imprimante" sur des supports bon marché) ?


    CONCEPTION: quels softs (libres ?) utilisez-vous pour vos conceptions/simulations ?

    Utilisez-vous un système de ditribution de la charge sur plusieurs machines ?

    • [^] # Re: fabrication, conception

      Posté par  (site web personnel) . Évalué à 10.

      Faire fabriquer une puce coute une fortune en petite série.

      Je pencherais pour la création d'un "core" qui serait réutiliser pour faire des SoC (system on chip) pour faire des puces plus grosses. Dans le but de faire des palms ou autres trucs du même genre.

      Les fabrications par imprimantes ne sont qu'au stade d'expérimentation. Toutes technologie est utilisable. Si la puce est fabirqué en faible exemplaire, une vieille techno coutera moins chère car les couts fixent seront inférieurs mais les perfs seront en baisse aussi.

      Coté soft libre de CAO.

      C'est simple : il n'y a rien ou quasiement rien !!

      En gros, en simulation, il y a simili ( http://www.symphonyeda.com/(...) ) qui est gratuit sous linux mais pas libre du tout. Pour la synthèse, il n'y a rien. Peut-être xilinx en version gratuit pour synthètiser sur des petits trucs (genre XCV300). Il n'y a sinon que les programmes proprio (design compiler,...).

      Seul gtkwave est un programme libre qui permet de faire un truc en CAO : afficher des waveformes !

      ghdl.free.fr est un projet de front end vhdl pour gcc : c'est super prometteur. Si le projet arrive au bout, cela va être terrible !

      "La première sécurité est la liberté"

      • [^] # Re: fabrication, conception

        Posté par  . Évalué à 2.

        Coté compilateur VHDL et simulateur, il y'avait VDT et IVSIM maintenant concernant leur licence respective j'en sais rien mais en terme d'efficacité, j'ai entendu de bon echos (de la part de gens bien plus compétents que moi concernant le hard) même si apparemment il y'avait quelques petits manques mais ça a du évoluer depuis. Peut-être que vous avez déjà testé ?

      • [^] # Re: fabrication, conception

        Posté par  . Évalué à 1.

        Xilinx est l'enfer sur terre: quoique qu'on avait pas la derneire version (étaient sur 4xx je crois), jamais vu un programme aussi chiant et buggué (p-e TraxMaker de CircuitMaker). Bonne idée de base, conception merdique. C'est incroyable le trouve qu on a eu pour faire une calculatrice sur FPGA

        (à la fin, plus rien simulais, chanceux que chaque bloc à été super bien testé indépendamment avant pis que ça l'est marché du premier coup sur la carte: en plus, de même, on est heureux d'avoir sauver l' "image" de la puce, on à jamais plus été capable de recompiler apres le premier coup...)

        • [^] # Re: fabrication, conception

          Posté par  (site web personnel) . Évalué à 0.

          mouarf !

          Là je me lance dans les CPLD (coût oblige !) et je suis tombé sur les trucs ALTERA de chez Conrad. Ben ça marche même pas et je pense pas qu'on pourrait me rembourser .... Mais il faut garder espoir !

    • [^] # Le prix

      Posté par  . Évalué à 4.

      Pour donner un ordre de grandeur:

      Un tapeout de 25 chips 5mmx5mm en .13µ coute environ 500000$, en fait le plus gros du prix c'est le jeu de masque.

      Ensuite faut ajouter le boitier et éventuellement les tests...

      Bref, seule une grosse boite peut financer le f-cpu pour le produire "en vrai"

      • [^] # Re: Le prix

        Posté par  . Évalué à 1.

        Oui, je pense que la question c'est de savoir s'il peuvent fournir une puce à un tarif concurrenciel et comment est-ce qu'ils comptent la produire. Il sera très couteux de faire de petites séries et de maintenir un niveau technologique capable de rivaliser avec Intel, AMD... Et je doute qu'un grand fondeur accepte de la produire...

        @+ tex

        • [^] # Re: Le prix

          Posté par  (site web personnel) . Évalué à 1.

          <mode> Le but du projet F-CPU n'est pas de fabriquer ni d'industrialiser un processeur, seulement d'écrire les sources VHDL. Ensuite, les gents font ce qu'ils veulent avec (enfin, presque) <mode>

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 2.

    f-cpu, on en parle, on en parle, mais y'a toujours que intel et amd dans les machines chez Auchan.
    Je ne vais meme pas poser ma question tellement elle est ridicule, mais ca merite surement une explication pour eclairer les buts de f-cpu.

    Le bonjour chez vous,
    Yves

  • # Autres projets

    Posté par  (site web personnel) . Évalué à 6.

    Que pensez-vous des projets suivant ? f-cpu est-il lié à ces projets et si oui de quelle manière ?

    http://www.opencores.org/(...)
    http://www.opencollector.org/(...)
    http://www.openhardware.net/(...)
    http://www.simputer.org(...)

    • [^] # Re: Autres projets

      Posté par  (site web personnel) . Évalué à 2.

      Je vais poser une question bete.

      Le projet d'interface ps2 de opencores m'interresse. Comment je l'integre dans un circuit existant. Les projets peuvent directement etre mis dans un ASIC ? comment ? ou je prendre plusieurs brique ainsi qu'un core pour construire un microcontroleur ?

      Sinon, si vous avez des codes sources et electronique associe (sans ajouter un microcontroleur) pour connecter un clavier/lecteur code barre a un microcontroleur... ca m'aiderait ;)

      Merci pour les liens !

      • [^] # Re: Autres projets

        Posté par  (site web personnel) . Évalué à 2.

        trop fastoche !

        va voir sur http://panda.cs.ndsu.nodak.edu/%7Eachapwes/PICmicro/code/code.html(...)

        je m'en suis sorti avec un PIC 16F84A mais on peut prendre un truc plus gros, selon ce dont tu as besoin ou ton programmeur.

        YG

        • [^] # Re: Autres projets

          Posté par  (site web personnel) . Évalué à 1.

          Ben, je connais cette page pour faire une interface sourie ;)
          Mais il s'avere qu'il n'y pas vraiment d'interface ps2. J'ai deja une carte ethernut (ATMEL+ethenet). Et j'aimerai me connecter un clavier .

          mais si c'est moins chiant, de prendre un core proc+ divers core IP de opencores pour me faire mon FPGA au petit oignon ;)

      • [^] # Re: Autres projets

        Posté par  . Évalué à 1.

        Existe t-il des packages pour lecture de code barre sous linux avec une douchette sur port PS/2?

        Merci pour toutes informations.

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 10.

    Quelqu'un s'est-t-il deja montré interessé pour construire ce processeur ?

    Que pensez-vous de LEON, le processeur (comp. SPARC) développé par l'Agence Spatiale Européenne lui aussi sous LGPL ? http://www.gaisler.com/leon.html(...)

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 9.

      Quelqu'un s'est-t-il deja montré interessé pour construire ce processeur ?

      Plus ou moins.

      Que pensez-vous de LEON, le processeur (comp. SPARC) développé par l'Agence Spatiale Européenne lui aussi sous LGPL ? http://www.gaisler.com/leon.html(...)

      C'est l'exemple pour dire que l'open hardware peut marcher ! Il a déjà été fondu 3 fois. Il tourne correctement et est tout petit. Et surtout il existe...

      "La première sécurité est la liberté"

      • [^] # cout/performance d'un proc libre comme LEON ?

        Posté par  . Évalué à 5.

        des projets comme LEON permettent-ils deja de fabriquer des puces performantes à bas cout ? (et qui tournent sous Linux, SPARC oblige)

        en particulier comment des projets se comparent aux procs Intel/AMD en termes de prix, de bogomips ou autres mesures de rapidité ?

        • [^] # Re: cout/performance d'un proc libre comme LEON ?

          Posté par  (site web personnel) . Évalué à 8.

          LEON et le RISC d'opencores.org peuvent tourner vers les 170-200 Mhz en 0.18µm avec une moyenne de 0.9 instruction par coup d'horloge (1.9 pour le dernier Opteron).

          Donc, c'est plus performant que les ARM 9. Mais pas que les arm 10 et autre Xscale/strongarm. Et je ne parles pas des x86 et autres cpu de station de travail.

          Niveau prix, cela dépend du nombre pièce fournis. Je ne connais personne qui vend un Leon "grand public" pour l'instand. Atmel devrait vendre une version "fault tolerant" pour le spatial à 100 Mhz (en 0.25 µm, je crois). Mais le prix doit être de l'ordre de 5000 eur.

          "La première sécurité est la liberté"

          • [^] # Re: cout/performance d'un proc libre comme LEON ?

            Posté par  . Évalué à 3.

            Amusant, ton dernier paragraphe résume pourquoi je ne crois pas beaucoup au succes au niveau application pratique du f-cpu.

            Le succés du 80x86 le montre bien: les CPU c'est comme les avions: si tu mets suffisamment de transistor et que tu produits en grande quantité une architecture pourrie, le rapport performance/prix sera imbattable (le corrolaire pour les avions, c'est que si tu mets suffisamment de moteur tu peux faire voler un fer a repasser, ça "marche" aussi cf le skyvan).

            Donc quand bien meme le design du f-cpu serait supérieur..
            Ne voyant pas de Léon partout (pourtant le marché de l'embarqué est supérieur en pieces au marché du PC), je doute que je verrais des f-cpu produit en autre chose..

            Ceci dit sans aucune méchanceté: les développeurs du f-cpu s'éclate a concevoir leur architecture et je dis bravo, bon courage et bonne chance!

            • [^] # Re: cout/performance d'un proc libre comme LEON ?

              Posté par  (site web personnel) . Évalué à 3.

              Le prix d'Atmel provient surtout du fait qu'il s'agit de version spatial. C'est une catégorie encore au-dessus de industrial et militaire. Le moindre puce coute une fortune un pauvre FPGA Actel 60.000 portes coute 60kf.

              La technologie utilisé est spécial pour tenir les radiations et tous est testé : les puces sont censé tourné entre 5 et 15 ans sans panne et sans maintenance !

              De plus, si il vende 200 puces par an, c'est un maximum.

              Metrowerk (?) le propose pour ses soc.

              "La première sécurité est la liberté"

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 10.

    1) Dans combien de temps pensez vous que l'on pourrait créer/utiliser un pc dont les composants seraient libres ? Par exemple un pc à base de f-cpu + linuxbios (+ f-gpu*) .

    * 2) Est-ce qu'il existe un projet similaire au f-cpu mais visant à créer un processeur de carte graphique (ou de carte son ou autre...) ?

    3) Est-ce que les participants au projet f-cpu s'impliquent aussi dans le développement des logiciels nécessaires à sa mise en oeuvre (comme le ghdl évoqué plus haut) ou son utilisation (comme le port de gcc pour l'architecture f-cpu) ?

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 6.

      1) Aucune idée.

      Faire un cpu, n'a rien à voir à faire un ordinateur. Un ordinateur est surtout une plateforme avec des IO spécifics (liens séries/ PCI/ISA/hypertransport/...). A mon avis, changer le CPU est ce qui doit être le plus facile si l'on fait un ordinateur car il "suffit" de changer de compilateur.

      2) Pas à ma connaissance.

      3) plus ou moins. Le projet fcpu est suffisament compliqué pour ne pas se mettre également à créer des outils qui réclament des compétences très différentes. On "suit" ghdl et je suggère des fonctionnalités :) Le port du f-cpu sous gcc est en court. Un nouveau cpu sans compilo ne sert à rien.

      "La première sécurité est la liberté"

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 1.

      Il y a bien eu "manticore" (voir sur opencollector.org pour les infos) mais c'était du bricolage. Avec F-CPU, il faudrait intégrer le contrôleur vidéo sur la même puce que F-CPU pour faciliter plein de choses.

      Mais il ne faut pas oublier que pour fonctionner un jour, le projet doit se fixer des limites, et la carte vidéo n'est pas du tout le but.

      YG

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  (site web personnel) . Évalué à 3.

    - Comment peut-on se motiver devant un projet d'une telle ampleur?

    - Comment les meilleures idées de design peuvent-elles être intégrées?

    - J'ai mangé les sources, mais je digère pas, que puis-je faire?

    Beatnick qui aimerait vraiment avoir un f-cpu pour faire tourner son vim

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  (site web personnel) . Évalué à 4.

    Et après, que ferez vous quand le processeur sera fini ;-)

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 6.

    A quel est type de machine est destiné f-cpu ? Quelles performances en attendent ses développeurs ? A quel processeur ressemble(ra)-t-il le plus ? A moins que ces questions n'aient pas encore de réponse ...

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 6.

      F-cpu était destiné aux workstation mais sera plutot utiliser dans l'embarqué, set-top box et autre pda à mon avis.

      Les perfs... disons qu'il est "one way" ce qui simplifie les choses mais le rend moins performant. D'un autre coté, le jeu d'instructions est riche. Si ton compilo sait utiliser le SIMD, il peut être très rapide.

      Le f-cpu ressemble beaucoup au SH5/ST50.

      "La première sécurité est la liberté"

      • [^] # Re: 10 questions à l'équipe f-cpu

        Posté par  . Évalué à 3.

        Puisqu'on parle de l'embarqué, le F-cpu integret'il des fonctions d'economie d'energie ou de variation de frequence ?

        Est il possible de predire une consomation moyenne du F-cpu sans processeur physique ? ( en fonction de la finesse de gravure bien entendut )

        • [^] # Re: 10 questions à l'équipe f-cpu

          Posté par  (site web personnel) . Évalué à 1.

          Puisqu'on parle de l'embarqué, le F-cpu integret'il des fonctions d'economie d'energie ou de variation de frequence ? C'est trop spécifique à une implémentation particulière. Mais c'est envisagé, on pourrait par exemple contrôler le facteur multiplicateur de la PLL par un SR par exemple. Mais ça dépend trop de l'implémentation pour pouvoir être correctement spécifié. Il faut rappeler quand même qu'on ne peut pas à la fois fonctionner à 1mW et délivrer 500MOPS. ça se saurait. Le premier objectif est de fournir le plus de performance possible par cycle d'horloge, et ensuite on regarde où on fait des opérations inutiles pour économiser un peu. YG

          • [^] # Re: 10 questions à l'équipe f-cpu

            Posté par  (site web personnel) . Évalué à 1.

            On pourrait surtout mapper la PLL dans l'espace d'adresse IO, je ne voix pas l'interret d'un SR dans ce cas.

            Sinon, coté architecture, les unité de calcul embarques des "enables" qui peuvent servir pour faire du clock gating.

            "La première sécurité est la liberté"

            • [^] # Re: 10 questions à l'équipe f-cpu

              Posté par  (site web personnel) . Évalué à 1.

              Les SRs sont faits pour éviter les effets de bord du pipeline, protéger les ressources à un niveau très fin (pas au niveau page) et amortir le fait que chaque CPU (dans un système hétérogène) peut avoir des ressources diffférentes, et donc une carte des SRs différente.
              Finalement ça simplifie beaucoup (sinon on se retrouve avec des conneries d'arbitrage si on a plusieurs CPUs). Ya aucun intérêt à mapper les registres de contrôle de PLL (et plein d'autres) en mémoire.

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 2.

    Que penser de la course à la vitesse / puissance d'intel et d'amd, avec maintenant des processeurs d'1 cm2 dissipant plus de 75 w ?
    Votre stratégie est-elle différente, et dans ce cas, peut-on espérer voir des processeurs dont les capacités, en terme de performances, soutiendraient la comparaison ?

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 2.

      Les objectifs ne sont pas seulement technologiques.

      Si qqn veut implémenter 10 coeurs F-CPU sur une puce en ECL ou en InP, c'est lui qui voit ! Les sources sont "libres" et les industriels ont aussi leur rôle à jouer.

      De toute manière on ne peut pas obtenir les puissances atteintes par les autres fondeurs sans déployer les moyens nécessaires. C'est arithmétique.

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 5.

    Sur votre site internet, on peut voir une roadmap indiquant qu'il n'y a pas de planification dans le temps car f-cpu n'est pas un projet commercial.
    Pourtant d'autres projets libres prévoient des dates afin de pouvoir toucher le grand public.
    a. Pourquoi ce choix ? Ne pensez vous pas qu'il s'agit d'une erreur non pas informatique, mais sociologique ?
    b. Ou pensez vous en être entre le travail effectué / restant à faire ?

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  . Évalué à 4.

      C'est plutôt le signe sain que cette équipe ne perd pas de temps à faire de l'astrologie, qui comme chacun sait ne marche pas dans le cadre de tels developpements : vous avez déjà vu un projet livré en tant voulu ? Si oui c'est probablement que vous êtes encore à l'école et pas en milieu professionnel.

      Comme le dit si bien la FAQ les hackers expliqués aux managers, pour un vrai hacker prévoir le temps qu'il faudra à résoudre un problème équivaut à résoudre ce problème.

      • [^] # Re: 10 questions à l'équipe f-cpu

        Posté par  (site web personnel) . Évalué à 1.

        Il y a aussi un problème plus simple : étant donné qu'on est toujours à la bourre, si on met une date elle sera dépassée de plusieurs années au moins. Alors le site web pourra donner l'impression qu'il est abandonné, donc plus crédible, alors on ne met pas de date ...

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 3.

    1) TCPA :
    Dans la tourmente Palladium et autre Trust Computing, Quelle est l'attitude des membre du FCPU ?
    Pas de fonction de sécurisation,
    Une fonction "compatible" et documentée,
    Un dispositif chargé de leurer les systèmes "adverses" ?

    2) Microcontrôleur :
    Quid d'une version embarquée du FCPU ?
    Pour un futur robot open source ou plus simplement des produits électroniques domestiques.

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 1.

      1) on se demande encore quelle va être la méthode pour éviter
      que ça pollue F-CPU

      2) il existe déjà une floppée de uC "libres" (disons : open source). F-CPU s'attaque aux segments supérieurs. ça servirait à quoi, pour un robot, de faires des opérations SIMD à plusieurs centaines de MHz ?

      http://www.fpgacpu.org/(...) contient de bons exemples de CPUs optimisés pour les petits FPGA. comme quoi il n'y a pas que Opencores. Et puis sinon kes PICs et AVRs sont largement utilisés.

      YG

  • # 10 questions à l'équipe f-cpu, 10 !

    Posté par  . Évalué à -2.

    1) le f-cpu est-il avec ou sans OGM ?
    2) le f-cpu est-il oral ou ... ?
    3) le f-cpu est-il un composé organique genre fido boulette ?
    4) le f-cpu coloré vert à pois rouges ?
    5) le f-cpu est-il utile pour s'habiller ?
    6) le f-cpu est-il compatible avec les affaires qu'on a déja ?
    7) le f-cpu est-il remboursé par la sécurité sociale ?
    8) le f-cpu est-il utile pour séduire les femmes ?
    9) le f-cpu est-il utilissable pour faire crier les femmes ?
    10) Est-ce que le f-cpu parfois se blo

    • [^] # Re: 10 questions à l'équipe f-cpu, 10 !

      Posté par  . Évalué à 0.

      Faut pas leur en vouloir d'être si méchants. Y zétaient pas né quand Coluche passait à la télé. ils t'en veulent de le leur rappeler. Pour eux l'humour, c'est Lagaff (Y l'est encore à la télé lui ?).

      Quand ils zauront notre âge, ils regretteront. Ils diront: c'était le bon temps, les jeunes de maintenant ils ont plus d'humour. Ils savent que regarder staracadémie
      en disant du mal de Kde, de Gnome, de Vim, de Emacs, des trôleurs.

      Allez je te plusun.

  • # Re: Yann Gudon et le logo f-cpu

    Posté par  (site web personnel) . Évalué à 2.

    J'ai une bonne photographie de notre ami Yann Guidon (alias whygee). Il présente le logo f-cpu. C'était le 12 juillet 2003 aux RMLL / LSM2002 à Bordeaux.
    Vous pouvez la voir sur l'URL temporaire : http://perso.wanadoo.fr/jarillon/docs/Yann_Guidon.jpg(...)

  • # Re: 10 questions à l'équipe f-cpu

    Posté par  . Évalué à 4.

    Bien que parfaitement convaincu de l'interêt de la démarche, je me pose encore quelques questions :

    - comment arriver à une workstation basée sur f-cpu ?
    qui va concevoir la M/B ? il faudrait en toute logique une free-M/B...
    comment le faire en contournant les brevets intel et autres ?
    faudrait des bus PCI/USB/AGP... sous licences ?
    est-ce votre intention ? ou vous vous limitez au point suivant ?
    - sera-t-il alors réduit aux SOC/ASIC ?
    faudra-t-il s'appeller ST ou Philips pour avoir la possibilté de l'utiliser ?
    autrement dit les utilisateurs ne seront-ils que des fondeurs ou de riches sponsors ?
    - comment sera-t-il fondu ? le sera-t-il sous forme de CPU ? CPU+CPLD ?
    devra-t-on se résigner aux FPGA ?

    à 1 million le run de fonderie... nous sera-t-il vraiment accessible à nous petits lusers ?
    quelles sont vos intentions, au delà de concevoir un modèle VHDL d'un CPU de qualité, au delà de la réduction des frais R&D de nos (très) chers fondeurs ?

    • [^] # Re: 10 questions à l'équipe f-cpu

      Posté par  (site web personnel) . Évalué à 3.

      1) là il s'agirait de faire un free computer.

      C'est complètement en dehors du projet bien assez ambitieux comme ça !

      Les PCI et autre usb sont pourris de licences intel qu'il faudrait bien faire payer ... à moins d'imposer un standart ouvert.

      2) Cela risque d'être ça. Les utilisateurs seront les industriels de la microelec. Le système produit peut ensuite être utiliser n'importe où. La, on rentre dans de l'industrialisation, le cout de reproduction n'est pas libre.

      3) vu la taille du multiplieur cela n'est pas près de rentrer dans un fpga :) Mais qui sait ! Un downgrade pourra peut-être tourner dessus :)

      Il n'y a surtout pas que les fondeurs de visé mais toute les petites boites qui font des puces pour plein d'application diverse et varié (et qui achètent des licences ARM...).

      "La première sécurité est la liberté"

      • [^] # A propos de multiplieur

        Posté par  (site web personnel) . Évalué à 1.

        Il fait quel taille le multiplieur?
        Dans les virtex-II de Xilinx il y a des multiplieurs câblé 18x18bits, avec 2 multiplieurs ça fais déjà un 36x36, suffisant pour du calcul sur 32 bits!

        Le problème, c'est qu'un de ces FPGA doit déjà coûter dans les 5000 à 10000 euros!

        Il me vient une question, comment vous comptez le tester si vous n'utilisez pas de FPGA?

        Il y a toujours des problèmes (la métastabilité par exemple) qu'on ne peut pas vraiment repérer en simulation logicielle.

        Et pour réussir à booter un OS en simulation, ça doit être vraiment long!

        • [^] # Re: A propos de multiplieur

          Posté par  (site web personnel) . Évalué à 3.

          Dans les virtex-II de Xilinx il y a des multiplieurs câblé 18x18bits, avec 2 multiplieurs ça fais déjà un 36x36, suffisant pour du calcul sur 32 bits!

          Pour faire un 36*36 avec des 18*18, il doit falloir plus de 2 multiplieur, j'ai pas trop envie de réflechir mais je dirais 4. De plus le f-cpu est 64 bits (en fait 64 bit SIMD, pipeliné 6x avec sortie SIMD 8 16 et 32 bits).

          Il me vient une question, comment vous comptez le tester si vous n'utilisez pas de FPGA?

          En utilisant plusieurs de FPGA ? :)

          Il y a toujours des problèmes (la métastabilité par exemple) qu'on ne peut pas vraiment repérer en simulation logicielle.

          ? Euh, si le design est synchrone il n'y a pas de problème. Sinon, ce n'est pas une maquette fpga qui te donnera la réponse mais une analyse de timing.


          Et pour réussir à booter un OS en simulation, ça doit être vraiment long!
          1:100000 en gros pour le temps de simulation rtl.

          Mais il y a un simulateur soft en développement (avec des temps en 1:10 beaucoup plus acceptable).

          "La première sécurité est la liberté"

          • [^] # Re: A propos de multiplieur

            Posté par  (site web personnel) . Évalué à 2.

            [...] il doit falloir plus de 2 multiplieur [...]

            Effectivement, il en faut 4... J'aurais du réfléchir avant d'écrire!

            ? Euh, si le design est synchrone il n'y a pas de problème. Sinon, ce n'est pas une maquette fpga qui te donnera la réponse mais une analyse de timing.

            Ouai, si le design est synchrone ya pas ce problème, et une analyse de timing doit pouvoir marcher entre différent domaine d'horloge tous synchrone, si par soucis de consommation vous utilisez du clock gating.

            Maintenant si il y avais plusieurs domaines asynchrones (effectivement dans un cpu on voit pas bien ce que ça ferais la) je crois pas qu'un analyseur soit capable de dire grand chose. Il va signaler une violation sur toutes les bascules qui reçoivent une donnée provenant d'un autre domaine d'horloge, sans pouvoir dire si ça marchera ou pas.

            Et le faire tourner sur FPGA (carte proto, ou accélérateur matériel) ça peut permettre de trouver des bugs, mais ça reste non exhaustif.

            Mais il y a un simulateur soft en développement

            C'est bien un simulateur soft, mais ça ne teste pas le code rtl.

            Mais apparemment t'en es bien conscient puisque ta première réponse est "En utilisant plusieurs de FPGA".

            Ceci dit, si ça peut tenir dans un seul gros FPGA, c'est bien plus facile, car franchement partitionné un design pour le faire rentrer dans plusieurs FPGA, c'est pas évident! Et les outils ont encore des progrès à faire avant d'y arriver correctement de manière automatique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.