Couverture ElectroniqueS n°127

L'éditeur canadien QNX est l'un des tout premiers à proposer un environnement de développement intégré, incluant outils et OS enfoui, spécifiquement adapté au support des processeurs multic&oelig;urs. Pour bon nombre d'observateurs, l'année 2005 aura consacré la montée en puissance des processeurs multic&oelig;urs dans les milieux de l'embarqué (voir EI n° 615) et tout particulièrement dans les équipements pour infrastructures télécoms, qui constituent, pour l'heure, les plus gros consommateurs de tels circuits. Il n'est donc guère étonnant de voir les éditeurs d'OS enfouis et d'environnements de développement associés s'adapter à la nouvelle donne et essayer de faciliter la tâche de leurs clients, pas nécessairement aguerris aux subtilités du multic&oelig;ur. Si certains d'entre eux tentent, via la Multicore Association, de poser les fondements de standards adaptés (voir encadré), QNX, lui, a décidé de prendre les devants. Fort d'une présence non négligeable sur le marché des équipements télécoms (QNX y réalise environ 20 % de son chiffre d'affaires et compte Cisco parmi les utilisateurs de son OS temps réel), l'éditeur canadien annonce une édition de sa suite d'outils Momentics spécifiquement calibrée pour les processeurs multic&oelig;urs tels que les BCM12xx et BCM14xx de Broadcom, le MPC8641D de Freescale ou les dernières puces d'Intel. Sa disponibilité est prévue d'ici à la fin mars 2006.Supporter différents modèles de programmation« Lorsqu'on décide de proposer des outils adaptés aux architectures multic&oelig;urs, il y a une chose qu'il ne faut pas oublier, c'est le support du code historique de l'utilisateur, code qui, en général, a été conçu dans une optique mono-processeur, s'empresse de préciser Mark Roberts, directeur product management de QNX. Momentics, Multicore Edition, a justement été développé pour faciliter la migration d'applications initialement élaborées pour des architectures monoprocesseurs vers des designs à base de circuits multic&oelig;urs, sachant que l'utilisateur peut opter pour le modèle de programmation le mieux adapté à ses besoins. »De fait, l'environnement de développement de QNX, qui repose sur la version 3.0 de la plate-forme Eclipse*, supporte les modes multiprocesseurs symétrique (SMP) et asymétrique (AMP) ainsi qu'un mode hybride dit “ Bound Multiprocessing ” (BMP), propre à l'éditeur. Rappelons, à cet égard, que le mode AMP consiste à associer à chaque c&oelig;ur un environnement logiciel distinct (OS et applications), les OS pouvant être identiques ou différents – Linux et QNX Neutrino par exemple.Un tel modèle convient bien aux programmes qui n'ont pas été conçus pour un traitement parallèle, mais il nécessite de relever quelques défis techniques au niveau de la synchronisation des c&oelig;urs (qui ne peut se faire qu'au niveau applicatif) et du partage des ressources. Par ailleurs, les capacités d'évolution du design sont limitées. Le mode SMP, quant à lui, ne pose pas ce genre de problèmes, puisque c'est un OS unique qui gère l'ensemble des processeurs et qui peut, de ce fait, équilibrer la charge de travail sur les différents c&oelig;urs, quel que soit leur nombre. Reste que ce modèle n'est pas, lui non plus, sans inconvénient. Certains programmes, et notamment ceux qui affichent un faible synchronisme entre threads*, se prêtent mal à un traitement de ce type. Le mécanisme dynamique d'équilibrage de charge peut aussi générer un over-head pénalisant pour des applications auxquelles, dans l'absolu, il vaudrait mieux dédier un processeur. C'est la raison pour laquelle QNX a élaboré le mode BMP, qui cumule les avantages des deux précédentes approches. Ce mode permet, simultanément, de coupler des applications ou des threads – les anciens programmes notamment – à un c&oelig;ur donné et de faire du traitement SMP sur de nouvelles applications développées spécifiquement pour le multic&oelig;ur (voir illustration). Le support du BMP exige toutefois une mise à jour du noyau QNX Neutrino, mise à jour qui sera disponible dans le courant de ce trimestre en même temps que l'environnement Momentics, Multicore Edition, avec ses outils optimisés. * cf lexique page 53La multicore association en quelques motsFormée d'une trentaine de sociétés qui ont entamé des discussions en mai 2005, la Multicore Association a tenu sa première réunion formelle fin novembre 2005. Objectif : développer des standards utilisables dans des architectures à multiples éléments de traitement, homogènes ou hétérogènes.Trois groupes de travail ont déjà été créés. Présidé par PolyCore, Ignios et Freescale, le premier compte définir une API qui serve de couche d'abstraction entre les applications et les mécanismes de communications entre c&oelig;urs de processeurs.Supervisés par Wind River, les deux autres groupes de travail planchent sur une API de débogage et sur le protocole Open Source TIPC, protocole utilisé pour les échanges entre process tournant sur différents OS intégrés dans un même équipement (TIPC est notamment supporté par Linux, VxWorks et QNX).

L’environnement de développement prend le train du multic

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

L’environnement de développement prend le train du multic

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure