Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 279 sur 334 PremièrePremière ... 179229269271272273274275276277278279280281282283284285286287289329 ... DernièreDernière
Affichage des résultats 8 341 à 8 370 sur 10008
  1. #8341
    Une après-midi passée à tenter de débugger l'initialisation au moment de l'élaboration d'un bloc de mémoire sur FPGA à partir d'un fichier, avant de me rendre compte que l'outil de synthé d'Altera ignore silencieusement tout ce qui a trait aux fichiers et remplace les données lues par des zéros. Puis tout content il m'annonce qu'il a optimisé le circuit en 3 portes logiques vu que ma mémoire renvoie tout le temps zéro.


    Donc je vire ma belle initialisation en VHDL portable, pour mettre à la place des attributs propriétaires, j'écris un script awk pour recoder tous mes fichiers dans le format à la con d'Altera, et... là le synthé me dit : eh, tu vas être fier de moi, j'ai vu que tu n'écris jamais dans ta mémoire, alors j'ai dégagé le code mort.

    En ajoutant des signaux d'écriture bidon venant de l'extérieur, ça le fait, il prend enfin en compte mon initialisation : cool, il n'y a plus qu'à router ces signaux sur quelques pins d'entrée soudés à la masse et ça sera bon.

    Et ces gusses ont été rachetés par Intel.

  2. #8342

  3. #8343
    Pareil. j'ai juste retenu que si un jour je dois bosser avec un truc pondu par Altera, je flingue le commercial. Peu de chances que ça arrive, cela dit.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  4. #8344
    Non mais c'est pareil chez la marque X, hein (mais avec des bugs différents sinon c'est pas drôle).

    Ce qu'il faut retenir, c'est que programmer du hardware c'est fun, on a des beaux langages normalisés avec des features de fou furieux, mais les outils sont dans l'état des compilateurs avant gcc : chaque vendeur a le sien avec un support des normes foireux, des extensions propriétaires dans tous les sens et une compatibilité hasardeuse avec les autres.

    Et la communauté est riquiqui, même StackOverflow a peu de questions et des réponses à côté de la plaque, et 90% des exemples de code que tu trouves c'est de la merde.

  5. #8345
    C'est l'impression que j'en avais eu. Ca donne trop envie.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution."

  6. #8346
    Grave, on n'est pas mécontent de faire du C/Java/C#/Perl/Python/Ruby ou que sais-je encore en lisant ça. Avec des normes qui sont à peu près respectées (SQL pourquooooooi?! ).

  7. #8347
    C'est quoi déjà la norme ISO pour Python ?

    En software, il n'y a qu'un seul langage qui a vraiment bien marché, c'est C. Après, tout le reste a été construit par dessus. Python est portable parce que le code C de l'interpréteur Python est portable.
    En hardware, le problème est surtout au niveau de Verilog/VHDL. Et il ne se réglera pas juste en empilant des couches de langages par dessus.

  8. #8348
    Citation Envoyé par Møgluglu Voir le message
    c'est C
    T'as oublié le JavaScript.

    Bientôt il y aura plus de langages qui compilent vers JavaScript que de langages compatibles avec le C.
    Rust fanboy

  9. #8349
    Citation Envoyé par Møgluglu Voir le message
    C'est quoi déjà la norme ISO pour Python ?

    En software, il n'y a qu'un seul langage qui a vraiment bien marché, c'est C. Après, tout le reste a été construit par dessus. Python est portable parce que le code C de l'interpréteur Python est portable.
    Y en a pas en effet mais y a des guidelines https://docs.python.org/2/reference/ , si tu t'en écarte c'est plus du python donc ça garantit quand même une uniformité au sein des différentes implémentations de python.

    A l'inverse SQL a une norme ISO mais tous les developpeurs de SGBD(R) rajoutent leurs petits mots clefs et leur façon de faire tel ou tel truc, une norme ISO ne garantit pas grand chose, au fond...

    Mais je sais que c'était juste pour le plaisir de taper sur python .

  10. #8350
    Citation Envoyé par Møgluglu Voir le message
    En hardware, le problème est surtout au niveau de Verilog/VHDL. Et il ne se réglera pas juste en empilant des couches de langages par dessus.
    Ça me rappelle ma jeunesse... dans une vie très lointaine... j écrivais un compilateur qui générait du Verilog et du VHDL... sans avoir l expérience des outils qui étaient censés bouffer ces langages... évidement le résultat n’était pas fameux...

  11. #8351
    Un bel aperçu du monde de l'EDA, et ses outils sclérosés des années 70 "Il y a tellement d'argent à perdre à changer un truc qu'on touche à rien". Quelques billets d'humeur intéressants. Bon d'un autre côté il "vend" son logiciel de PCB : c'est comme du LateX mais pour générer du svg puis du gerber, c'est original... (Enfin, à mon avis c'est rigolo sur des petits projets, mais avec un truc en 22 couches remplies de fpga à 500 pinoches, tu dois vite aimer retrouver un vrai soft).

    Et un logiciel de Verilog vers bitstream open source pour le Lattice ice40, ca existe !
    http://www.clifford.at/papers/2015/icestorm-flow/

  12. #8352
    Citation Envoyé par Møgluglu Voir le message
    En hardware, le problème est surtout au niveau de Verilog/VHDL. Et il ne se réglera pas juste en empilant des couches de langages par dessus.

    Come to the Dark Side!

  13. #8353
    Citation Envoyé par weedkiller Voir le message
    Et un logiciel de Verilog vers bitstream open source pour le Lattice ice40, ca existe !
    http://www.clifford.at/papers/2015/icestorm-flow/
    Sympa. Bon, le FPGA le plus gros que ça supporte équivaut grosso modo au plus petit de la gamme Xilinx ou Altera d'il y a 10 ans, mais pour une fois qu'il y a des docs...

    Citation Envoyé par Naity Voir le message
    Construire des circuits en connectant des boîtes avec des fils. Cette révolution.

  14. #8354
    Citation Envoyé par Møgluglu Voir le message
    Sympa. Bon, le FPGA le plus gros que ça supporte équivaut grosso modo au plus petit de la gamme Xilinx ou Altera d'il y a 10 ans, mais pour une fois qu'il y a des docs...

    Construire des circuits en connectant des boîtes avec des fils. Cette révolution.
    Même qu'un homme seul peut produire suffisemment de code pour remplir à raz-bord une Virtex-6 en une seule journée de travail. Suffit juste d'optimiser avec les pieds

  15. #8355
    Citation Envoyé par Møgluglu Voir le message
    Une après-midi passée à tenter de débugger l'initialisation au moment de l'élaboration d'un bloc de mémoire sur FPGA à partir d'un fichier, avant de me rendre compte que l'outil de synthé d'Altera ignore silencieusement tout ce qui a trait aux fichiers et remplace les données lues par des zéros. Puis tout content il m'annonce qu'il a optimisé le circuit en 3 portes logiques vu que ma mémoire renvoie tout le temps zéro.


    Donc je vire ma belle initialisation en VHDL portable, pour mettre à la place des attributs propriétaires, j'écris un script awk pour recoder tous mes fichiers dans le format à la con d'Altera, et... là le synthé me dit : eh, tu vas être fier de moi, j'ai vu que tu n'écris jamais dans ta mémoire, alors j'ai dégagé le code mort.

    En ajoutant des signaux d'écriture bidon venant de l'extérieur, ça le fait, il prend enfin en compte mon initialisation : cool, il n'y a plus qu'à router ces signaux sur quelques pins d'entrée soudés à la masse et ça sera bon.

    Et ces gusses ont été rachetés par Intel.
    Tu entends quoi par " l'élaboration d'un bloc de mémoire sur FPGA à partir d'un fichier" . Le classique d'utilisation "public" des FPGA (hors ce qu'on fait en labo de recherche) c'est pas de pondre les portes une fois pour toute pour l’application en cours et ne pas faire de re-adaptation en cours d'appli ?
    En fait je comprends pas à quelle fichier tu peut faire reference dans ton VHDL... en théorie il ne doit être que l'expression de ce que seront tes portes et ne faire appels qu'a la mémoire du coups ça me parait, heu, cohérent que la première fois il te remplace le fichier par rien du tout et que la seconde il te dit que vu que tu ne touche pas à la mémoire ben il optimise ...

    Je doit me gourer quelque part, du coups je demande ^^
    Dernière modification par Nilsou ; 29/01/2016 à 01h09.

  16. #8356
    Citation Envoyé par Nilsou Voir le message
    Tu entends quoi par " l'élaboration d'un bloc de mémoire sur FPGA à partir d'un fichier" . Le classique d'utilisation "public" des FPGA (hors ce qu'on fait en labo de recherche) c'est pas de pondre les portes une fois pour toute pour l’application en cours et ne pas faire de re-adaptation en cours d'appli ?
    En fait je comprends pas à quelle fichier tu peut faire reference dans ton VHDL... en théorie il ne doit être que l'expression de ce que seront tes portes et ne faire appels qu'a la mémoire du coups ça me parait, heu, cohérent que la première fois il te remplace le fichier par rien du tout et que la seconde il te dit que vu que tu ne touche pas à la mémoire ben il optimise ...

    Je doit me gourer quelque part, du coups je demande ^^
    Par "au moment de l'élaboration", je parle de la première étape de synthèse qui correspond à la compilation pour le software. J'essayais de faire de la méta-programmation pour que le code qui lit le fichier soit exécuté par l'outil de synthé au moment de l'élaboration. Le fichier d'initialisation est dans le répertoire des sources de l'hôte.
    Code:
    architecture structural of My_Memory is
    	constant rambits : natural := 8;
    	type ram is array(0 to 2**rambits - 1) of instruction_word;
    
    	impure function Read_File(fname : string) return ram is
    		file fh       : text open read_mode is fname;
    		variable ln   : line;
    		variable addr : natural := 0;
    		variable word : instruction_word;
    		variable output : ram;
    	begin
    		report "Opened file " & fname;
    		while addr < 2**rambits loop
    			if endfile(fh) then
    				report "Unexpected EOF!";
    				exit;
    			end if;
    			readline(fh, ln);
    			report "line(" & integer'image(addr) & ")= " & ln.all;
    			hread(ln, word);
    			output(addr) := word;
    			addr := addr + 1;
    		end loop;
    		return output;
    	end function;
    
    	-- Qu'une fonction impure abreuve mes signaux !
    	signal imem : ram := Read_File("my_mem.hex");
    	signal address : natural range 0 to 2**rambits - 1 := 0;
    begin
    	process(clock)
    	begin
    		if rising_edge(clock) then
    			address <= to_integer(input_address);
    		end if;
    	end process;
    	data <= imem(address);
    end architecture;
    Transposé dans un langage pour software genre C++, ça reviendrait à initialiser un tableau statique constexpr avec une fonction constexpr qui lit un fichier. On est d'accord que ça n'a aucune chance de marcher, le compilo m'enverrait chier à juste titre. Surtout qu'en VHDL la fonction est explicitement marquée "impure" vu qu'elle a des effets de bord sur le système de fichier hôte.

    Ce qui me tue, ce n'est pas que ça ne marche pas (encore que les outils Xilinx vont lire le fichier sans broncher), c'est que je n'ai même pas un putain de warning dans la console pour me dire que peut-être que remplacer les données lues par des zéros ça pourrait changer légèrement le comportement de mon circuit...

  17. #8357
    Y'a des cours de FPGA à mon IUT, mais j'ai jamais eu l'occasion d'y toucher.
    Quelques doctorants amenés à en faire, visiblement atteints de syndrome post-traumatique, et pas franchement à l'aise avec, et pas tellement de recul dessus on dirait.

    D'après ce que j'en ai compris, c'est bien pour faire de l'embarqué sur un petit circuit portable qui consomme modérément, mais niveau performances c'est vraiment si bon que ça sur des applis scientifiques (FFT, accès à grosses mémoires, tout ça)? Visiblement, chez nous, c'est pas orienté perfs du tout, mais plutôt embarquement dans de petits appareillages.
    Dernière modification par vectra ; 30/01/2016 à 23h58.

  18. #8358
    La simplicité pour faire une FSM en rust
    Citation Envoyé par Snakeshit Voir le message
    Mais comme on me l'a appris dans la Marine, plus les choses sont automatisées, moins ça consomme de cases plus vous en avez de libre pour choses utiles, comme penser à des filles dénudées .

  19. #8359
    Citation Envoyé par vectra Voir le message
    mais niveau performances c'est vraiment si bon que ça sur des applis scientifiques (FFT, accès à grosses mémoires, tout ça)? Visiblement, chez nous, c'est pas orienté perfs du tout, mais plutôt embarquement dans de petits appareillages.
    Oui, meme si ca arrive pas forcemment au niveau d'un circuit analogique. Ca depend de ta puce et de la complexite de ton calcul, et si par "grosses donnees" tu entends 2Gb, tu peux probablement oublier. Mais ca trouve son application meme en RF (un copain a implemente "pour le fun" un decodeur DVB-T sur une puce FPGA). Vu que ce que tu te "contente" de router des transistors entre eux, ta vitesse de calcul est theoriquement proportionnelle a la vitesse de propagation de ton signal electrique dans ta puce et non a la vitesse de calcul de ton processeur (aka plus rapide). Dans les faits c'est un peu plus complique, mais ca reste tres rapide car ta puce FPGA n'est decrite que pour pouvoir donner une operation mathematique donnee quand ton processeur est sense tout pouvoir realiser en plus de gerer ton OS et tes peripheriques.

  20. #8360
    Citation Envoyé par vectra Voir le message
    D'après ce que j'en ai compris, c'est bien pour faire de l'embarqué sur un petit circuit portable qui consomme modérément, mais niveau performances c'est vraiment si bon que ça sur des applis scientifiques (FFT, accès à grosses mémoires, tout ça)? Visiblement, chez nous, c'est pas orienté perfs du tout, mais plutôt embarquement dans de petits appareillages.
    Déjà, les gammes de FPGA sont très larges. Tout comme les CPU qui vont du micro-contrôleur AVR au Power 8 d'ailleurs, sauf que côté FPGA tu trouveras ces extrêmes chez le même constructeur voire dans la même gamme. C'est parce que la segmentation de marché se fait sur la surface de silicium, qui peut aller facile de 4mm² à 400mm², plutôt que sur la fréquence.
    Par exemple chez Altera tu as la gamme Celeron Cyclone V qui va de 25K à 301K éléments logiques, puis la gamme Core i Arria 10 de 160K à 1100K, et la gamme Xeon Stratix 10 de 484K à 5510K LE. Avec des features en plus quand tu montes en gamme, comme des blocs de calcul en hard et des I/O qui poutrent.
    (Le LE est en gros une table de vérité à 6 entrées avec plein de filasse autour. Le Lattice cité au-dessus doit être équivalent à 5 ou 6K LE Altera. )
    Bien entendu les prix varient en fonction, entre 10$ et 10K$.

    Donc les petits FPGA sont effectivement utiles en embarqué là où un microcontrôleur ne suffit pas : quand tu as besoin de connecter un truc à un machin qui causent des protocoles de bus différents ou quand tu veux acquérir et pré-filtrer des données, et ça à une fréquence mégahertzique ou centomégahertzique.

    Les gros FPGA, ils servent surtout pour le prototypage, pour tester ton chip avant de l'envoyer à la fab, voire pour vendre un appareil fonctionnel à perte à tes premiers clients en attendant que le vrai chip revienne de la fab.
    Tu peux faire du calcul bourrin avec aussi, quand ton calcul est à base d'opérations mal gérées sur CPU et GPU. Donc pas du calcul flottant de base avec du gros débit mémoire, déjà. Plutôt de la crypto, ou des opérations arithmétiques compliquées en virgule fixe.
    Cela dit, les dernières générations de FPGA chers ont des blocs d'arithmétique flottante en hard, ce qui permet de tirer jusqu'à 9 Tflops simple précision sur un chip. Mais si on compte le prix et le temps de développement ça se fera laminer par une paire de Titan X.

  21. #8361
    Et d'un seul coup
    Le x86 intervient
    Et personne ne bitta rien
    Était-il fou ?
    ♬♫

  22. #8362
    Ben au contraire, il a répondu très précisément à ma question.
    Here come the Men in Black ♬♫


    Ouais effectivement, de mon côté, c'est plutôt les débits mémoire qui coincent, et le gros des opérations est en virgule flottante sur 1Go mini, 4 en pratique.
    Donc de ce côté-là, pas de miracles...

    Une des questions que je me posais, en marge de mes calculs habituels, c'était quoi attendre comme performances pour une FFT 2D pour 1Mo en float 32 bits.
    A défaut de concurrencer le GPU sur le calcul principal, du pré-filtrage de données acquises nous permettrait d'économiser de la bande-passante en amont, au niveau de l'acquisition.
    Dernière modification par vectra ; 31/01/2016 à 16h38.

  23. #8363
    hijopr: je te rassure, j'en profite juste parce que j'arrive à suivre la discussion. Quand ça cause PHP ou pire genre design patterns, je panne rien non plus.

    Citation Envoyé par vectra Voir le message
    Une des questions que je me posais, en marge de mes calculs habituels, c'était quoi attendre comme performances pour une FFT 2D pour 1Mo en float 32 bits.
    A défaut de concurrencer le GPU sur le calcul principal, du pré-filtrage de données acquises nous permettrait d'économiser de la bande-passante en amont, au niveau de l'acquisition.
    Telle que la question est posée, c'est mal parti : ça revient en gros à demander si l'algo que tu as pensé et optimisé pour CPU tournera plus vite si tu le portes tel-quel sur FPGA.
    Si c'est pour réimplémenter en soft à 150 MHz les mêmes unités flottantes IEEE-754 que le CPU/GPU a en hard à 2 ou 3 GHz, c'est pas la peine.

    Mais si tu acceptes de faire ta FFT en virgule fixe, ça peut le faire. Pour faire tenir 1Mo en mémoire on-chip, il te faudra au moins du milieu de gamme. Par exemple toujours chez la marque A, le plus gros Cyclone V a 12Mbits de mémoire et 680 multiplieurs 18x18 (à ~200MHz) que dans la pub ils disent que c'est vachement bien pour les FFT. Mais la marque X a sûrement des trucs équivalents.

  24. #8364
    Citation Envoyé par Møgluglu Voir le message
    Par exemple toujours chez la marque I,
    Fixed . Ils finiront bien par mettre des fpga avec des xeons, non ? A 100k$ l'unité d'accord, et 2000 pin à router sur le pcb . Il y a bien des Cortex A9 @1GHz chez les X. Ou ils ont juste racheté ça pour les patterns de tests de la chaine de prod à 10/7nm ?

  25. #8365
    Citation Envoyé par weedkiller Voir le message
    Fixed . Ils finiront bien par mettre des fpga avec des xeons, non ? A 100k$ l'unité d'accord, et 2000 pin à router sur le pcb . Il y a bien des Cortex A9 @1GHz chez les X. Ou ils ont juste racheté ça pour les patterns de tests de la chaine de prod à 10/7nm ?
    Surement. Mais Intel va continuer à produire des Cortex A9 et A53 chez TSMC pendant un bon moment. Indice : le tableau avec les lignes Year introduced, Process technology et Recommended for new designs ici : https://www.altera.com/products/fpga...ne-series.html.
    Salut Microsoft, je veux développer une nouvelle appli à partir de zéro, comme techno tu me conseilles quoi ? Visual Studio 2003 sous Windows XP 32-bit ? Nickel.

    Remarque, Intel, ils ont l'habitude. Au pire ils feront des soft FPGA sur FPGA pour emuler les anciens designs. (Même pas de smiliey ninja, ça existe vraiment.)

  26. #8366
    Citation Envoyé par Møgluglu Voir le message
    Surement. Mais Intel va continuer à produire des Cortex A9 et A53 chez TSMC pendant un bon moment. Indice : le tableau avec les lignes Year introduced, Process technology et Recommended for new designs ici : https://www.altera.com/products/fpga...ne-series.html.
    Salut Microsoft, je veux développer une nouvelle appli à partir de zéro, comme techno tu me conseilles quoi ? Visual Studio 2003 sous Windows XP 32-bit ? Nickel.
    Lapin compris. C'est quoi le lézard?

  27. #8367
    Si tu veux commencer un nouveau projet là maintenant tout de suite, Altera Intel te recommande de partir sur un FPGA sorti en 2004 au moins. La durée de vie de ton projet sera minimum de 10 ans, pendant lequel Altera continuera d'assurer la disponibilité du hardware et le support software. Ça nous amène en 2026 pour la fin du support.
    À moins qu'Intel change sa politique en envoyant chier ses clients, les modèles Altera sortis en 2014 juste avant le rachat devront rester au catalogue et être supportés jusqu'en 2035 ou 2040... Et encore, si tu es client en aérospatiale ou militaire tu dois encore pouvoir réclamer une rallonge jusqu'en 2050.

  28. #8368
    Citation Envoyé par vectra Voir le message
    Y'a des cours de FPGA à mon IUT, mais j'ai jamais eu l'occasion d'y toucher.
    Quelques doctorants amenés à en faire, visiblement atteints de syndrome post-traumatique, et pas franchement à l'aise avec, et pas tellement de recul dessus on dirait.

    D'après ce que j'en ai compris, c'est bien pour faire de l'embarqué sur un petit circuit portable qui consomme modérément, mais niveau performances c'est vraiment si bon que ça sur des applis scientifiques (FFT, accès à grosses mémoires, tout ça)? Visiblement, chez nous, c'est pas orienté perfs du tout, mais plutôt embarquement dans de petits appareillages.
    MS se la pète d'avoir doublé certaines perfs des serveurs de Bing depuis qu'ils ont mis des FPGA dedans : http://research.microsoft.com/en-us/projects/catapult/

  29. #8369
    Citation Envoyé par Møgluglu Voir le message
    Et encore, si tu es client en aérospatiale ou militaire tu dois encore pouvoir réclamer une rallonge jusqu'en 2050.
    Ouais, mais si tu es client aérospatial ou militaire, tu le fait écrire noir sur blanc dans ton contract de service et ca n'a pas d'incidence sur le support public. Après, si tu dev des techno militaires en France sur des FPGA Intel, prend garde à pas te prendre un retour d'ITAR dans la tronche.
    Après, ma compréhension limitée me fait supposer que la "génération" n'a que peu d'importance non? A partir du moment ou ta puce est bien dimentionnée, que tu as suffisemment de bascules, de portes logiques, de tables de correspondance, de mémoire et de blocs de foncions mahtématiques pou ton projet, peu importe que la puce soit de 2004 ou de 2014?

    - - - Mise à jour - - -

    Citation Envoyé par Robix66 Voir le message
    MS se la pète d'avoir doublé certaines perfs des serveurs de Bing depuis qu'ils ont mis des FPGA dedans : http://research.microsoft.com/en-us/projects/catapult/
    2*0 = ?

  30. #8370
    Citation Envoyé par Naity Voir le message
    Après, ma compréhension limitée me fait supposer que la "génération" n'a que peu d'importance non? A partir du moment ou ta puce est bien dimentionnée, que tu as suffisemment de bascules, de portes logiques, de tables de correspondance, de mémoire et de blocs de foncions mahtématiques pou ton projet, peu importe que la puce soit de 2004 ou de 2014?
    En théorie oui. De la même façon qu'en software tu t'en fous du CPU sur lequel tu tournes, x86, PowerPC ou ARM, 32 ou 64-bit, tant qu'il a suffisamment de mémoire et de puissance, t'as juste à recompiler ton code, c'est bien connu.

    En pratique, tu as conçu un PCB autour d'un FPGA donné, et tu as perdu tu ne veux pas refaire le design, donc il te faut au minimum un remplacement pin-compatible. Ensuite vu la merde que c'est de faire comprendre du HDL portable aux outils, tu as surement instancié des composants hard des bibliothèques constructeur, genre blocs de mémoire ou générateur d'horloge, qui ne sont pas portables (même en restant dans la même crèmerie). Enfin ton circuit tu l'as testé intensivement pendant la phase de validation et tu es raisonnablement sûr qu'il marche avec le FPGA X, mais c'est tout. La loi de Murphy étant ce qu'elle est, tu serais obligé de re-valider tout si tu mets le FPGA A à la place.

Page 279 sur 334 PremièrePremière ... 179229269271272273274275276277278279280281282283284285286287289329 ... DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •