En matière de liberté le monde du FPGA est resté dans les années 90. Une époque obscure où l’on cachait le mode de fonctionnement des logiciels, où il fallait signer des accords de non divulgation (NDA) avant de pouvoir simplement utiliser un logiciel. Une époque où l’on croyait encore que la sécurité par l’obfuscation était le summum de l’état de l’art pour sécuriser et protéger son logiciel et ses données. Mais il est possible que les nouvelles de sorties de nouveaux logiciels libre de fin d'année 2018 changent la donne.
Un FPGA est littéralement un champs de portes programmable. Le paysan-développeur ensemence son champs avec un fichier nommé «bitstream». Ce bitstream permet de configurer les liens entre les différentes portes logiques du FPGA et constituer ainsi un circuit électronique (numérique).
C’est ce fichier qui n’est documenté par aucun fabricant de FPGA.
Jusqu’à très récemment pour ses semailles, le développeur devait passer par le logiciel fourni par le fabricant pour générer son bitstream. À chaque modèle un logiciel spécifique, avec tous les défauts inhérent aux logiciels fermés :
- Obligé d’utiliser un ordinateur et un système d’exploitation supporté officiellement par le fabricant (impossible de générer le bitstream sur un système embarqué ARM par exemple).
- Grande difficulté à gérer les bugs du logiciels (et les bugs c’est vraiment pas ça qui manque)
- Support aléatoire
- Obligé de payer une licence pour les «gros» FPGA
- Licence Gratuite pour les petits FPGA mais un système de gestion de ladite licence obligeant à être fliqué par le fabricant (serveur de gestion de licence, obligation d’identification, collectes de données personnelles, …).
L’argument principale des fabricants est qu’ils risquent de perdre toutes crédibilités en matière de sécurité auprès des clients militaires notamment. Et qu’ils risquent d’être plus facilement copié par les chinois (Même s’ils y a déjà des copies fabriquées en chine).
Il a pourtant été démontré depuis longtemps qu’il est tout à fait possible de faire le reverse-engineering des bitstream. C’est notamment ce qu’avait fait en 2008 Jean-Baptiste Note et Éric Rannaud avec debit pour les FPGA de Xilinx notamment. Mais c’est surtout ce qu’a fait Wolf Clifford en 2015 avec Icestorm pour servir notamment à son logiciel de synthèse Yosys en utilisant une plate-forme réel : les ice40 de Lattice.
Ce «déverrouillage» des ice40 a permis une véritable révolution dans le domaine du FPGA chez les bidouilleurs. Beaucoup de cartes électroniques utilisant un ice40 on vu le jours, et le projet à fédéré tout un tas de nouveau projet de logiciels libre.
À l’origine, icestorm permettait de faire la synthèse avec yosys (transformer du verilog en netlist), le placement routage avec arachne-pnr (placer les différentes portes dans le FPGA et les relier entre elles) ainsi que la génération du bitstream avec icestorm (icepack).
Un fois le bitstream généré il est nécessaire de vérifier que les temps de propagation entre les différentes portes soient inférieur au cycle d’horloge. Il est donc nécessaire de posséder la spécification des temps de propagation entre les portes dans le FGPA. Chose qui a également été documenté dans le projet Icestorm (icetime).
Le problème qui persistait avec cette chaîne de développement était arachne-pnr qui ne prenait pas en compte les timings du FPGA pour faire son placement routage. C’est ce verrou qui vient de sauter fin 2018 avec la sortie du nouveau logiciel de placement routage nextpnr initié par Clifford mais fédérant une communauté de développeurs de plus en plus grosse.
En plus de faire du placement routage en fonction des temps de propagations, nextpnr possède une interface graphique permettant une visualisation du FPGA une fois le projet routé.
Vue de l'interface graphique de nextpnr.
Tous ces outils sont désormais regroupés dans un projet opensource ayant pour objectif de réaliser un IDE complet pour les FPGA et nommé SymbiFlow.
Le projet SymbiFlow a pour objectif de devenir le «GCC du FPGA et des ASIC». En plus de icestorm, SymbiFlow intègre d’autres projets de «reverse-bitstream», notamment:
- icestorm: déjà longuement décrit dans cet article, permet de faire un développement complet avec des outils opensource.
- X-Ray: Projet de rétro-ingénierie des FPGA de la série 7 de xilinx. Les «tuiles standard» de ces FPGA sont déjà bien documenté et il est possible de générer un bitstream pour des Artix 7.
- Trellis: Projet de rétro-ingénierie des FPGA ECP5 de Lattice. Toute la matrice a été documenté, et il est désormais possible de faire un projet pour ECP5 de bout en bout avec des outils open-source.
- 2064: Projet de rétro-ingénierie des FPGA XC2064 de xilinx. Bon ce projet peut être considéré comme anecdotique puisque il vise à reverser le premier fpga de Xilinx du début des années 80 : le xc2064.
Le projet SymbiFlow est un projet encore «en travaux» mais il permet de tracer une voie et fournir des outils permettant de faire la retro-ingénierie d’autres FPGA. Comme on le voit dans les différents projets intégrés il est possible de voir fleurir d’autre projets de retro-ingénierie de FPGA et voir émerger une solution opensource solide pour développer sur FPGA.
L’année 2018 s’est terminée en fanfare avec la présentation de nextpnr au 35c3. L’année 2019 sera-t-elle celle de la libération des FPGA avec une fédération des projets de rétro-ingénierie de tous les FPGA du Marché ? Un fabricant de FPGA osera-t-il publier la documentation des ses bitstream pour ses FPGA ? Vera-t-on l’émergence de nouveaux acteur du FPGA faisant du libre ?
Vous saurez tous cela en suivant le prochain épisode de l’année 2019 !
# Certes, mais pour quels usages ?
Posté par dinomasque . Évalué à 7.
J'ai vu que les FPGA commencent à être utilisés dans des "émulateurs hardware" multi-machines et c'est très enthousiasmant.
Y a-t-il d'autres usages "grand public" (c'est à dire hors de la sphère des hackers qui veulent concevoir leurs propres processeurs) ?
BeOS le faisait il y a 20 ans !
[^] # Re: Certes, mais pour quels usages ?
Posté par nico4nicolas . Évalué à 3.
Wikipedia a une partie de la réponse.
[^] # Re: Certes, mais pour quels usages ?
Posté par dinomasque . Évalué à 3.
Merci !
J'avais lu la version française qui était peu bavarde sur le sujet sans avoir le réflexe de voir si la version anglophone n'était pas mieux fournie.
BeOS le faisait il y a 20 ans !
[^] # Re: Certes, mais pour quels usages ?
Posté par dib2 . Évalué à 2.
Cela fait très longtemps que les FPGA sont utilisés pour émuler des processeurs.
Il y en a dans la plupart des imprimantes, la plupart des smartphones et la plupart des appareils photo numériques.
[^] # Re: Certes, mais pour quels usages ?
Posté par dinomasque . Évalué à 5.
Enéfé.
J'avais en tête les retro-consoles de jeu qui au lieu d'un émulateur, reproduisent le hardware original avec des FPGA pour une fidélité maximale hors de portée de la puissance de nos ordis actuels en émulation.
BeOS le faisait il y a 20 ans !
[^] # Re: Certes, mais pour quels usages ?
Posté par Guillaume Knispel . Évalué à 10.
Hm c'est pas si simple que ça.
Un CPU high end moderne a une puissance démesurée et est cadencé super rapidement. On peut émuler une SNES quasi-parfaitement là-dessus (et en pratique tous les jeux ayant été édités sur SNES tournent parfaitement), et certes ça consomme un peu toute cette puissance mais en fait le problème principal est plus de reverse le hard d'origine avec un niveau de précision ultra fin et une bonne réimplantation, que la puissance nécessaire au runtime (puisque cette dernière est dispo sur étagère). Cf le projet higan.
De même, la réimplantation dans un FPGA ne va pas se faire d'une manière magique. Ni d'une manière "naïve" ou "triviale" (en copiant le hard d'origine bloc par bloc). Du coup le boulot est tout autant conséquent, et par exemple un projet commercial aura plus tendance à privilégier un peu les hacks (avec par exemple du tuning par jeu pour les plus courant, voire des patchs des ROMs connues) qu'une émulation absolument parfaite.
Et en plus, d'un point de vue conservation, on peut arguer que le résultat n'est pas aussi puissant qu'un émulateur full-soft, vu que le FPGA cible et la board cible va avoir son propre cycle d’obsolescence, alors qu'un soft peut être très largement portable pour son moteur d'émulation et pour les petits bouts d'IO la maintenance est relativement facile (et peut potentiellement n'être nécessaire que rarement).
Et la complexité de la réimplé augmente bien évidemment sur des consoles plus puissantes.
Enfin sur de la 3D on arrête rapidement l'émulation low level pour passer sur une traduction des primitives graphiques vers une API moderne, et là un FPGA n'aidera pas.
[^] # Re: Certes, mais pour quels usages ?
Posté par zurvan . Évalué à 2.
Je ne vois pas de quoi tu parles au niveau des limitations, y'a un paquet de systèmes 8 et 16 bits émulés par FPGA, MiST et Mister sont 2 projets dans ce créneau, avec plus d'une 20taine de systèmes, sans compter les bornes d'arcade en plus :
http://obligement.free.fr/articles/mister.php
Par exemple la Megadrive est réimplémentée quasi parfaitement.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Certes, mais pour quels usages ?
Posté par Guillaume Knispel . Évalué à 5. Dernière modification le 17 janvier 2019 à 19:59.
Je ne dis pas que c'est impossible de faire de très bonne choses avec un FPGA, ni même que ça n'a pas des avantages par rapport à un PC puissant + des émulateurs full-soft précis. Simplement ça n'est pas magique (surtout en ce qui concerne la fidélité), et ça a aussi des inconvénients. Donc à chacun de voir lesquels des avantages il privilégie et qu'est ce qu'il veut en faire. De toutes façons on a atteint un stade où les jeux majeurs, y compris souvent pour des consoles relativement "récentes" (Wii, etc.) tournent suffisamment bien même avec des solutions pas forcement 100% précises. Et on a aussi pas mal d'émulateurs qui utilisent des techniques de haut niveau pour améliorer l'expérience de jeu plutôt que de privilégier la fidélité; et c'est très bien : ça plaît à beaucoup de monde !
[^] # Re: Certes, mais pour quels usages ?
Posté par ariasuni . Évalué à 2.
Il faut aussi savoir que ces avancées sont en partie dues au fait que les consoles modernes ressemblent beaucoup plus à un ordinateur standard qu’auparavant, facilitant leur émulation.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Certes, mais pour quels usages ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 10.
L'utilisation en «émulateurs hardware» est loin d'être la première application des FPGA.
On peut avoir par exemple :
J'ai plus qu'une balle
[^] # Re: Certes, mais pour quels usages ?
Posté par benoar . Évalué à 8.
En gros, c'est souvent pour des traitements spécifique répétitifs et/ou « temps-réel », ou alors pour avoir beaucoup d'I/O (en nombre ou en genre différent). Ce qui en général représente des besoins assez particuliers, pas souvent rencontrés par des amateurs.
Je précise ça pour essayer de faire comprendre pourquoi en général les FPGA ça reste mystérieux : ça n'est pas vraiment utile à la plupart des gens (qui arrivent souvent à tout faire par le CPU), c'est tout.
[^] # Re: Certes, mais pour quels usages ?
Posté par Jimmy . Évalué à 7. Dernière modification le 16 janvier 2019 à 18:35.
De manière générale, on va pouvoir utiliser des FPGA dans toutes les applications où un processeur standard (CPU, DSP, GPU) n'est pas adapté, mais où la fabrication d'un circuit intégré spécifique (ASIC) n'est pas économiquement rentable. C'est le cas de tous les marchés de niche, et ca progresse avec le coût faramineux des circuits intégrés les plus fins.
Le FPGA sera plus cher à l'unité, mais sans investissement initial, donc adapté aux petites et moyennes séries.
C'est une technologie très présente dans le domaine des systèmes embarqués, des infrastructures réseau (routage de paquets), du traitement de signal en temps-réel (audio, radar, télécom, sonar, vidéo …)
Deux exemples récents en audio :
https://fr.antelopeaudio.com/hardware-based-fpga-effects/
https://fr.audiofanzine.com/synthetiseur-hybride-analogique-numerique/novation/peak/editorial/tests/am-stram-gram.html
Ca peut être le processeur principal, ou un co-processeur, ou un élément d'une chaîne de traitement plus vaste. Ou un peu tout ca à la fois quand il y a plusieurs fonctions plus ou moins indépendantes dans le système.
Le prototypage d'ASIC est une application historique, toujours présente, mais bien moins massive que dans l'imaginaire collectif.
Là où ça progresse beaucoup, c'est l'utilisation des FPGA comme co-processeurs dans les gros calculateurs de data-centers, comme accélérateurs d'algorithmes d'"intelligence artificielle". Le rachat d'Altera par Intel il y a quelques années est d'ailleurs un signe fort dans cette direction.
[^] # Re: Certes, mais pour quels usages ?
Posté par benoar . Évalué à 9.
Ah, très bons exemples de la troisième raison (que j'avais oubliée) pour laquelle les FPGA sont souvent mystérieux : c'est utilisé par ceux qui veulent cacher délibérément leur techno encore mieux qu'avec du soft sur CPU. C'est une « obfuscation matérielle », en quelques sortes, et ça marche bien parce que le milieu des FPGA est rempli de personnes qui adorent cacher les choses (modulo ceux qui essayent de libérer ce domaine, comme évoqué dans ce journal).
Dire qu'on a besoin de FPGA pour traiter de l'audio, comme dans ton exemple, c'est du gros bullshit. C'est uniquement pour cacher leurs algos, c'est tout. Ça sert également à avoir un avantage concurrentiel en cachant sa techno, comme par exemple dans un domaine que je connais bien où on fait de la soft-radio en FPGA pour des canaux à quelques kHz sur des communications où on ne demande même pas de la réactivité à la milliseconde (on demande certes de la précision à cette échelle, mais ça se fait très bien avec un microcontrôleur ; cf. les archis « récentes » qui sortent avec des multicœurs ARM « big-little » qui sont fait pour ça, avec de la programmation ouverte sur CPU/uC, des outils ouverts classiques, etc).
Bref, le FPGA c'est mystérieux également parce que ceux qui le commercialisent et l'utilisent aiment bien cacher les choses. C'est bien que certains veuillent botter un peu le cul à ce petit monde.
[^] # Re: Certes, mais pour quels usages ?
Posté par steph1978 . Évalué à 4.
Et j'ajouterai où on veut faire des mises à jour de la logique matérielle directement sur le matériel en service
OVH s'en sert pour faire de la lutte anti-DDOS dans la carte réseau.
IBM s'en sert dans ses baies flash pour implémenter FiberChannel et la gestion des cellules flash.
[^] # Re: Certes, mais pour quels usages ?
Posté par benoar . Évalué à 2.
Puis après, des mecs se sortent un peu les doigts du cul et créent XDP, qui permet de faire la même chose avec un bon vieux CPU : https://blog.cloudflare.com/l4drop-xdp-ebpf-based-ddos-mitigations/
Bref, beaucoup d'utilisation de FPGA sont dues à un manque de connaissance sur les capacités réelles des CPU.
[^] # Re: Certes, mais pour quels usages ?
Posté par steph1978 . Évalué à 2.
Heu, faut voir les bestiaux qu'ils ont…
D'ailleurs je n'ai pas vu sur leur blog qu'ils avaient testé et invalidé la piste FPGA.
[^] # Re: Certes, mais pour quels usages ?
Posté par benoar . Évalué à 2. Dernière modification le 22 janvier 2019 à 12:10.
En fait je ne parlais pas forcément de Cloudflare (et effectivement ce sont de beaux bestiaux), qui n'est pas à l'origine de XDP (mon lien était une référence comme une autre) — OK, c'est Facebook, donc niveau taille on doit être un peu pareil… Cependant, XDP est valable même pour les plus petites machines, et permet je pense de remplacer des FPGA dans bien des cas même plus « petits ».
Enfin bon, de toutes façons le marché de la protection des DDoS c'est du racket de protection, alors peut-être que la mentalité colle bien à celle des fabricants de FPGA…
[^] # Re: Certes, mais pour quels usages ?
Posté par steph1978 . Évalué à 2.
Si par mentalité tu entends pas très ouvert, côté CPU, on a Intel et son management engine, qui se posent là.
Le propos de l'article est que justement l'ouverture s'améliore pour certains FPGA.
Et si on pense à RiscV, pouvoir le simuler sur un FPGA peut améliorer l'adoption.
[^] # Re: Certes, mais pour quels usages ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Ça s'améliore mais c'est pas à l'initiative des constructeurs au contraire !
J'ai plus qu'une balle
[^] # Re: Certes, mais pour quels usages ?
Posté par Jimmy . Évalué à 0.
Il ne s'agit pas d'utiliser le FPGA pour simuler le processeur (techniquement ce serait de l'émulation, mais c'est un détail).
Là l'intérêt c'est aussi d'intégrer le FPGA dans le produit final, pour les cas (de plus en plus nombreux) où un circuit intégré sur mesures n'est pas économiquement faisable.
[^] # Re: Certes, mais pour quels usages ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Économiquement cela a un sens ? un cpu sur FPGA est très très peu efficace par rapport au moindre cpu fondu, non ? Le moindre petit arm fera mieux pour moins chère, j'ai l'impression.
Le seul cas, ou le CPU/FPGA pourrait tout déchirer, cela serait par l'ajout d'instruction ultraspécialisé. Sur un système on-chip (cpu+periphérique), pour ajouter de la puissance à un cpu, on ajoute des accélérateurs. Cela veut dire : drivers linux, support de l'OS pour la gestion du partage de la ressource, et appel système dans les applications. Bref, du gros boulot. Une instruction spécifique, si elle est fait correctement (sans état et sans effet de bord), n'a besoin d'aucun support OS et le partage entre 2 taches se fait naturellement. De plus, il n'y a pas de perte de perf dans la configuration de registres ou autre programmation d'accélérateur qui peut rendre son usage inutile et absurde si la quantité de donnés à traiter est trop faible.
"La première sécurité est la liberté"
# Qu'est-ce qu'un FPGA ?
Posté par MTux . Évalué à 8.
Désolé, j'ai beau lire et relire le journal, consulter la page wikipedia, mais je n'arrive pas à comprendre ce que c'est qu'un FPGA.
[^] # Re: Qu'est-ce qu'un FPGA ?
Posté par flan (site web personnel) . Évalué à 10.
Un processeur normal est constitué de « portes logiques » qui laissent ou non passer le courant en fonction des courants électriques en entrée (à traduire par « ça produit un 0 ou un 1 en fonction des 0 et 1 en entrée). Tu as des portes pour faire un AND, un NOT, un OR, etc. Quand tu en as quelques millions mises bout à bout, ça donne des enchaînements complexes capables de produire des additions, divisions et autres opérations dont sont capables les processeurs modernes.
Ces portes sont gravées dans le silicium et donc non modifiables. Si tu te plantes lors de la gravure de ton processeur, tu mets tout à la poubelle et tu recommences.
Un FPGA est la même chose, sauf que ce n’est pas gravé dans le marbre et que tu peux regraver les portes logiques pour adapter les opérations faisables par le processeur (en contrepartie les opérations sont faites moins vite). Pratique pour faire des prototypes ou des processeurs hyper spécialisés.
[^] # Re: Qu'est-ce qu'un FPGA ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
La version simple d'un FPGA contient des blocs standard, appelé cellule avec des fils d'entré sortie, ces fils sont plus ou moins long, pour les connecté il y a un paquet de "switch" interne programmable par des points mémoires SRAM (le bitstream est copié depuis une mémoire flash, sur ces points mémoires entre autre). Ainsi, on peut faire les connections que l'on veut.
Une cell est composé d'une ou plusieurs "LUT" c'est simplement une petite mémoire, avec 4 fils, et 2 sorties, tu peux réalisé toutes les fonctions logique à 4 entrées et 2 sorties (les bits d'adresses sont tes entrées, et les bits de sorties sont le contenu de l'adresse mémoire). Le bitstream programme le contenu de ces LUT.
Elle peut aussi contenir des portes logiques supplémentaire pour aller plus vite.
Les blocs spécialisé ont aussi fait leur apparition : bloc mémoire (~16ko), multiplication (16x16->32 bits), IO complexe (DRAM, PCIe), puis CPU (arm)…
On peut faire la même chose qu'avec un microcontrôleur mais beaucoup plus rapidement (signal à 200Mhz et plus).
Dans les applications, j'ai vu le compagnon chip d'un processeurs utilisé dans le spatial qui utilisait des protocoles spécialisé ou pas (SPI, spacewire…). J'ai vu des applications radar, quand les DSP ne vont pas assez vite (il existe des FPGA avec plusieurs centaines de bloc multiplieur).
"La première sécurité est la liberté"
[^] # Re: Qu'est-ce qu'un FPGA ?
Posté par Jimmy . Évalué à 9. Dernière modification le 16 janvier 2019 à 19:24.
Techniquement, la configuration des portes logiques et de leurs interconnexions se fait en chargeant un fichier dans une zone mémoire du FPGA (SRAM le plus souvent). Ce fichier est le bitstream évoqué dans l'article.
Les FPGA ont beaucoup évolué depuis une quinzaine d'années.
Initialement, il n'y avait que des portes logiques (réunies sous la forme de logic cells avec une LUT et un registre), plein de fils pour les interconnecter, et plein de pattes d'entrées/sorties logiques. De plus en plus.
Ensuite, on a rajouté des blocs mémoire (de quelques kilo-octets) et des multiplieurs. Et augmenté le nombre de portes.
À ce moment-là (début des années 2000) on a commencé à pouvoir intégrer des composants logiques aussi complexes qu'un petit microprocesseur dans une matrice FPGA.
Ensuite, on a complexifié les multiplieurs, qui deviennent de vrais DSP configurables et chaînables (addition-multiplication-accumulation) de manière à câbler par exemples des filtres numériques. Et augmenté la taille des mémoires.
Ensuite, on a rajouté des périphériques "en dur" : gestion d'horloge (avec des bouts analogiques), contrôleur mémoire DDR, interfaces série hyper-rapides (pour faire par exemple du PCIe ou du SATA ou du SerialRapidIO). Et encore plus de portes logiques.
Ensuite on a rajouté des processeurs "en dur", un peu de PowerPC mais surtout ARM, avec leur cohorte de périphériques voire GPU. Et la capacité de les coupler finement avec la logique configurable, pour faire des coprocesseurs spécialisés.
Et maintenant, on voit apparaître des co-processeurs massivement parallèles, fortement connectés, pour des applications d'apprentissage ou d'IA de manière générale.
Du coup, il n'y a pas que du FPGA dans les FPGA modernes, ce sont des plate-formes de plus en plus hétérogènes, adaptables à plein de besoins.
On n'est vraiment pas dans la même classe de machine. D'ailleurs, la fréquence d'horloge n'est pas le principal facteur : c'est le parallélisme massif du matériel qui donne la puissance de calcul à un FPGA.
Par exemple, tu peux faire travailler un pipeline vidéo à la fréquence pixel (quelques dizaines de MHz en SD, quelques centaines en HD) et faire bien plus de calculs qu'un DSP qui tournerait à plusieurs GHz : les calculs sont étalés physiquement dans la matrice, un peu comme la chaîne d'assemblage d'une usine.
Un autre exemple, les entrées-sorties série très rapides (plusieurs dizaines de Gb/s maintenant) sont fortement dé-sérialisées pour rentrer dans la matrice logique, afin de baisser drastiquement la fréquence et profiter du parallélisme.
L'ordre de grandeur "marketing" des performances maximales des toutes dernières matrices annoncées est en TFLOPS (mille milliards d'opérations flottantes par seconde), centaine de TOPS (calculs entiers), Tb/s (IO et réseau interne).
Un autre aspect intéressant, mais pas très développé, est la capacité à reconfigurer une partie du FPGA pendant qu'il fonctionne. On appelle ca la reconfiguration dynamique partielle, et ca permet par exemple d'adapter les traitements en fonction de l'environnement.
# Mauvaise image
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
"Le paysan-développeur ensemence son champs avec un fichier nommé «bitstream»."
C'est confusionnant au possible.
Par ailleurs, il manque un mot dans "une plate-forme réel". Et il faudra dire en
2 phrases pourquoi c'est bien adapté pour le "temps réel" (le vrai "temps réel",
celui qu'il va falloir renommer un jour).
Supers journaux nonobstant, il faudrait les compiler dans une dépêche ?
[^] # Re: Mauvaise image
Posté par gUI (Mastodon) . Évalué à 2.
je ne vois pas ce que tu veux dire par là.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mauvaise image
Posté par blobmaster . Évalué à 5. Dernière modification le 16 janvier 2019 à 14:29.
Le "temps réel" ne signifiant pas "qui donne l'impression d'être immédiat" (en ressentit humain), l'expression "temps réel" étant utilisée dès que l'on a "l'impression que c'est immédiat" (en ressentit humain) par tellement de gens, on pourrait renommer le vrai "temps réel".
Quoique si on lâche là dessus il faudra utiliser hacker pour dire pirate.
Sinon, comme wikipédia le fait, l'astuce, pour s'en sortir, consiste à parler de temps réel dans un cas et de système temps réel dans l'autre.
https://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el
[^] # Re: Mauvaise image
Posté par nico4nicolas . Évalué à 3. Dernière modification le 16 janvier 2019 à 14:31.
Le terme "temps réel" est mal nommé puisque qu'il s'agit en fait de la maitrise du temps d'exécution. Le FPGA est particulièrement adapté à la problématique de la maîtrise du temps puisque la donnée/le signal va passer à travers un chemin défini et maîtrisé. Le plus long chemin sera donc le temps garanti d'exécution. La contrainte temporelle étant maîtrisée, le FPGA peut faire du temps dit "réel".
Wikipedia a dit :
[^] # Re: Mauvaise image
Posté par gUI (Mastodon) . Évalué à 6.
Ah oui dans ce sens là. J'ai déjà vu passer l'expression "en temps contrôlé" qui serait bcp plus rigoureuse en effet.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mauvaise image
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
"J'ai déjà vu passer l'expression "en temps contrôlé" qui serait bcp plus rigoureuse en effet."
J'aime bien "temps contrôlé", mais on doit pouvoir faire mieux.
J'ai beaucoup travaillé sur des sujets ou on me demandait de garantir l’exécution de 99% de taches
en moins de 15 minutes et je refusais catégoriquement que certains nomment cela du "temps réel".
Les systèmes temps réels que je connaissais dans l'embarqué géraient de véritables contraintes,
et utilisaient des noyaux temps réels.
On est ni sur les mêmes enjeux, ni sur les mêmes contraintes, ni sur les mêmes architectures
techniques, ni sur les mêmes langages et outils, il faudra certainement clarifier le vocabulaire
pour éviter les catastrophes dans le nouveau monde .
Par ailleurs, l'expression "temps réel" a aussi un sens en médiologie. Ça devient bordélique
si on parle de médias du style twitter/facebook qui permettent de suivre l'actualité
en "temps réel" au sens de la médiologie mais en utilisant des technos non "temps réel"
dans leurs architectures techniques.
[^] # Re: Mauvaise image
Posté par nico4nicolas . Évalué à 4.
J'imagine que les tâches en question s'exécutaient dans un système d'exploitation grand public. Tu avais donc raison car le mot clé est garantir et il est impossible de garantir un temps d'exécution si tout l'environnement n'est pas contrôlé/maîtrisé.
La définition même du "temps réel" en médiologie telle que donnée par Wikipedia est incorrecte :
sans attente, immédiat est impossible dans le monde réel. Le temps de traitement de l'information au niveau humain est négligé mais n'est pas nul. Le temps que la lumière met pour parcourir une distance (300 000 km/s), le temps que l'électricité met pour parcourir nos nerfs (30 m/s), le temps que cerveau met pour interpréter les signaux électriques.
[^] # Re: Mauvaise image
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 3.
C'était un OS à chapeau rouge sur une infra X86 virtualisée classique.
C'était "garanti" contractuellement vis à vis de notre client (grande distribution). En cas de retard, on avait juste des pénalités financières et pas des châtiments corporels (heureusement).
En médiologie, "temps réel" est opposé à "en différé". C'est sur une autre échelle de temps.
Il y a peu, on avait encore un compte rendu des manifestations dans les journaux papiers
uniquement le lendemain (c'était mieux avant, hein, dominique ?).
De nos jours, on a plusieurs chaines d'infos en continu, des livefeeds twitter facebook interactifs, etc.
[^] # Re: Mauvaise image
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
C'est la différence entre temps réel mou et temps réel dure.
Example : la boucle de pilotage d'une commande de vol électrique. c'est une fonction appelé 250 fois par seconde, soit 4 ms de traitement. Le temps est fixe pour la simplicité et cela colle avec les théories sur le traitement du signal. La contrainte simple, quoi qu'il se passe le traitement ne dois jamais dépasser 4 ms.
Pour faire ça, l'équipementier doit prouver que WCET (worst case execution time) est inférieur à 2 ms (oui, on prends 50 % de marge). L'OS spécifique détruit la tache si la deadline est dépassé et passe en mode dégradé.
Dans le cas "mou", c'est l'exemple de VLC qui a peu de temps pour décoder la prochaine frame. Si il ne va pas assez vite, la vidéo n'est plus fluide, il faut donc virer des images pour soutenir le rythme, ce qui peut être compliqué à faire correctement (éviter la désynchro son/images,…). Le problème peut être ponctuelle avec une charge cpu ou IO qui varie, comme le démarrage d'un navigateur internet.
En fait, le cas mou est bien plus complexe que le cas dur, où l'on arrête tout en cas de dépassement.
"La première sécurité est la liberté"
[^] # Re: Mauvaise image
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 3.
Dans les deux exemples très pertinents que tu donnes, les systèmes analysent leur propre performance et réagissent de manière autonome, à chaque itération.
Dans l'exemple que j'ai donné plus haut, il n'y avait rien de similaire. On se contentait d'analyser à posteriori la performance du système.
Les gens qui voulaient utiliser le terme "temps réel" avait l'habitude programmer ces traitements dans un batch nocturne qui traitait toutes les réceptions du jour et d'analyser le temps de traitement du batch complet avec un engagement client à 24 heures. Passer à un engagement à 15 minutes a déjà été difficile. Pour ces traitements, on a fini par utiliser le terme de "fil de l'eau". Le système traite ce qu'il reçoit dès
qu'il le reçoit, mais il ne peut pas offrir plus de puissance que ce qu'il a.
Ensuite on est passé à 5s mais c'est une autre histoire.
[^] # Re: Mauvaise image
Posté par gUI (Mastodon) . Évalué à 8.
Pour moi c'est du temps réel. On te demande de prouver que tu tiens un certain temps ? Alors ça en est. Tes tâches de 15mn, un ABS qui doit prendre une décisions en 0.1ms, même combat.
Ensuite les stratégies mises en oeuvre pour tenir ce "temps réel" sont diverses, notamment un OS temps réel dur (il va te couper le quiqui si tu dépasses) ou temps réel mou (les tâches sont sympas et redonnent la main par elle-même) selon la criticité, le risque de dépassement etc.
En d'autres termes : peut-on faire un système temps réel avec un kernel non temps réel (Windows, Linux sans les patches RTLinux) ? Oui je le pense.
Parce que si on veut faire l’ayatollah de la démonstration, on va commencer par regarder le hardware : mémoire cache, bus PCI, exécution dans le désordre, prédiction de branchement, tout ça fout un bordel de dingue dans les calculs, pourtant on l'accepte volontiers.
Mais bon, on est plus dans la rhétorique que la technique, on est d'accord :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Mauvaise image
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
Dans mon cas, c'était surtout du bon dimensionnement de la VM pour gérer les pics de charge et s'assurer que le code qui tourne a bien les performances attendues.
On me demandait juste de mesurer le temps écoulé pour chaque tache et on faisait un bilan en fin de semaine.
[^] # Re: Mauvaise image
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Dans un benchmark classique de fonction rapide, on a l'habitude de faire 10000 boucles, mesurer le temps et faire la division. Le résultat n'aura pas beaucoup de sens, sauf à gros grain.
Je me rappelle d'un cas de calcul de WCET, selon que les caches étaient froid ou non, j'avais un temps d’exécution x10…
Suite à ce benchmark, j'ai changé ma manière de mesurer les fonctions, je faisais bien 10 000 boucles, mais j'utilisais les timer cpu (RDTSC) précis au coup d'horloge prêt. Et je faisait un graph avec ces 10 000 points temporelles.
En général, on voyait le première démarrage à froid, puis une descente en 2 temps, un plateau. Puis des piques plus ou moins important, lié à un changement de contexte ou une allocation mémoire, sur quelques points seulement, mais de manière très régulière.
Du graphique, on peut en tirer la "vitesse max" (le plateau bas), le WCET (les pics) tout en sachant que l'on peut se prendre x100. Cela dépende ce que l'on cherche à faire.
J'avais tendance à prendre la tout première mesure, comme moyenne étant le plus proche de la réalité, car ce bout de fonction avait une probabilité faible de tomber pendant un changement de contexte.
"La première sécurité est la liberté"
[^] # Re: Mauvaise image
Posté par martoni (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 16 janvier 2019 à 14:21.
J'ai essayé 3 fois de la publier en dépêche, mais j'ai une erreur oops de linuxfr :(
Avec le recul c'est vrai que c'est un peu confusionnant, c'était pour faire écho à la traduction littéral de FPGA : Field Programmable Gate Array ;)
J'ai plus qu'une balle
[^] # Re: Mauvaise image
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 4.
"J'ai essayé 3 fois de la publier en dépêche, mais j'ai une erreur oops de linuxfr :("
Faut passer sur les tribunes (celle des dépêches en cours ou celle des moules), y'aura bien qqun pour aider.
"c'était pour faire écho à la traduction littéral de FPGA"
Ça serait plutôt un champ d'éolienne une semaine et des panneaux solaires la semaine suivante ?
J'avais plus une image en tête avec un centre d'appel (externalisé) plein de cubicles.
Une semaine ils bossent pour une assurance, la semaine d'après pour un marchand de robinet.
C'est moins efficient que de l'avoir en interne (ça va moins vite et y'a des soucis d'I/O :))
mais c'est plus polyvalent.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.