electronews et meilleurs liens électroniques - Page 146

Hmmm

Tu l'as déjà dit dans un autre topic

HMMMMMMMMMMMMM

j'ai lu en diagonal mais pas compris la nouveauté ?
Le C2H existe depuis longtemps chez altera, et altium le faisait aussi.

Je sais pas trop non plus. Le concept n'est pas nouveau c'est sûr, ça fait longtemps qu'il existe SystemC pour que les boîtes puissent embaucher des développeurs info pour faire du FPGA (avec les résultats qu'on peut imaginer).

Je pense que c’est moins lourdingue, et ça semble venir avec pas mal de librairie + le fait que c’est intégré dans leur outils.

Ce n’est pas un compilateur C vers VHDL/Verilog

Un peu plus sur Vitis:



et

Tiens, Flan pourrait se mettre au FPGA ?

Les compilateurs C vers V(HDL), ça a un intérêt dans quel domaine ? Quelqu'un s'en sert au boulot ?
Au boulot ici, on on utilise un mélange de Verilog et VHDL pour faire du traitement d'image à un débit de données relativement élevé (plusieurs centaines de millions de pixels par seconde), et je suis curieux de savoir dans quel ordre de grandeur les perfs seraient affectées.

Ça dépend du développeur. Si c'est quelqu'un qui maîtrise déjà la parallélisation massive (par exemple en maîtrisant CUDA) et qui utilise intelligemment les ressources hardware, j'imagine qu'il doit pouvoir obtenir un truc pas trop dégueu. S'il a l'habitude de coder comme en JS par contre, c'est même pas la peine

En pratique je suppose que ça sert surtout pour faire des protos, ou pour les parties non critiques. Logiquement quand on utilise un FPGA c'est qu'on a besoin de perfs qui ne sont pas atteignables avec un CPU ordinaire, donc ce serait idiot de les gaspiller avec un langage sous-optimal juste pour faire l'économie d'un dév qui fait du HDL.

Rien à voir : restauration d'une panne de fer par ponçage et placage de nickel :

Bon, ça ne vaut le coup que pour une panne coûteuse ou qui n'est plus fabriquée, parce que sinon...

Zerosquare (./4360) :
Ça dépend du développeur. Si c'est quelqu'un qui maîtrise déjà la parallélisation massive (par exemple en maîtrisant CUDA) et qui utilise intelligemment les ressources hardware, j'imagine qu'il doit pouvoir obtenir un truc pas trop dégueu. S'il a l'habitude de coder comme en JS par contre, c'est même pas la peine

En pratique je suppose que ça sert surtout pour faire des protos, ou pour les parties non critiques. Logiquement quand on utilise un FPGA c'est qu'on a besoin de perfs qui ne sont pas atteignables avec un CPU ordinaire, donc ce serait idiot de les gaspiller avec un langage sous-optimal juste pour faire l'économie d'un dév qui fait du HDL.

Merci pour les infos ! Notre savoir-faire en traitement d'images informatique est un no man's land, donc c'est poubelle direct (c) vu que les projets doivent toujours être bouclés pour l'avant-veille.

Au départ, je croyais que ce genre de compilateur était capable de paralleliser des grosse boucles for dégueulasse Mais ça semble comme tout le reste = il faut un bon savoir-faire pour s'en servir de manière efficace.

Ouais, faut surtout pas prendre le HDL comme un langage de programmation. Faire ca, c'est aller dans le mur a Mach2.

Le HDL est une manière de décrire des CIRCUITS. C'est une description de schémas, de machines a états et de connexions.
Tant qu'on a pas pigé ca, c'est pas la peine de faire du HDL.

par ex, une instruction switch n'est pas une suite de tests logiques. c'est un multiplexeur indexé par le résultat de comparaisons. Chaque branche doit affecter chaque variable une et une seule fois, sinon tu décris des court-circuits ou des machins totalement impossibles.

Du coup ca ne décrit pas des algorithmes séquentiels, mais des actions simultanées dans des circuits.

Perso, j'ai encore beaucoup du mal à tout saisir. En particulier sur les listes de sensibilité, mais je crois que c'est un détail.

Il me semble que c'est surtout tres VHDLesque, je n'ai pas souvenir que Verilog ai ce concept

si, pareil

Pour ceux qui ont le (mauvais) goût de faire du PIC, Farnell fait une promo sur ça en ce moment :
https://fr.farnell.com/microchip/pg164100/snap-in-ckt-debugger-mcu/dp/2915518

The MPLAB® Snap In-Circuit Debugger (PG164100) is an ultra-low priced debugging solution for projects not requiring high-voltage programming or advanced debug features. Therefore, it supports many of Microchip’s newer MCU offerings but not some legacy products. With a nominal feature set, the debugger is geared toward developers who don’t require advanced features. It is not intended for production programming.

Works with many Microchip PIC, dsPIC, AVR, or DSC devices, including 32-bit microcontrollers such as SAM, CEC and PIC32 devices

Ça fait pas tout, mais c'est beaucoup moins cher que les PicKit et les ICD, et ça gère aussi certains AVR apparemment.

Sinon, si vous êtes d'humeur Brunniesque, un mini arc-en-ciel à LEDs RGB pas trop cher :
https://fr.farnell.com/kitronik/35134/carte-arc-led-moyen-carte-bbc/dp/3021739

Merci, mais j'ai définitivement divorcé avec les PIC

Bien

Je ne programme qu’en PIC mais pas avec l’APIC parce que l’ASLR ça fait faire Poopoo on the Edge

vince (./4369) :

How can someone be that lazy!9GAGMore memes, funny videos and pics on 9GAG

Non mais en fait c'est juste que la photo a été prise au mauvais moment. Le monsieur allait justement ajouter l'étain en s'aidant de cette 3ème main en plastique

reminded of the USB Power Delivery version 1, whose specification includes this figure. you can take a guess at why you've never seen a single device with USB Power Delivery version 1 pic.twitter.com/spSRtKovZi

— whitequark (@whitequark) November 13, 2019

Je le savais. Les membres du comité USB sont des grands malades.

Tiens, Twitter est down ?

Ici ça marche.

Bon ça remarchera peut-être plus tard

Ou alors, ils ont décidé de bloquer Twitter sur Renater

C'est pas possible, ça, il y a des community managers dans certaines univs et même dans certains labos de recherche

(Je dois avoir un cookie pourri dans un coin, ça fonctionne en navigation privée ^^)

ca a l'air un peu pété par ici...

Merci de l'info.