vendredi 10 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Presse

[16] LOGIN: n°91
[55] Zataz Mag : les 3l33tz parlent aux 3l33tz
[24] Dmitri Sklyarov est libre!
[46] Linux Mag 35 (Janvier 2002) est arrivé...
[10] DVDRom Hors Série Linux Mag
[20] Star Office commence sa longue marche Asiatique
[112] Les logiciels libres dans "La Recherche" de Janvier
[30] La MACIF bascule vers les logiciels libres
[38] Hors Série Internet de Libération et Transfert
[7] Login HS spécial XML

Liens connexes

Site du F-CPU (1164 hits)
Linux Mag (1356 hits)

Dépêche modérée par

Presse : Article sur le FCPU de LMF

Posté par Nicolas Boulay (). Modéré le 08 janvier 2002.

J'ai l'impression que l'article concernant le F-CPU paru dans le Linux Mag de Janvier a été un peu difficile à comprendre pour beaucoup.

J'aimerais avoir un feed-back pour voir les points qui coincent. Si ceux qui ont lu l'article pouvait laisser un commentaire, cela m'aiderait beaucoup.

Note du modérateur: Ceci n'est pas vraiment une nouvelle mais vu la qualité des articles de Nicolas dans LMF... nous encourageons les lecteurs à lui répondre.

Linux Mag (1356 hits)
Site du F-CPU (1164 hits)

> Lire les commentaires (85 commentaires, moyenne: 5,1).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

une petite reponse qui vaut ce qu'elle vaut...

Posté par blackshack (page perso, ) le 08/01/2002 à 10:29. (lien). Évalué à 29.

c'était un bon article, mais pour moi qui ne suis pas expert en micro electronique certains passages étaient et sont tjrs d'ailleurs quelques peu obscures mais grossierement compréhensibles qd meme mais si des finesses m'ont surement echappes. Sinon cela montre bien l'interet, difficultes et avantages d'un tel projet.
esperons qu'il continu

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

Posté par SoWhat () le 08/01/2002 à 11:08. (lien). Évalué à 29.
je ne suis pas expert non plus mais j'ai quelques notions, c'est vrai. En fait, je vois mal comment on pourrait mieux expliquer en moins de mots. La couverture technique de cet article est quand même assez vaste!
J'ai bien aimé les points sur le choix de la license et tout ce qui s'en suit.
Les points réellement techniques d'un tel article ne peuvent de toute façon pas s'adresser à de vrais débutants. J'ai trouvé cet article très interressant ( ok, je ne ferait plus de récursif avec des proc sparc, promis ;). bravo.

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

Posté par Troy McClure (page perso, ) le 08/01/2002 à 11:33. (lien). Évalué à 15.
moi aussi j'ai eu l'impression de comprendre, j'ai trouvé que l'article était un des plus intéressants du numéro et bien écrit qui plus est (je le dis parce que c'est rare de prendre plaisir à lire un article malgré tout plutot technique).

--
poulpe !
- [^]Re: une petite reponse qui vaut ce qu'elle vaut...
  
  Posté par Troy McClure (page perso, ) le 06/02/2002 à 21:00. (lien). Évalué à 1.
  taiste
  - [^]Re: une petite reponse qui vaut ce qu'elle vaut...
    
    Posté par Troy McClure (page perso, ) le 06/02/2002 à 21:02. (lien). Évalué à 1.
    zut retaiste
    - [+] [^]Re: une petite reponse qui vaut ce qu'elle vaut...
      
      Posté par Troy McClure (page perso, ) le 06/02/2002 à 21:06. (lien). Évalué à -1.
      ultime taiste

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

Posté par Jean-Noël Avila (page perso, ) le 08/01/2002 à 13:35. (lien). Évalué à 17.

Ces articles ne contiennent pas de finesses particulières vu qu'ils présentent des panoramiques de la technologie. Bien qu'ils soient tout à fait compréhensibles si on possède des bases en architecture informatique, il est regrettable qu'il attaque de manière trop abrupte certains points (ex : gestion de cache dans un processeur).

Le fait qu'il soit généraliste aurait du guider vers une approche plus douce, en évitant les non-dits. Je suis certain que celà aurait évité cette impression de "finesses cachées".

Par contre, les parallèles entre architectures internes et architectures distribuées sont saisissants. Ce sont des analogies comme celle-ci qui fournissent de bons repères pour la compréhension.

Enfin, je crois qu'il aurait fallu plus d'exemples chiffrés pour éclairer les principes (d'autant plus que des exemples d'architectures sont cités).

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

Posté par William Steve Applegate (page perso, ) le 08/01/2002 à 14:23. (lien). Évalué à 13.
Personnellement, je ne peux m'empêcher de me demander pourquoi Nico tient tant à ce que son article soit compris par tout le monde. Un projet comme le F-CPU a besoin (AMHA) de contributeurs ayant déjà un certain niveau d'expertise. Dans ces conditions, de deux l'une : soit (1) on comprend l'article, on a donc les connaissances nécessaires et l'article a des chances de nous amener à participer au projet, soit (2) on n'y comprend rien (perso, je n'ai pas compris un certain nombre de choses, par exemple pour ce qui est du fonctionnement exact de la prédiction de branchement - et, je vous l'avoue, ça ne me fait ni chaud ni froid, vu que je ne programme pas en ASM et que le compilo s'occupe de la tambouille derrière) et dans ce cas, on n'est pas la cible de l'article. Point. En cela, je pense qu'il atteint parfaitement son but. Maintenant, j'imagine que l'auteur cherche à faire connaître son projet au plus grand nombre. C'est louable, mais... ça sert à quoi, si tous ces gens ne peuvent rien faire pour celui-ci ?

--
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™
- [^]Re: une petite reponse qui le vaut bien ...
  
  Posté par Nicolas Boulay () le 08/01/2002 à 14:43. (lien). Évalué à 18.
  Interrescant ton point de vue.
  
  Article pour pro : donc plus il est pointu, plus il est interrescant.
  
  Article pour neuneu : je ratisse large mais cela ne servirai pas à grand chose.
  
  Mouais.
  Je pense pas que le Finnois serait pas super heureux si seulement 1% des lecteurs seraient capable de comprendre les articles.
  
  Le but de genre d'article sont multiples :
  - Faire découvrire (aimer?) le hard
  - Faire connaissance avec les CPU
  - Faire du prior art (pour lutter contre d'hypothètique brevet)
  - Attirer des bons
  - Faire comprendre que le projet est sérieux
  - Faire exploser nos ego...
  
  Concernant les "moins" bon, il y a du gros travails de mise en forme et gestion de site web. De plus, les petits jeunes qui s'y mettent sérieusement peuvent aider après 1 an ou 2, à avoir lu et appris sur le sujet (compilation, microarchitecture, algorythme pour les unité de calculs, codage VHDL...).
  - [^]Lefinnois, pas le Finnois, inculte ;)
    
    Posté par Denis Bodor (page perso, ) le 08/01/2002 à 17:30. (lien). Évalué à 5.
    Je pense pas que le Finnois serait pas super heureux si seulement 1% des lecteurs seraient capable de comprendre les articles.
    
    Attend, je decortique....
    
    [decortiking....]
    0%...25%....50%...75%...100%
    [decortiking done !]
    
    C'est vrai, je pense que je ne serait pas super comptant si seulement 1% des lecteurs comprennent ce qu'ils lisent, autant pour eux, que pour moi que pour la boite :)
- [^]Re: une petite reponse qui vaut ce qu'elle vaut...
  
  Posté par Guidon Yann (page perso, ) le 08/01/2002 à 15:09. (lien). Évalué à 31.
  bonjour,
  
  quels que soient mes reproches envers nicO (ça se règle souvent autour d'une table avec un crayon et beaucoup de papier :-D), ses efforts auront été cela : une continuation du projet, pour permettre de le faire mieux connaitre. Pour le reste, nicO est majeur et responsable.
  
  Personnellement, j'ai souvent plusieurs discours selon la personne à laquelle je m'adresse : soit un non-initié qui n'a jamais vu le comp de comp.arch, je lui tends alors la "brochure" qui présente rapidement le projet sans l'effrayer.
  Il y en a une qui traine à http://www.f-cpu.de/brochure/(...) si cela vous dit.
  
  Puis il y a ceux qui sont avides de sensations fortes et là, c'est le manuel qu'il faut leur tendre. Une vieille version
  est disponible en ligne à http://www.f-cpu.de/man/i7/summary.html(...) (depuis, on a commencé à écrire du code et le délégué au manuel n'a pas fait tout son boulot, veuillez l'excuser).
  
  Enfin il y a les spécialistes du VHDL et là c'est http://www.f-cpu.seul.org/new/stable_yg_12_31_2001.tgz(...)
  Il y a plein de choses dont un HOWTO sur l'utilisation des outils de VHDL. La version française "non-geek" paraitra dans LM bientöt.
  
  Il y a encore d'autres sites externes, plus ou moins mal foutus (et surtout peu à jour) à voir sur http://www.f-cpu.org/(...)
  comme celui de Philippe Trbich http://philippe.trbich.free.fr/(...)
  qui a traduit une partie du manuel http://philippe.trbich.free.fr/pub/fcpu/manuel/(...) mais je m'égare.
  
  Peut-être nicO a-t-il voulu en faire trop à la fois ?
  Il y a des fois où je me sens pas, quand j'écris du code ou des articles.
  Au moins, à défaut de demander les réactions avant publication, il demande après :-)
  
  Quant à programmer en ASM, j'en ai fait assez sur x86 pour te dire ... que F-CPU est plus facile :-) Il est certain que des techniques avancées et récentes de programmations sont nécessaires et peu développées, mais ce n'est rien comparé au casse-burnes d'Intel.
  Code à l'appui.
  Quant aux compilos, ils crachent ce qu'on leur donne : je ne les utilise que parce que je développe un algo ou parcequ'il faut qu'il soit portable sur d'autres archis.
  
  Pour ce qui est de l'expertise, oui on a besoin de gens qui ont tâté du Synopsys ou de l'ATPG, mais aussi de personnes "normales" (hmm, oui, ça existe). A trop faire de la technique, le projet d'assoce 1901 n'avance pas, et les sites webs sont devenus complétement chaotiques...
  Si vous voyez ce que je veux dire.
  
  Au fait pour la prédiction de branchement l'état actuel c'est : y'en a pas pour FC0. En fait il y a 1 cycle de pénalité par branchement pris, mais c'est trop peu pour justifier du HW supplémentaire. En plus le pipeline du FC0 est "OOOC" et ne supporterait pas une exécution spéculative, donc la prédiction ne sert à rien pour l'instant. Mais on a réservé des espaces pour les implémentations plus compliquées que FC0, au cas où.
  
  Toutefois la prédiction de branchement est un mécanisme qui peut devenir critique pour un programme : il n'y a qu'à lire les chapitres de recommandations des fabricants comme Intel (X86, ia64 et autres), Motorola/IBM (POWER, PowerPC), Digital/Compaq (Alpha) etc pour voir que le style de programmation influence lourdement l'efficacité du code, et cela même à un haut niveau d'abstraction. Je pense que trop de monde se moque de ces "détails" qui font que le code "a l'air moins beau" mais terriblement plus efficace. Ce sont ces mêmes personnes qui sont ensuite embauchées dans les boites pour cracher du source toute la journée, des usines à gaz qui nécessitent des machines toujours plus grosses pour faire encore moins... En cela, je pense que les articles de nicO sont importants. Peut-être cela incitera les gens à lire "le Zen de l'optimisation" de Michael Abrash, par exemple ?
  
  YG

[+] RAV

Posté par Infernal Quack (Jabber id, page perso, ) le 08/01/2002 à 10:35. (lien). Évalué à -14.

La section de cette news aurait dû être RTFM (plus approprié AMA)

Mais bon MA n'est pas parole d'évangile et puis je préfère MA~ ;)

article plus général

Posté par gui_ () le 08/01/2002 à 11:19. (lien). Évalué à 17.

Ce qui me plairai, c'est d'avoir un article un peu plus général sur les microprosseceurs et les technologies employées dans ceux ci. L'article sur le F-CPU parle du F-CPU (heureusement :-) mais j'aimerai avoir une vue d'ensemble du monde des CPU avant de m'interesser à un CPU en particulier.

En tout cas, merci pour les articles de LMF qui sont toujours interessant, même si l'on est pas un expert.

[^]Re: article plus général

Posté par furai (page perso, ) le 08/01/2002 à 11:41. (lien). Évalué à 1.
Il y en a deja eu au moins 1 sur le pentium IV, dans le numero precedent.
- [^]Re: article plus général
  
  Posté par gui_ () le 08/01/2002 à 12:45. (lien). Évalué à 5.
  Je l'ai lu, mais il était consacré à un microprocesseur en particulier. Moi j'aimerai avoir un article sur les microprocesseurs en général, pour pouvoir comprendre, en gros, leurs fonctionnement. Connaitre le rôle de chaque composants plutôt que d'avoir une description des composants présent dans tel microprocesseur sans savoir vraiment comment ils fonctionnent.
  En gros, un article d'initiation et de vulgarisation pour un neuneu complet.
  - [^]Re: article plus général
    
    Posté par Marc (Jabber id, page perso, ) le 08/01/2002 à 22:35. (lien). Évalué à 0.
    on s'eloignerait pas un peu du sujet du magasine la?
    f-cpu est u nbon sujet vu que ca parle de libre etc etc. Un article sur le fonctionement d'un processeur sortirait pas du cadre?

[^]Re: article plus général

Posté par Sylvain Rampacek (Jabber id, page perso, ) le 08/01/2002 à 11:48. (lien). Évalué à 6.
Je m'avance peut-etre, mais le problème avec l'architecture des processeurs, c'est qu'elle n'est, bien souvent, pas libre.

Donc pour faire un article sans dévoiler les secrets de la construction à la concurence risque d'etre difficile.

Mais sinon en cherchant RISC/CISC sur google, on peut trouver quelques articles intéressant.
Comme celui ci sur les proc RISC de HP : http://www.cpus.hp.com/technical_references/parisc.shtml(...)
- [^]Re: article plus général
  
  Posté par Patrice Karatchentzeff (page perso, ) le 08/01/2002 à 14:36. (lien). Évalué à 11.
  Donc pour faire un article sans dévoiler les secrets de la construction à la concurence risque d'etre difficile.
  
  Non. Pas libre ne veut pas dire ferme. Tout fait l'objet de depose de brevet et ces brevets sont publics (enfin, ceux que l'Armee ne censure pas ;-) ).
  
  On peut tres bien faire un article dessus et expliquer tout le mecanisme. C'est l'implemantation qui est protegee. C'est tout.
  
  PK

[^]Re: article plus général

Posté par bertran dherouvi () le 08/01/2002 à 12:11. (lien). Évalué à 1.
microprocesseurs avec 1 C et 2 S, ça tourne plus vite ;-)
- [^]Re: article plus général
  
  Posté par gui_ () le 08/01/2002 à 12:46. (lien). Évalué à 3.
  Oula! C'est vrai que je fais beaucoup de fautes, mais celle là est vraiment pas mal :-)
  Contrairement à d'autre, j'aime bien que l'on me corrige, ça me permet d'apprendre (sauf que là, je connaissais la bonne orthographe, c'est plutôt de l'inatention).
  Ce serait bien si certain pouvaient avoir un rôle de modérateur orthographique. Ils n'auraient pas le droit de toucher au contenu des commentaires, mais pourraient corriger les fautes.
  Mais bon, qui à le temps de faire ça?
  - [+] [^]Re: article plus général
    
    Posté par Aurélien Jarno (page perso, ) le 08/01/2002 à 14:07. (lien). Évalué à -4.
    Ou alors avoir ispell/aspell qui nous corrige les fautes lorsqu'on poste un commentaire. Ca ne corrige pas les fautes de grammaire, mais ça éviterai déja les fautes d'orthographe.
    
    Bon aller -1 car HS.
  - [^][HS] Or tau Graff
    
    Posté par ptifeth (page perso, ) le 08/01/2002 à 15:14. (lien). Évalué à 1.
    Pas d'accord.
    Il arrive à quasiment tout le monde de faire des jeux de mots plus ou moins légers... sans compter l'emploi d'homonymes, de mots étrangers...
    Une "revue et correction" effectuée par un autre que l'auteur risque à mon sens d'être très préjudiciable aux commentaires.
    
    En revanche je trouverais chouette une moulinette facultative via aspell lors de la soumission d'un commentaire.
    Encore mieux si cette moulinette proposait la francisation des termes techniques pour lesquels un équivalent technique existe !
    
    I set to -1 because the post is off topic.

[^]"Hack en C" ? et +

Posté par Nicolas Boulay () le 08/01/2002 à 12:44. (lien). Évalué à 12.
Disons que j'avais visé ce genre d'explications généralistes dans l'article sur le "hack en C". Les technique de codage n'était qu'une excuse "pratique" pour faire découvrir les techniques des CPU.

Sinon Personne n'a de points particuliers à soulever ? Je pourrais en remettre une couche dans un prochain article sur tous ce que je n'ai pas mis dans celui-ci ? ;p

Sinon merci à tous pour vos remerciements, j'ai les chevilles qui vont exploser.
- [^]franchement...
  
  Posté par blackshack (page perso, ) le 08/01/2002 à 13:32. (lien). Évalué à 2.
  remets en une couche même du même niveau, cela pousse a bien faire attenetion a ce que tu dis, et donc a essayer de comprendre, en clair on se couche moins con. vas-y continue sur ta lancé, cpu ou autre hardware d'ailleurs. Et d'ailleiurs si qq'un a la reponse à l'utilité d'un bios dans une carte mere -il me revient vaguement l'existence de projet de cm sans bios, mais...-?
- [^]dégonflage de chevilles
  
  Posté par Guidon Yann (page perso, ) le 08/01/2002 à 13:46. (lien). Évalué à 30.
  salut :-)
  
  Il y a plusieurs points que je voudrais soulever.
  
  D'abord le nombre de fautes d'orthographe, d'accord etc. mais on peut mettre ça sur le dos de la rédaction qui n'a pas corrigé ou même relu. C'est pourtant pas sorcier, c'est pas de la technique.
  
  Ensuite, il y a plusieurs cafouillages comme confondre "word" et "world". Je n'ai pas l'article sous les yeux (je crois que c'était pour "VLIW") mais j'ai noté plusieurs trucs qui m'ont fait sursauter. Passons.
  
  Faire sauter le "-" : je n'en ai rien à faire, tu es majeur et tu sais que seule l'orthographe "F-CPU" est déposée à l'INPI et à l'ICANN. C'est pour cette raison-là que j'essaie de me tenir à cela.
  sachant que fcpu.com était déjà pris au moment d'acheter la marque et le DNS, on a dû choisir la version avec "-". Voilà pour la petite histoire : le "-" n'a aucune signification mais son en son absence on n'est pas à l'abris des emmerdes.
  
  Je me souviens aussi des paragraphes sur le SRB : c'est pourtant marqué dans le manuel et ça veut dire "Smooth Register Backup", une technique destinée à réduire la latence des interruptions et de la sauvegarde du contexte précédent, grâce à une assistance HW pour
  sauvegarder les registres au fur et à mesure de leur besoin. C'est ça qui a permis à l'époque de faire avaler la pilule des 64 registres, ce qui prendrait au moins 64*4=256 octets et 64 cycles pour sauvegarder en utilisant des instructions ! Avec un peu d'astuce et en ajoutant qqs circuits bien conçus, plus de problème.
  On peut retrouver la justification même dans le vieux manuel pourri en ligne (voir http://www.f-cpu.de/man/i7/part4.html#SRB(...) ).
  
  Il y a encore d'autres trucs mais c'est plutôt le genre de détail qui n'a pas d'importance pour ceux qui découvrent, je n'ai pas non plus envie de te descendre en flèche ou de passer pour un vieu crouton :-)
  
  La vraie conclusion c'est que toutes ces erreurs auraient pu être évitées par une relecture croisée. Personne n'est parfait mais les solutions sont bien connues. J'espère aussi que les prochains articles seront plus posés, plus clairs et plus structurés afin de ne pas noyer les pauvres linuxiens sous une montagne de termes trop "l33t3" :-) déjà que j'y comprends rien à LDAP, IPsec, j'utilise ni CVS ni GPG...
  
  publicité gratuite : j'ai écrit un article qui paraitra probablement dans le prochain numéro de LM. J'espère que ce sera suffisamment accessible et que des personnes oseront installer et lancer les outils décrits.
  
  J'ai aussi dans mon "pipeline" un article encore plus dingue que le premier article de nicO dans LMF. Ca présente les méthodes de codage pour programmer en RISC et évidemment en utilisant les règles de codage du FC0. En plus c'est super-utile car le code est une DCT de Winograd, le truc qui permet de faire l'analyse spectrale de 8 échantillons avec seulement 5 multiplications :-)
  
  Allez, dernière URL : les sources les plus frais sont à http://f-cpu.seul.org/new(...) : bon surf :-) La dernière archive qui j'y ai uploadé (http://f-cpu.seul.org/new/stable_yg_12_31_2001.tgz(...)) est considérée comme "stable" mais on continue à travailler dessus. Ca permet au moins d'utiliser les outils décrits dans l'article prochain, car toute la procédure de compilation a été remise à plat.
  
  YG (qu'a pas un seul XP mais j'men fous, j'ai jamais vu nicO mouler sur la tribune :-P)
  - [^]vi
    
    Posté par Denis Bodor (page perso, ) le 08/01/2002 à 17:05. (lien). Évalué à 2.
    l'article en question dans le prochain LM il sera... :)
    - [+] [^]Re: vi
      
      Posté par Guidon Yann (page perso, ) le 08/01/2002 à 17:32. (lien). Évalué à -1.
      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...

[^]Re: article plus général

Posté par a_jr () le 08/01/2002 à 14:02. (lien). Évalué à 17.
mais j'aimerai avoir une vue d'ensemble du monde des CPU avant de m'interesser à un CPU en particulier.

Moi aussi.

D'autre part, ce qui manque a un tel article, c'est une sorte de glossaire. Les termes sont expliques, mais quand on est 2 pages plus loin et qu'un terme revient, on hesite a revenir 2 pages en arriere pour relire la signification du terme dont on n'a pas retenu la signification.

D'autre part, et ce serait tres en relation avec Linux ou Hurd, ce serait interessant d'avoir un article sur les pilotes du noyau. Non pas la vision du programmeur (quoique, y'a deja eu un article comme ca, et un autre ne serait pas de refus), mais la vision d'un gars en microelec.

Un truc interessant serait aussi une rubrique de bricolage, a savoir realiser puis brancher un thermometre sur linux, ou un detecteur de n'importe quoi. Je suis sur que de nombreux hackers s'amuseraient comme des fous si on leur fournissaient la maniere de creer un emetteur/recepteur infrarouge simple, pour apres commander la tele ou le lecteur video via linux, voire faire du reverse-engineering sur le protocole de communication du telephone portable. Sans oublier ceux qu'ont une calculatrice evoluee...

Le bonjour chez vous,
Yves
- [^]Re: article plus général
  
  Posté par Guidon Yann (page perso, ) le 08/01/2002 à 15:15. (lien). Évalué à 4.
  Je crois que Denis Bodor (rédac'chef de LM) a une idée de Hors Série à ce propos. A vos fers à souder !
  - [^]Re: article plus général
    
    Posté par Xavier B. () le 08/01/2002 à 16:54. (lien). Évalué à 5.
    Puisqu'on ne me le demande pas, je suis carrément intéressé par une suite d'article de ce style, et même, je ne pense pas être le seul à vouloir utiliser ma machine linux pour piloter des montages, causer avec un µ contrôleur ( programmé à partir du même O.S. bien sur, avec les outils linux, etc ...), ATMEL AVR, s'pas ?
    
    Hein, je ne suis pas le seul ?
    
    Hého ?
    - [^]Re: article plus général
      
      Posté par Guidon Yann (page perso, ) le 08/01/2002 à 16:59. (lien). Évalué à 0.
      mmmm linuxAVR.com ?
      
      </déconne>
    - [^]un projet sous le coude
      
      Posté par Denis Bodor (page perso, ) le 08/01/2002 à 17:16. (lien). Évalué à 3.
      vi vi vi :)
      
      les chip USB, des 68hc11, des PIC, plein de petites pupuces qui parles a linux :)
      Allez hop, des idees, des contribs, des voeux :
      
      elect@linuxmag-france.org
      
      et zou :)
      
      Note : attention, soyez gentils, je suis aussi bon en electronique qu'en orthographe (sauf qu'en electronique en confondant vcc et vss ca coute plus cher)
      - [^]Re: un projet sous le coude
        
        Posté par Guidon Yann (page perso, ) le 08/01/2002 à 17:23. (lien). Évalué à 3.
        (sauf qu'en electronique en confondant vcc et vss ca coute plus cher)
        
        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>

article

Posté par johann berchet () le 08/01/2002 à 11:32. (lien). Évalué à 13.

L'electronique c'est tres difficile à expliquer d'autant plus que c'est de plus en plus petit est compliqué.
Ce que je n'ai pas compris sur le F-CPU à part que c'est de la theorie est:
Qui pourrait s'intéresser à lancer ce CPU vu le prix que coute une ligne de fabrication (plusieurs milliards)
AMD? intel? motorola?
A quoi ça leur servirais vu qu'ils ont déjà une techno plus avancée et de la R&D béton?
Ou alors ça permettrais à vivendi-universal de se lancer la dedans? (pour devenir maitre du monde)
Y'a un gars qu'a inveté le moteur à eau mais je le vois pas dans les voitures?

Désolé y'a pas que l'argent qui compte , l'innovation c'est bien mais tant que ça resteras theorique....

[^]Re: article

Posté par Patrice Karatchentzeff (page perso, ) le 08/01/2002 à 12:10. (lien). Évalué à 39.
Qui pourrait s'intéresser à lancer ce CPU vu le prix que coute une ligne de fabrication (plusieurs milliards)

Tu n'as pas tout compris.

Une ligne de fabrication coute en effet fort cher mais uniquement a developper. Une fois l'usine en place (on dit fab dans le jargon), la technologie (on la definit par l'unite de la chose la plus difficile a produire - a savoir la largeur de grille du transistor - comme 0.18 micron ou 0.13 micron), il ne reste plus qu'a produire pour rentabiliser l'ensemble.

Tous les fondeurs procedent ainsi. Ils delivrent une sorte de cahier des charges de leur techno (on parle de DRM pour Design Rule Manual), ils offrent des bibliotheques de cellules standard (portes elementaires, pads, cellule analogique, memoires, etc.) et tout le monde peut fabriquer un circuit a partir de ces donnees chez eux.

Combien cela coute-il ? Techniquement parlant - hormis les couts de developpement du circuit ici assume par des volontaires - le cout du produit s'etale ainsi :

- prix des masques
- prix de revient

Le prix des masques est celui de chaque niveau du circuit dans la techno specifiee (la technique de fabrication d'une puce consiste a empiler successivement un certain nombre de couches (basses comme le silicium et hautes comme les metalisations). Le prix de ces masques depend de la taille du circuit et de la techno : plus elle est fine et plus les masques coutent chers. Pour une techno de l'ordre de 0.18 um et pour un circuit de l'ordre du fcpu, il faut compter entre 100 000 et 300 000 dollars.

Pour le prix de revient, il est evident que le fondeur ne va pas te faire le meme prix pour 10 pieces et pour un million. Il y a des tonnes de parametres qui entrent aussi en jeu : temps de fabrication, rendement par tranche (on dit waffer), temps du test de validation fonctionnelle, prix du boitier, etc.

Du temps du pentium (enorme puce dans la techno d'alors), on parlait d'un cout de production de 85 dollars par piece. Le fcpu etant beaucoup plus petit, on peut esperer descendre de beaucoup ce prix.

Voila pour les couts : ce n'est pas faramineux meme si cela reste cher pour le particulier.

Quant a la philosophie de la chose, Nico te repondra mieux mais en gros, le domaine du hardware est bien pire que celui du software. Quand un produit coute 100 $, il y a grosso modo plus de 80% de royalties a verser a differents possesseurs de licences.

Exemple : dans un decodeur satellite (un SoC typique dont parle Nico dans son article) : il y a un decompresseur MPEG2 (au moins une licence), la gestion du son (dolby, surround, etc. au moins une douzaine de licences), l'algo de cryptage et de decriptage (pareil), etc. Quand on fait le calcul a la fin, c'est faramineux !

D'ailleurs, si vous voulez devenir riche, il suffit d'une bonne idee brevetee. C'est tout.

L'idee du f-cpu est de pouvoir utiliser le f-cpu comme entite (on dit macro) dans un SoC sans avoir a debourser de royalties... et ainsi, en generalisant le systeme, arriver a des SoC a prix tres reduits.

PK

[^]Re: article

Posté par Jak () le 08/01/2002 à 12:26. (lien). Évalué à 21.
Aucun rapport avec AMD ou Intel. Ces derniers possèdent les moyens de fabrication de leurs puces, mais c'est loin d'être le cas en général. ARM, par exemple, ne fait que fournir des licences du noyau de son processeur, ensuite, ceux qui les ont achetées peuvent aller les faire fondre, par leurs propres moyens ou en faisant appel à un fondeur.
Cyrix, par exemple, avant d'être racheté par National SemiConductor, n'a jamais fait autre chose que de la conception de puces. IBM était un des fondeurs, mais il y en avait d'autres.

Là, en effet, quand le projet F-CPU sera fini, n'importe qui pour utiliser les schémas pour vendre son propre processeur (tout en respectant la licence). F-CPU. Il faut admettre que cela demande de gros investissements contrairement au logiciel, ça risque de coûter un peu cher au particulier de faire fondre sa propre puce (mais c'est possible aussi).
Le processeur F-CPU aura beaucoup plus de mal à percer face à AMD, Intel, Motorola, IBM, HP que Linux face à Microsoft, AIX, HP-UX... Mais ce n'est pas le but non plus.

Je pense que le 1er intérêt du F-CPU, une fois finalisé, sera d'offrir à coût réduit un core processeur générique pour les PME/PMI qui pourraient avoir des besoins en circuits sans avoir à payer une licence à ARM, Intel, XIlinx. Il ne pourra commencer à apparaître que dans des circuits spécialisés avant d'être reconnu comme processeur générique, selon moi.
La route sera longue et difficile, je souhaite bonne chance à tous les participants!

--
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
- [^]Re: article
  
  Posté par spim () le 08/01/2002 à 13:37. (lien). Évalué à 1.
  IBM était un des fondeurs, mais il y en avait d'autres.
  
  Au hasard Thomson ;-)
  - [^]Re: article
    
    Posté par Patrice Karatchentzeff (page perso, ) le 08/01/2002 à 14:31. (lien). Évalué à 5.
    SGS-Thomson en fait, c'est-a-dire STMicroelectronics aujourd'hui. Rien a voir avec Thomson. C'est un groupe prive (hmmm) et independant (re-hmmm) depuis plus de dix ans.
    
    En fait, il s'agissait du coeur 486 pour la production. Le coeur Pentium n'a servi que pour calibrer la Fab de Crolles en Isere.
    
    PK
- [^]Re: article
  
  Posté par Raynaud Alain () le 08/01/2002 à 23:50. (lien). Évalué à 3.
  >Je pense que le 1er intérêt du F-CPU, une fois finalisé, sera d'offrir à coût réduit un core processeur générique pour les PME/PMI qui pourraient avoir
  >es besoins en circuits sans avoir à payer une licence à ARM, Intel, XIlinx. Il ne pourra commencer à apparaître que dans des circuits spécialisés
  >avant d'être reconnu comme processeur générique, selon moi.
  >La route sera longue et difficile, je souhaite bonne chance à tous les participants!
  
  On est franc? N'importe quoi. Une license ARM coute moins cher que le masque pour aller chez son fondeur.
  
  Donc tout ton exemple s'ecroule: si tu prends un F-CPU (libre), et tu le fabriques, tu payes un ticket d'entree de $300,000 pour les masques (ca depend de la technologie).
  Alors l'idee que ca permet de court-circuiter une license pour un CPU synthetisable, ca me fait doucement rigoler.
  
  Alain.
  - [^]Re: article
    
    Posté par Patrice Karatchentzeff (page perso, ) le 09/01/2002 à 08:21. (lien). Évalué à 4.
    Donc tout ton exemple s'ecroule: si tu prends un F-CPU (libre), et tu le fabriques, tu payes un ticket d'entree de $300,000 pour les masques (ca depend de la technologie).
    Alors l'idee que ca permet de court-circuiter une license pour un CPU synthetisable, ca me fait doucement rigoler.
    
    C'est parce que tu n'as pas tout compris ;-)
    
    Le ticket d'entree dont tu parles est le meme pour tous... Si on fait un circuit, on paye tous cela.
    
    Maintenant, sur ce circuit, tu mets un coeur ARM ; tu payes toujours ton ticket d'entree mais tu ajoutes le prix du coeur ARM (qui coutent tres cher a la difference de ce que tu dis). Si tu ajoutes une demi-douzaine de macros sous licence, le prix du ticket d'entree peut facilement se voir multiplier par dix...
    
    300 000 dollars est encore assumable par une PME solide. 3 millions de dollars l'eliminent d'entree.
    
    L'interet est donc bien de fournir des macros libres...
    
    nota-bene : dans la vie d'un produit un peu long, le cout final du produit est tres peu impacte par les couts de developpement et surtout ceux des masques. Mais pour dix produits developpes, un seul a vraiment du succes. Il faut donc amortir les cout des autres...
  - [^]Re: article
    
    Posté par Jak () le 09/01/2002 à 08:23. (lien). Évalué à 1.
    Bon, admettons. J'ai pris le (mauvais ?) exemple d'ARM car il s'agit d'un microprocesseur générique comme le F-CPU.
    Mais je pensais à l'achat de core déjà fait, par exemple le core PCI de chez Xilinx, qui n'est pas donné. Et il doit même exister des core ARM pour XIlinx à acheter également, et ça m'étonnerait que ce soit donné. Parce que l'on peut, dans certains cas, vouloir utiliser en production des FPGA plutôt que des ASIC, il commence à y en avoir qui sont adaptés à ça.
    Et gagner quelques ? par pièces, ce n'est jamais négligeable.
    
    --
    « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
    - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
  - [^]prix d'IP
    
    Posté par Nicolas Boulay () le 09/01/2002 à 09:00. (lien). Évalué à 3.
    Les licences sont du style 1 Millions de $, le ticket d'entrée plus qq dollars par pièces pour une IP hard. Si tu veux le code source le ticket d'entrée passe à 10 millions.
    - [^]Re: prix d'IP
      
      Posté par Jak () le 09/01/2002 à 09:42. (lien). Évalué à 1.
      Waouh! Je pensais qu'Alain avait un peu raison sur le prix de la licence ARM, mais je n'imaginais pas qu'en fait, c'était aussi cher. Arf...
      
      --
      « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
      - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
    - [^]Re: prix d'IP
      
      Posté par Raynaud Alain () le 09/01/2002 à 18:37. (lien). Évalué à 1.
      Je ne sais pas d'ou tu sors ces prix, mais ca ne correspond pas a la realite du tout!
      
      Un bon processeur RISC, ca se trouve a moins de $200,000. ARM, MIPS/Lexra, Arc Cores... Donc toujours bien moins que les masques ($500,000), et en plus tu peux amortir ta license sur plusieurs projets (je n'irais pas jusqu'a dire qu'il a 1 chip sur 10 qui reussit a se vendre, mais si c'etait le cas, tu aurais donc 5 millions de couts de masques, toujours pour $200,000 de licenses).
      
      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).
      
      Alain.
      - [^]====> Moment je pète un plomb <====
        
        Posté par Guidon Yann (page perso, ) le 10/01/2002 à 18:50. (lien). Évalué à 1.
        Salut,
        
        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: article

Posté par gilles renault (page perso, ) le 08/01/2002 à 13:39. (lien). Évalué à 3.
Il n'existe pas des "cpu" reprogrammables? J'ai vu Xilinx de cité, ne fabrique t'ils pas ce genre de composants? Et si ces composant existaient, on pourrait donc avoir un cpu que l'on upgrade presque comme un bios non?

--
Vous venez de mourir pour la troisième fois. Perte d'adhérence aggravée par des pneus trop étroits.
- [^]Re: article
  
  Posté par LeMagicien Garcimore () le 08/01/2002 à 14:19. (lien). Évalué à 1.
  Le probleme c'est que les Xilinx (et ses amis les PGA) ont un nombre très limité de portes logiques(quelques centaines de milliers je crois). On est bien loin des besoins d'un processeur.
  De plus, niveau vitesse, c'est pas le pied :)
- [^]Re: article
  
  Posté par Nicolas Boulay () le 08/01/2002 à 14:26. (lien). Évalué à 4.
  Si cela s'appelle des FPGA. Il s'agit d'une matrice de portes programmables. Le problème concernent les performances. Tu obtiendra jamais plus de 50 Mhz avec de tel machin de plus les plus grosse matrice coute jusqu'à 2000 euro.
- [^]Re: article
  
  Posté par William Steve Applegate (page perso, ) le 08/01/2002 à 14:35. (lien). Évalué à 2.
  Ça me fait penser à la fameuse technique de « Code Morphing » de Transmeta. C'est vrai qu'avoir un CPU qui pourrait faire tourner n'importe quoi, ça a de quoi séduire, mais un tel système n'aurait-il pas un impact très négatif sur les performances ? Après tout, il va bien falloir que le processeur interprète le code qu'il exécute, ce qui va prendre des cycles (notamment s'il lui faut émuler des fonctions complexes style MMX, SSE, etc.). Donc ch'uis pas très convaincu. Mais bon, j'aimerais bien avoir un avis autorisé aussi...
  
  --
  Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™
