Convoyeur à vendange, Suisse, 2019

I am PhD graduated from Verimag (Synchrone team, Université Grenoble Alpes) and the Kalray company. I worked under the supervision of Pascal Raymond, Matthieu Moy at Verimag and Benoît Dupont de Dinechin at Kalray.

My topic was the parallel code generation from the Synchrous data-flow languages Lustre/Scade to the Kalray MPPA many-core processor.

Research Interests

• Synchronous data-flow languages (Scade/Lustre)
• Parallel execution on multi-cores with real-time constraints.
• Network-on-Chip deadlock-free unicast and multicast routing algorithm.
• Quality of Service (QoS) on a network-on-Chip.

Publications

• Bounding the delays of the MPPA network-on-chip with network calculus: Models and benchmarks
  Marc Boyer, Amaury Graillat, Benoît Dupont de Dinechin, Jörn Migge, Performance Evaluation Journal 143: 102124, 2020.
• Response Time Analysis of Dataflow Applications on a Many-Core Processor with Shared-Memory and Network-on-Chip
  Amaury Graillat, Claire Maiza, Matthieu Moy, Pascal Raymond, Benoît Dupont de Dinechin, RTNS 2019 / 27th International Conference on Real-Time Networks and Systems, Toulouse, France, November 2019.
• Parallel Code Generation of Synchronous Programs for a Many-core Architecture.
  A. Graillat, B. Dupont de Dinechin et al. DATE 2018 – Design, Automation and Test in Europe, March 2018, Dresden, Germany. 2018
• Computing Routes and Delay Bounds for the Network-on-Chip of the Kalray MPPA2 Processor.
  Marc Boyer, Benoît Dupont de Dinechin, Amaury Graillat, Lionel Havet – European Congress on Embedded Real-Time Software (ERTS 2018), Toulouse, France, January 2018.
• Feed-Forward Routing for the Wormhole Switching Network-on-Chip of the Kalray MPPA2-256 Processor.
  B. Dupont de Dinechin & A. Graillat. 10th International Workshop on Network-on-Chip Architectures (NoCArc 2017), Boston, MA, USA
• Network-on-Chip Service Guarantees on the Kalray MPPA-256 Bostan Processor.
  B. Dupont de Dinechin & A. Graillat. 2nd International Workshop on Advanced Interconnect Solutions and Technologies for Emerging Computing System (AISTECS 2017), Stockholm, Sweden

Thesis

• Defense slides

« Sinon, tu travailles sur quoi exactement ? »

J'aime bien cette question, savoir que quelqu'un s'intéresse à mon travail est très gratifiant, pourtant, je la redoute : comment vulgariser suffisamment sans trop simplifier, ou comment donner assez de détails sans se perdre dans des périphrases incompréhensibles.

L'exercice est périlleux, alors je me lance.

Du régulateur de James Watt à ma thèse.

Un peu d'histoire

Pour réguler automatiquement la vitesse de sa machine a vapeur et ainsi avoir une vitesse la plus constante possible, James Watt (1), a inventé un système très ingénieux : il fixa à une tige, entrainée par la machine, deux boules en métal au bout de bras. Ainsi, plus la tige va vite, plus les deux boules s'écartent. Les bras maintenant les boules étant reliés au robinet d'alimentation en vapeur, la hauteur des boules fait varier l'arrivée en vapeur : la vitesse agit sur l'arrivée de vapeur, il y a rétroaction.

Le régulateur à boules de James Watt.

Aujourd'hui, cette science de la régulation (ou contrôle) s'appelle l'automatique. On parler alors d'actionneur (le robinet), de capteur (les deux boules en métal pour capter la vitesse) et une boucle de rétroaction : la machine a vapeur qui fait varier sa vitesse en fonction du débit de vapeur.

Bien sûr, les systèmes entièrement mécaniques sont rares et l'invention de l'électronique, puis de l'informatique ont permis des systèmes beaucoup plus complexes et performants. Il existe donc des programmes (logiciels) de contrôle.

(1) Cet exemple vient de l'article From Control Loops to Real-Time Programs de Paul Caspi and Oded Maler (Verimag-CNRS, 2005).

Les systèmes critiques, temps réel dur

Certains systèmes contrôlés sont très critiques : un fonctionnement anormal peut avoir des conséquences graves (humaines, écologiques, etc). Les exemples souvent cités sont les commandes de vol d'un avion, ou les systèmes de sécurité d'une centrale nucléaire, mais aussi dans les voitures (que dire de la voiture « autonome » ?).

Dans le cas d'un avion, les actionneurs sont les ailerons et les élévateurs de l'avion, des capteurs mesurent l'altitude, ou les commandes du pilote par exemple. Entre ces capteurs et ces actionneurs, il n'y a plus de systèmes à boules, mais un ordinateur qui calcule la position des actionneurs en fonction de la valeur des capteurs (après numérisation) : la position de l'élévateur, en fonction des entrées.

Une caractéristique de ces systèmes critiques est que le temps fait partie intégrante du cahier des charges : on imagine difficilement le système de contrôle demander au pilote d'attendre la fin du chargement pour rétablir la trajectoire de l'aéronef (!) ou que l'altitude de l'avion soit momentanément traitée 10 secondes plus tard.

Les langages synchrones

Peu après 1989, le besoin d'avoir un langage permettant de rendre le développement de programmes de contrôle plus facile s'est fait sentir. Il fallait un langage pouvant être compris par les automaticiens et qui intègre une notion de temps pour faciliter le développement de tels programmes.

Entre 1991 et 1992, trois langages sont apparus : Lustre, Signal et Esterel.

« Bien. Et donc, tu travailles sur quoi exactement ? »