- [^]Re: article
  
  Posté par Jak () le 08/01/2002 à 14:51. (lien). Évalué à 3.
  Ce ne sont pas des "CPU" reprogrammables, mais des circuits programmables auxquels on peut faire faire ce qu'on veut. d'ailleurs, si je me souviens bien, une des premières étapes du projet F-CPU est de faire tourner le code sur ce genre de composant.
  Le problème, comme cité plus haut, c'est le coût et les performances du truc. Ça sert à tester un prototype, moins souvent à la production (encore qu'il y en a qui sont faits pour ça, voir les Spartan par exemple).
  Là, un Xilinx ne servirait qu'aux prototypes. Et c'est pas sûr que ce serait bien utile. En plus, les logiciels pour le programmer sont assez chers, le bas de gamme étant Fondation qui ne tourne que sous Windows ou HP-UX (à moins que ce soit Solaris au lieu de HP-UX... je sais plus).
  
  C'est un autre problème du projet : les outils de développement libres ne sont pas aboutis pour le moment, il faut qu'ils utilisent ce qu'ils ont à disposition (en École ou en université, ça doit se trouver), mais ce n'est pas toujours évident.
  (Même en étant malhonnête par nécessité, on ne trouve pas de version pirate :) , donc c'est sans objet. Encore que si on utilise leur logiciel (je parle de Fondation), c'est qu'on va leur acheter des composants => c'est même limite défendable).
  
  --
  « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
  - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
  - [^]Re: article
    
    Posté par Guidon Yann (page perso, ) le 08/01/2002 à 15:29. (lien). Évalué à 1.
    (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: article
      
      Posté par Jak () le 08/01/2002 à 16:24. (lien). Évalué à 1.
      Comme tu le dis, à quoi ça servirait si en plus il faut payer le Spartan ?
      Ben, ce que je veux dire, c'est qu'ils pourraient filer ça gratos plutôt que de le faire payer, puisqu'en sortie on ne peut cibler que leurs produits.
      
      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.
      
      --
      « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
      - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
      - [^]Re: article
        
        Posté par Guidon Yann (page perso, ) le 08/01/2002 à 16:56. (lien). Évalué à 2.
        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.
        
        Bienvenue dans le monde libre.
        
        YG (tiens je suis maintenant à 19 XP ???)
        
        [^]Re: article
        
        Posté par Jak () le 08/01/2002 à 17:06. (lien). Évalué à 2.
        Pour ce qui est des générateurs, on ne peut même pas les utiliser
        À l'époque, je crois même que c'était écrit qu'on ne pouvait travailler qu'en comportemental, donc la synthèse, c'était si on avait de la chance :)
        
        YG (tiens je suis maintenant à 19 XP ???)
        20 même :) <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>
        
        --
        « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
        - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
        
        [+] [^]Re: article
        
        Posté par Guidon Yann (page perso, ) le 08/01/2002 à 17:26. (lien). Évalué à -2.
        <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 ? :-)))
        
        [+] [^]debut de troll ?
        
        Posté par kadreg () le 08/01/2002 à 17:38. (lien). Évalué à -2.
        Trop gros, passera pas
        
        [+] [^]Re: debut de troll ?
        
        Posté par Guidon Yann (page perso, ) le 08/01/2002 à 17:52. (lien). Évalué à -2.
        Trop gros, passera pas
        
        moui c'est ça : avec kadreg dans le coin, ça va bientôt faire ====>pika<==== partout...
        
        [+] [^]Re: debut de troll ?
        
        Posté par gle () le 08/01/2002 à 18:09. (lien). Évalué à -1.
        
        Pika !
        
        Rien à foutre des XP, comme disait l'autre !
        
        [+] [^]Re: debut de troll ?
        
        Posté par Antoine Beck () le 08/01/2002 à 18:15. (lien). Évalué à -2.
        !Picon
        
        [^]C koi ce nick
        
        Posté par cedric () le 10/01/2002 à 00:15. (lien). Évalué à 1.
        C'est marrant, j'ai cru que j'etait schizophrene ;-)
  - [^]Re: article
    
    Posté par Ronan BARZIC () le 08/01/2002 à 17:30. (lien). Évalué à 1.
    <em>Là, un Xilinx ne servirait qu'aux prototypes. Et c'est pas sûr que ce serait bien utile<em>
    
    Heu... tu serais surpris du nombre de problemes que l'on voit apparaitre en faisant des protos FPGAs avant de fondre un asic.
    Croire que la simulation suffit, c'est aller droit dans le mur, au vue du prix d'un jeu de masque.
    Et meme si un FPGA ca ne pedale pas rapidement, ca pedale toujours plus vite
    qu'une simu logicielle (booter Linux en simu soft : bonjour - en FPGA, Intel l'a deja fait...)
    
    Ronan
    - [^]Re: article
      
      Posté par Guidon Yann (page perso, ) le 08/01/2002 à 17:41. (lien). Évalué à 1.
      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 :-)
      - [^]Re: article
        
        Posté par Jak () le 09/01/2002 à 08:26. (lien). Évalué à 1.
        Combien de portes? Remarque, c'est possible de cibler une architecture sur plusieurs Xilinx plus petits, j'ai déjà vu l'option dans Fondation, il me semble.
        
        --
        « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
        - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
        
        [^]Re: article
        
        Posté par Guidon Yann (page perso, ) le 09/01/2002 à 10:36. (lien). Évalué à 1.
        Combien de portes?
        
        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: article
      
      Posté par Jak () le 09/01/2002 à 08:16. (lien). Évalué à 1.
      Ben, c'est ce que je dis, non? Les prototypes, c'est bien pour voir apparaître les problèmes.
      Ah, oui, quand je dis que ça ne serait pas bien utile, en fait, je me disais qu'il risque d'y avoir besoin d'un FPGA très gros, avec énormément de portes, ce qui risque de coûter extrtêmement cher, d'où problème.
      Donc cette étape ne sera probablement pas faite directement par les contributeurs dans leur garage.
      
      --
      « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
      - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
  - [^]et en plus il faut des machines surpuissantes...
    
    Posté par koopa () le 09/01/2002 à 13:58. (lien). Évalué à 1.
    La bonne volonté ne suffit pas, il faut aussi des ordinateurs très puissants :
    Même un PC dernier cri (genre P4@2Ghz), gonflé à bloc au niveau de la mémoire (4Go) me semble un peu juste pour simuler/synthétiser une puce aussi complexe qu'un microprocesseur.
    
    .
    
    L'EDA (Electronic Design Automation) est un des domaines d'application qui consomme le plus d'espace mémoire et de CPU. (pour le plus grand bonheur de Sun Microsystem, qui a la majorité de ce marché).
    - [^]Re: et en plus il faut des machines surpuissantes...
      
      Posté par Nicolas Boulay () le 09/01/2002 à 15:58. (lien). Évalué à 2.
      Simu RTl cela devrait aller.
      Simu porte cela se gate un peu mais c'est bon !
      
      synthèse : glurps ! >1Go/Ram juste pour le multiplier : on évitera la compile top-down !
- [^]Re: article
  
  Posté par Raynaud Alain () le 09/01/2002 à 18:29. (lien). Évalué à 1.
  Si. Je t'invite a jeter un oeil a ce que fait notre boite (www.tensilica.com : c'est pas de la pub, aucun d'entre vous n'a les moyens d'etre client!)
  
  Ce n'est pas du RE-programmable. Mais c'est encore mieux!
  
  Au lieu de concevoir un processeur RISC (a la F-CPU), on a ecrit un generateur de processeurs. Tout le processus est automatique: tu decris dans notre propre langage ton processeur ideal, tu cliques sur "Build", et une heure plus tard, tu recois tout ce qu'il faut pour le fabriquer.
  
  L'avantage de cette solution, c'est que pour un algorithme donne, on explose tout le monde en performance. Par exemple, une societe veut faire une camera numerique: ils leur faut un compresseur JPEG. Avant qu'on arrive, tout ce qu'ils pouvaient faire, c'est acheter le plus DSP de chez Texas Instrument, et soufrir a cause de la consommation monstrueuse. Ou alors concevoir une cellule custom pour JPEG, perdre 1 an par rapport a leurs concurrents, et tout mettre a la poubelle le jour ou JPEG2000 est arrive.
  Maintenant, en creant leur processeur "customise" pour JPEG, ils gardent les avantages d'un processeur, c'est souple, on suit facilement les changements de normes, etc... et ils ont essentiellement la performance d'une cellule custom. Conso tres reduite egalement, donc ta camera a une autonomie doublee.
  
  Ca s'applique aussi pour les set-top-box MPEG2, les decodeurs AC-3, les routeurs et autre hub TCP/IP, etc...
  
  Alors oui, le seul cas ou ca marche pas, c'est 10% du marche des processeurs, a savoir les processeurs de bureau (Intel x86, PPC). Quoi que. En tout cas, le concept d'un meta-langage de description de processeurs, c'est autrement plus cool que de se prendre la tete sur un seul processeur!
  
  Et en plus on a le plaisir de travailler dans une startup...

pas clair pas clair du tout; pour l'instant...

Posté par mathic () le 08/01/2002 à 12:19. (lien). Évalué à 1.

C'est vrai que cet article est assez sombre pour la compréhension ...
Pourtant je travaille un peu sur la programmation de µps simples (8051, 68HC11). Donc j'ai une connaissance qui est vraiment de "base" sur le fonctionnement d'un µp, mais là !!!!

C'est trop durt, j'ai travallerais plus en profondeur plus tard !!

Très interessant

Posté par Pascal Terjan (Jabber id, page perso, ) le 08/01/2002 à 13:24. (lien). Évalué à 13.

J'ai fait un stage de 6 mois dans une boite de compilation (je travaillais sur de l'optimisation SIMD automatique) donc j'ai déja une bonne idée de la plupart des trucs dont tu parles dans l'article.

Je l'ai trouvé très interessant car tu parles aussi des technos que vous avez choisi de ne pas utiliser et en expliquant brievement pourquoi.

Par contre, je pense que cet article n'est pas totalement compréhensible par quelqu'un qui n'y connait rien.

Exemples:
- le SIMD
Tu dis ce que c'est Single Instruction Multiple Data et que ca veut dire qu'il y a des fonctions similaires au SSE, SSE2, MMX, 3DNOW et plus loin que ca augmente le CPI.
Tu ne dis à aucun moment ce qu'est une instruction SIMD. par la suite tu dis que le decodage est le meme at qu'il suffit de dupliquer les unités de traitement mais si on ne sait pas ce qu'est le SIMD on ne comprend pas trop.

- le CISC et le RISC
Tu aurais pu expliquer en une phrase la difference.

Je ne vais pas relire tout l'article à la recherche de choses non expliquées bien que je pense qu'il n'y en ait pas tant que ca.
Je pense que quelques petis exemples pour ces points auraient rendu ton article plus accessible sans pour autant l'alourdir.

Pour conclure félicitations pour ton article que je trouve globalement très bien et qui m'a donné envie de suivre le F-CPU de plus près.

[^]Re: Très interessant

Posté par Nicolas Boulay () le 08/01/2002 à 14:33. (lien). Évalué à 0.
Pour le SIMD, j'aurais pu être plus clair.

Concernant RISC et CISC, ... ce que l'on dis actuellement est faux (un cycle par instruction (3 pour la fpu Sparc), nombre d'instruction réduit (+ de 300 parfois), nombre de mode d'adressage réduit).

La seul chose qui soit vrai est la taille fixe des instructions pour simplifier le décodeur.

Concernant la compilation SIMD, si tu pouvais fournir de l'aide au projet Gcc, cela sera toujours utile au Fcpu dans le future.
- [^]Re: Très interessant
  
  Posté par Patrice Karatchentzeff (page perso, ) le 08/01/2002 à 14:57. (lien). Évalué à 4.
  Concernant RISC et CISC, ... ce que l'on dis actuellement est faux (un cycle par instruction (3 pour la fpu Sparc), nombre d'instruction réduit (+ de 300 parfois), nombre de mode d'adressage réduit).
  La seul chose qui soit vrai est la taille fixe des instructions pour simplifier le décodeur.
  
  C'est faux actuellement mais c'est parce que le nom n'a pas change depuis la creation de la bete... A l'origine, c'etait vrai bien sur...
  
  C'est comme dire qu'aujourd'hui le x86 est un CISC... Cela n'a plus beaucoup de sens.
  
  PK
  - [^]Re: Très interessant
    
    Posté par Ronan BARZIC () le 08/01/2002 à 16:53. (lien). Évalué à 6.
    C'est comme dire qu'aujourd'hui le x86 est un CISC... Cela n'a plus beaucoup de sens
    
    Si ! Le x86 est toujours un CISC au sens de son "ISA" (instruction set architecture),
    quand bien meme son architecture interne est "RISC".
    
    On confond le concept du RISC et les caracteristiques techniques des implentations du dit concept
    
    Un RISC, c'est d'abord une architecture Load/Store + un jeu d'instructions simple et orthogonal vis a vis des regitres.
    En clair :
    - il n'y a que des operations arithmetiques/logiques entre registres (la memoire n'est pas utilise)
    - les acces a la memoires ne servent qu'a charger ou stocker des registres
    - pas de registres specialises (du style accumulateur, pointeur de donnee, etc...)
    - des instructions utilisables efficacement par un compilo (le plus important !!!)
    
    Les autres soit-disantes "caracteristiques" d'un RISC (nombre d'instructions, nombre de cycle par instruction, mode d'adressage plus ou moins reduit, complexite du decodage, etc..), ce sont
    les contraintes d'implentation qui les fixent (et le bon sens) .
    
    Avec ces criteres, le x86 est bien un CISC et le restera jusqu'a la fin de sa vie....
    
    Ronan
    - [+] [^]Re: Très interessant
      
      Posté par Guidon Yann (page perso, ) le 08/01/2002 à 18:21. (lien). Évalué à -2.
      Avec ces criteres, le x86 est bien un CISC et le restera jusqu'a la fin de sa vie....
      
      /un CISC/de la merde/
- [^]Re: Très interessant
  
  Posté par Pascal Terjan (Jabber id, page perso, ) le 08/01/2002 à 15:42. (lien). Évalué à 2.
  Concernant la compilation SIMD, si tu pouvais fournir de l'aide au projet Gcc
  J'y ai pensé mais j'ai deja 50 trucs en cours et du temps pour aucun.
  En attendant, si quelqu'un veut s'en occuper, il y a un gars au MIT qui a proposé un algo assez simple : http://www.cag.lcs.mit.edu/slp/SLP-PLDI-2000.pdf(...)
  - [^]Re: Très interessant
    
    Posté par Guidon Yann (page perso, ) le 08/01/2002 à 18:05. (lien). Évalué à 3.
    pas de bol : l'imprimante a plus de toner.
    mais j'ai survolé : ça m'a l'air que du bon !
    merci pour le lien !

Très (trops général)

Posté par Damien Merenne (page perso, ) le 08/01/2002 à 14:16. (lien). Évalué à 8.