Les langages synchrones sont très utilisés actuellement pour la programmation de systèmes de contrôle. Cependant, pour rendre les systèmes plus performants, plus confortables, plus complets, etc, ces programmes se complexifient.

Depuis une dizaine d'années, les processeurs arrivent à leurs limites : il n'est plus possible d'augmenter la performance sans augmenter énormément la consommation. Ainsi, sont apparus les processeurs multi-cœurs (contenant plusieurs processeurs) offrant de meilleurs performances pour une consommation moindre.

Cependant, ces processeurs récents sont très complexes et rendent les temps de calculs très difficiles à prévoir (certains comportements sont même aléatoires) : alors que justement, le temps est très important pour le contrôle !

L'entreprise Kalray conçoit un processeur many-cœurs qui permet de prévoir (de manière pas trop pessimiste) ces temps de calcul.

Mon sujet de thèse est donc : comment faire tourner ces programmes de contrôle sur le Kalray MPPA.

Depuis octobre 2015, je suis en thèse CIFRE. C'est un contrat entre un doctorant, une entreprise et un laboratoire. Je passe donc 3 jours chez Kalay, une entreprise qui conçoit et commercialise un processeur many-core. Un many-core est une puce (SoC) composée de plusieurs processeurs reliés par un réseau. Ainsi, deux jours par semaine, je suis chez Verimag, un laboratoire de recherche dont les sujets principaux sont la vérification de programme et les langages synchrones. C'est une courte introduction, mais je compte écrire un article pour détailler un peu ces notions.

Voici le début d'une série d'articles introduisant ma thèse. Je consacre le premier aux décisions qui m'ont conduites à la recherche.

Passage par le master recherche

J'ai été étudiant à l'Ensimag (Grenoble INP) pendant 3 ans, jusqu'à l'été 2015. Durant le second semestre de la 2ème année, j'ai consacré un après-midi par semaine chez Verimag à un stage recherche. Cette expérience m'a donné envie de m'inscrire en Master 2 recherche (M2R) en septembre 2014. Ensuite, j'ai passé l'été 2014 chez SAP à Walldorf (j'ai écris un article), ce n'était pas un stage recherche, mais très R&D quand même car je travaillais sur certaines instructions de l'Intel Xeon Phi (qui n'était alors pas encore commercialisé).

Septembre 2015. Le Master 2 recherche (M2R) s'appelle MoSIG, Master of Science in Informatics at Grenoble (notez le terme informatics, qui, je trouve actuellement plus juste que computer science, si vous avez 5 mn, réfléchissez-y sur votre vélo :-)). Il existe plusieurs filières, celle que j'ai choisi traite d'informatique embarquée, de programmation parallèle et de systèmes distribués. Les cours sont dispensés en anglais, ce qui nous épargne les phrases du type : « Ce handler catch l'exception du cache miss. », pour le bien de tous.

J'ai fait ce choix de « l'informatique embarquée » plusieurs fois : en DUT Informatique. En vérité, j'aime me situer à la limite entre l'électronique et l'informatique (j'ai aussi fait le choix bac STI Electronique pour atteindre l'informatique par le matériel). Cette proximité électronique/informatique est très présente, notamment en embarquée où le matériel a autant d'importance que le logiciel : pour la fiabilité des systèmes critiques, la réduction de la consommation pour réduire la chaleur ou optimiser les batteries et la robustesse.

Les 6 mois de cours ont été très intéressants bien qu'un peu déroutant au début. En effet, en école d'ingénieurs, j'avais été habitué à avoir des travaux pratiques dans toutes les matières. Le master s'est passé différemment, car les cours étaient là pour dresser l'état de l'art d'un domaine. Par exemple, les grands concepts et méthodes et les papiers fondateurs. Aussi improbable que ça puisse paraitre, sans le nommer, j'ai fait de l'histoire : l'informatique est déjà assez vieille (et a évoluées assez vite) pour avoir une histoire propre.

J'ai passé beaucoup de mon temps libre à lire des articles, pour approfondir les concepts et avoir des exemples. Le but de la formation est surtout d'avoir un sens critique sur les articles et de savoir les comparer. Finalement, le manque de travaux pratiques, déroutant au début, ne m'a pas gêné, cela m'a plutôt poussé à chercher par moi-même.

Chercher par moi-même, connaitre l'historique des choses, avoir un sens critique sur les articles. C'était le nécessaire pour appréhender le stage de recherche et plus tard, le doctorat.

Le stage recherche

Le stage recherche au laboratoire Verimag a été très différent de ce que j'imaginais : plus dur. Le sujet « vers la génération de code d'une langage synchrone sur un architecture many-core » paraissait très technique au premier abord. Aussi, je n'avais jamais programmé sur un processeur many-core, cependant, avec quelques jours passé à lire la documentation, j'ai pu apprendre à faire fonctionner mes premiers exemples. Ce sujet étant proche de celui de mon doctorat, je le décrirai plus en détail dans l'article sur mes recherches actuelles.

Les difficultés n'ont finalement pas été techniques, mais propres à la recherche.

J'ai dû comprendre le jargon du domaine. En effet, il y a beaucoup de notions à connaitre et à savoir exprimer. Il faut oublier les synonymes et la beauté de la langue ! Un mot est une notion précise qu'il faut apprendre. Parfois, ce qui semble être un synonyme crée un contre-sens et embrouille une discussion. Comme toujours, si on oublie l'art, la langue n'est qu'un outils.

Plus tard, nous avons assisté à une formation pour apprendre à mieux utiliser la puce. J'ai appris alors que l'entreprise avait justement besoin d'un doctorant pour travailler sur les usages embarqués critiques. C'est ainsi que j'ai commencé mon doctorat.