Je crois que le problème de cet article est qu'il balaye trops de matière. J'ai passé mon examen d'architecture des ordinateurs le matin ou j'ai acheté linuxmag, donc je n'ai pas eu de problème à le comprendre, mais il y a tellement de chose différente dans l'article...

Une suite de plusieurs article expliquant chacun un point bien précis sur les architectures: les bases, les interruptions, la mémoire virtuelle, les caches, les pipelines,... ca pourrait être très intéressant pour ceux qui n'y connaissent pas grand chose.

Merci quand même pour cet article que j'ai fort apprécié.

PS: il y a un cours d'architecture des ordinateurs disponnible à http://www.montefiore.ulg.ac.be/~pw/cours/struct.html(...)

[^]Re: Très (trops général)

Posté par Nicolas Boulay () le 08/01/2002 à 14:26. (lien). Évalué à 5.
J'ai horreur des suite d'articles lorsque je les lis, je ne vais pas me mettre à en écrire !

Je veux que chaque article se suffise (plus ou moins) à lui-même. C'est difficile mais avec l'exemple que tu prends, j'aurais passer l'année entière avec le même thème !
- [^]Re: Très (trops général)
  
  Posté par Damien Merenne (page perso, ) le 09/01/2002 à 08:57. (lien). Évalué à 1.
  Evidemment, si tu n'aime pas les suites =) Mais alors je crois qu'il ne faut pas vouloir que l'article soit compréhensible par la majorité des gens, car parcourir un panoramique de technologie aussi vaste en un seul article, avec un minimum de fond (je veux dire ne pas se contenter d'écrire des belles phrases avec des beaux mots genre "pipeline"), est impossible...

Bon bon bon

Posté par Vincent MOLLIMARD () le 08/01/2002 à 17:21. (lien). Évalué à 6.

J'utilise linux depuis 1 ans donc ni expert ni complètement nioubi. L'article est ardu pour qui ne connait rien à la fabrication des CI, mais :
- les articles de presse n'ont pas la vocation d'un cours.
- les moteurs de recherche permettent de trouver les liens nécessaires à une explication complémentaire si nécessaire tout comme les références fournies dans le papier de linux mag
- bien que pas électronicien pour deux sous une lecture attentive m'a appris plein de choses.
- si le spécialiste reste sur sa faim, la liste de diffusion du projet lui est ouverte. J'ai d'ailleurs constaté que cela marche en allant y faire une petite visite

Bref j'ai pas tout compris mais à chaque fois que je relis l'article, j'ai l'impression d'être un peu moins c..

Merci Nicolas, c'est que du bon !

[^]Re: Bon bon bon

Posté par Guidon Yann (page perso, ) le 08/01/2002 à 18:03. (lien). Évalué à 7.
et tu connais la meilleure ?

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 :-)

Un bon article

Posté par reno () le 09/01/2002 à 21:02. (lien). Évalué à 1.

Je ne l'ai pas trouvé compliqué au niveau technique mais bon, avoir suivi un cours d'architecture, ça aide :-)

1) Sur le plan technique juste une petite remarque pourquoi avoir utilisé le terme "diélectrique" au début de l'article plutôt que "isolant"?
C'est la même chose, non?

2) Sinon il y a un truc que je n'ai pas bien compris c'est le positionnement du FCPU.
Au début de l'article, tu parles du créneau du maximum de puissance pour un coût minimum.
Et après c'est un CPU 64 bits superpipeliné, incluant le controleur de mémoire, le controleur DMA, le controleur de bus périphérique (le southbridge ?????).

Haute performance peut-être, mais surface de silicium mmmh intéréssante on va dire!
Bon peut-être que le bas cout va venir du fait que le code VHDL sera libre..

3) En plus j'ai un gros doute sur l'interet de mettre le southbridge dans le CPU: les standards evoluent tellement rapidement..

4) Je suis d'accord avec le débat du dessus qui considere que la bataille d'architecte a été considéré du mauvais point de vue: CISC ou RISC ce sont des differents type de jeux d'instruction (IS: Instruction Set) sous-entendu jeux d'instruction EXTERNE..
Et pour moi:
- le CISC a gagné la bataille pour les PC car le 80x86 a gagné la bataille et que la compatibilité ascendante s'est avérée plus importante que la performance pure.
- le RISC a quasiment gagné tout le reste des autres segments.

5) Il est marqué aussi: chaque instruction peut traiter un nombre unique ou un paquet composé de nombre 8,16,32,64 bits.
Ca veut dire qu'a chaque instructions, il y a 3 bits qui indiquent le type de l'instruction?

Mmm, je crois que je vait regarde sur le web..

[^]Re: Un bon article

Posté par Guidon Yann (page perso, ) le 10/01/2002 à 18:09. (lien). Évalué à 1.
salut !

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: Un bon article
  
  Posté par reno () le 11/01/2002 à 08:01. (lien). Évalué à 2.
  3) Je ne comprends pas trop: la j'ai l'impression que tu parles plutot de l'integration du northbridge dans le CPU (comme dans le futur K8 d'AMD) ce qui est une bonne idee: diminution du temps de latence d'acces a la memoire.
  Mais dans l'article, il etait aussi decrit l'integration du controleur bus peripherique dans le FCPU.
  
  Moi j'interprete ca, comme etant l'integration du southbridge dans le CPU ce qui me parait un peu bizarre..
  Vous voulez vraiment integrer un controleur PCI, USB, Firewire, ISA(:-)) dans le CPU?
  - [^]Re: Un bon article
    
    Posté par Nicolas Boulay () le 14/01/2002 à 12:39. (lien). Évalué à 1.
    Non on ne veut pas intégrer le southbridge mais bien le northbridge. Mais dans ce cas,; il sort bien 2 bus de la puce celui pour la mémoire et celui pour les io : le bus de périphérique (style hypertransport ou autre)
    
    nicO

Revenir en haut de page

Articles précédents : Presse

Liens connexes

Dépêche modérée par

Presse : Article sur le FCPU de LMF

une petite reponse qui vaut ce qu'elle vaut...

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

[+] [^]Re: une petite reponse qui vaut ce qu'elle vaut...

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

[^]Re: une petite reponse qui le vaut bien ...

[^]Lefinnois, pas le Finnois, inculte ;)

[^]Re: une petite reponse qui vaut ce qu'elle vaut...

[+] RAV

article plus général

[^]Re: article plus général

[^]Re: article plus général

[^]Re: article plus général

[^]Re: article plus général

[^]Re: article plus général

[^]Re: article plus général

[^]Re: article plus général

[+] [^]Re: article plus général

[^][HS] Or tau Graff

[^]"Hack en C" ? et +

[^]franchement...

[^]dégonflage de chevilles

[^]vi

[+] [^]Re: vi

[^]Re: article plus général

[^]Re: article plus général

[^]Re: article plus général

[^]Re: article plus général

[^]un projet sous le coude

[^]Re: un projet sous le coude

article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]prix d'IP

[^]Re: prix d'IP

[^]Re: prix d'IP

[^]====> Moment je pète un plomb <====

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[+] [^]Re: article

[+] [^]debut de troll ?

[+] [^]Re: debut de troll ?

[+] [^]Re: debut de troll ?

[+] [^]Re: debut de troll ?

[^]C koi ce nick

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]Re: article

[^]et en plus il faut des machines surpuissantes...

[^]Re: et en plus il faut des machines surpuissantes...

[^]Re: article

pas clair pas clair du tout; pour l'instant...

Très interessant

[^]Re: Très interessant

[^]Re: Très interessant

[^]Re: Très interessant

[+] [^]Re: Très interessant

[^]Re: Très interessant

[^]Re: Très interessant

[^]**====> Moment je pète un plomb <====**