Des MEMS et du Libre

Posté par . Modéré par Florent Zara.
26
26
juil.
2011
Matériel

Je travaille dans les MEMS, les microsystèmes électromécaniques (Micro‐ElectroMechanical Systems), voir l'introduction dans la suite de cette dépêche issue d'un journal de maclag< pour plus de détails sur ce domaine.
Suite à un commentaire de ma part dans lequel je disais qu’il n’y a rien de libre dans le secteur où je bosse, j’en profite pour faire un état des lieux des « sources ouvertes » qui gravitent autour de ce secteur.

Sommaire

Mais commençons par le commencement :

Introduction

Je travaille dans les MEMS, les microsystèmes électromécaniques (Micro‐ElectroMechanical Systems). Le principe qui a conduit à ces petits joujoux est la découverte que le Silicium n’est pas seulement un matériau remarquable pour ses propriétés électroniques, mais également mécaniques. Les MEMS utilisent donc une technologie dérivée et très proche des techniques de fabrication des circuits intégrés traditionnels. Le but est de fabriquer des éléments mécaniques, mobiles, avec des connexions électriques.

Un système complet comporte, en plus de la partie mécanique, une électronique de gestion. Le tout est soit fait sur une seule puce en Silicium, soit en deux puces ou plus, avec la partie mécanique d’un côté et la partie électronique de l’autre. Si je dis électronique de gestion, et pas de commande, c’est parce que les MEMS peuvent être aussi bien des capteurs que des actionneurs, et l’électronique est bien évidemment très différente !

Les exemples les plus connus de MEMS sur le marché sont les capteurs de pression, mais surtout les accéléromètres, les gyroscopes, et, peut‐être de façon un peu plus sujette à discussion (pas vraiment des MEMS), les capteurs magnétiques (boussoles). On les retrouve maintenant dans les téléphones portables, appareils photo, etc..

Le lien avec les circuits intégrés

Pourquoi s’intéresser aux MEMS ?

Eh bien, on est sur un site qui traite du Libre, je suis un Linuxien et libriste modéré, mais disons tout de même convaincu, et la vraie question serait plutôt : pourquoi ne pas en parler ?

Comme vous le savez ou devriez le savoir, il existe un mouvement libre autour des circuits intégrés, dont le meilleur regroupement est le site OpenCores.

Mais, intéressons‐nous un peu au flot de conception (simplifié) de circuits intégrés :

  1. définitions des spécifications (fonctions, interfaces) ;
  2. modélisation haut niveau (un peu de VHDL/Verilog haut niveau), simulations haut niveau ;
  3. modélisation bas niveau, utilisant éventuellement des bibliothèques (VHDL/Verilog). Cette partie inclut les optimisations. À partir du résultat, on peut utiliser un outil de synthèse automatique ;
  4. synthèse du circuit : on obtient ici le schéma électronique bas niveau ;
  5. organisation de la disposition (layout) du circuit ;
  6. placement, routage (on dispose les blocs du circuit, le routage correspond aux connexions électroniques).

Maintenant, que trouvons‐nous sur des sites comme OpenCores ?

  • des bibliothèques ;
  • des descriptions synthétisables de circuit.

On ne peut pas descendre plus bas, parce que pour aller plus bas, il faut les paramètres physiques des composants, et ces paramètres dépendent de l’usine et de la technologie que vous allez utiliser (ex : TSMC 0,13 µm ou Austria Microsystems 0,6 µm ? Ça change beaucoup de choses !).

Et ceci n’est valable quasiment que pour les circuits numériques. Pour les circuits analogiques, on travaille encore en bas niveau (pas de synthèse automatique). On utilise donc, dès les premières étapes de la conception, les paramètres liés à la technologie.

Et les MEMS alors ?

Eh bien pour les MEMS, la situation est encore plus délicate : il n’y a pas vraiment d’outil installé pour la description haut niveau. On utilise des outils de conception mécanique (CAO), plutôt que des outils du monde électronique. Bien évidemment, il y a de plus en plus de passerelles, mais les outils de synthèse automatiques ne vont que rarement au‐delà de « modifie légèrement ce composant pour que les specs changent de autant ».

Parce que si pour l’électronique, un procédé de fabrication différent signifie essentiellement des paramètres différents, pour les MEMS, les procédés de fabrication peuvent n’avoir quasiment rien en commun. Exemples : usinage de surface (donc films minces) contre usinage de volume (donc éléments avec une dimension suivant Z très grande devant une des deux autres dimensions) ; utilisation de silicium polycristallin, monocristallin, métal, matériau organique, etc.

Du coup, un concept ne sera applicable que pour une « famille » de technologie ou, le plus souvent, juste un nœud technologique particulier.

Il s’agit d’ailleurs d’un problème connu dans l’industrie, et la réputation des MEMS auprès des micro‐électroniciens « un produit, un procédé » (procédé de fabrication différent pour chaque produit) est presque vraie.

Il y a plusieurs raisons à cette situation :

  • la technologie MEMS est finalement assez jeune et immature. Les « meilleures » technologies ne sont pas encore identifiées. Imaginez, par comparaison, que la bataille fasse toujours rage entre téléviseurs cathodiques optimisés, plasma, LCD, LED, AMOLED, etc.. Faites‐vous une bonne longue liste, ensuite la grande question est : comment faire une gamme de télé et d’écrans d’ordinateur sur une seule techno ?
  • les fabricants de composants électroniques entrent à peine dans le fabless, certains veulent néanmoins conserver tout ou partie de la fabrication des MEMS en interne, pour diverses raisons (ex : Bosch, qui a quelques technos MEMS un peu exclusives) ;
  • il y a, de l’avis général, beaucoup trop de purs fondeurs MEMS ; ce sont pour la plupart des petites fonderies aux capacités limitées, ce qui pousse les fabricants de composants à en avoir plusieurs, dont les technos sont incompatibles…

La situation pourrait changer avec l’entrée sur scène des géants de la micro‐électronique : TSMC, Global Foundries, UMC. Avec des capacités de fabrication et d’investissements conséquentes, ils pourraient attirer assez de clients pour établir leurs technos comme un standard de fait.

Si un standard est établi, il devient possible de développer des briques élémentaires réutilisables, mais aussi de se lancer dans les conceptions libres et ouvertes. Aujourd’hui, un composant MEMS libre serait totalement lié à un fondeur et une technologie en particulier, ce qui en limiterait considérablement l’intérêt…

Alors rien de libre dans les MEMS ?

Ne soyons pas si pessimistes ! Si la conception des MEMS eux‐mêmes est toujours très fermée, il n’en va pas de même pour les outils de cette conception.

Tout d’abord, mentionnons :

Sugar

Sugar n’est pas seulement un outil de de gestion de la relation client, mais aussi un projet relativement ancien de simulation comportementale de MEMS. En général, les outils de simulation de MEMS sont basés sur les éléments finis, et sont des outils de bas niveau (on calcule les contraintes externes à un élément, internes, qu’elles soient mécaniques, thermiques, électriques, etc., et on en déduit un déplacement et/ou une déformation et/ou en incluant une température, etc.).

Sugar a une approche différente. On suppose ici que vous savez, par exemple, comment se comporte votre poutre sous diverses contraintes, et vous pouvez donc aborder la simulation à un niveau plus haut : des combinaisons de poutres, par exemple.

La mauvaise nouvelle, c’est que Sugar semble être plus ou moins à l’abandon. Si vous postez un message sur leur forum demandant si le projet est mort, vous recevrez systématiquement un « non, non, ça a traîné, mais on s’y remet bientôt ». Ça fait presque 10 ans que ça va s’y remettre bientôt…

Encore une fois, Sugar est contraint de s’appuyer sur une technologie particulière (ici, le procédé PolyMUMPs). Mais le concept est adaptable relativement facilement à d’autres technos.

Simulation par éléments finis

Ensuite, si l’on sait que les éléments finis sont le point central des MEMS, on peut très bien imaginer des solutions basées sur Open CASCADE. Malheureusement, je ne connais aucune initiative active allant dans ce sens aujourd’hui.

Il est difficile d’utiliser un simulateur MEF (méthode des éléments finis) « brut » à cause des rapports d’aspect que peuvent présenter les MEMS. Des objets dont les dimensions les rendent comparables à une feuille de papier très fine : on mélange quelques centaines de nanomètres d’un côté, et de l’autre, les dimensions atteignent des centaines de microns. On se retrouve avec de gros problèmes d’erreurs numériques. Il faut utiliser des méthodes de calcul particulières.

Une autre difficulté est souvent dans le côté dit « multi‐physique ». Les propriétés mécaniques des MEMS ne suffisent pas, il faut combiner le plus souvent au moins l’électronique et la mécanique. Parfois, on y ajoute le thermique et d’autres. Beaucoup de composants MEMS sont vibrants, et les frottements avec le milieu ambiant ne sont pas négligeables. Néanmoins, les gens versés dans l’art de la fluidique admettront volontiers qu’il s’agit d’une des choses les plus difficiles à simuler, non seulement en termes de puissance de calcul brut nécessaire, mais aussi en termes de modélisation initiale.

Donc, les simulateurs MEMS libres ne sont pas là aujourd’hui, mais on pourrait les voir arriver assez rapidement si des moyens sont mis dessus !

Applications

Enfin, avec la complexité croissante des systèmes modernes, on ne fournit plus vraiment un composant MEMS, mais on parle de « solution » : le composant et les outils de gestion informatique (pilotes, algorithmes, etc.). On retombe ici dans quelque chose qui sera plus familier pour tout le monde : des logiciels ! Pour prendre les applications les plus en vogues en ce moment, il y a beaucoup de choses à faire dans le domaine des centrales inertielles, la correction des boussoles électroniques en fonction de l’attitude du téléphone, et encore beaucoup, beaucoup d’applications à réaliser. Et de ce côté, on voit beaucoup de code libre.

On voit même ce côté libre chez des fabricants avec, par exemple, Freescale qui fournit CodeWarrior, un IDE basé sur Eclipse dédié au développement sur ses produits. Freescale produit également une gamme de capteurs MEMS sous le nom Xtrinsic, embarquant de sérieuses capacités de calcul numérique. Le lien avec CodeWarrior est ici assez évident.

Conclusion

Les MEMS, comme beaucoup de composants matériels, sont sujets à extrêmement peu de développements libres. En revanche, leur environnement, aussi bien de développement que d’application, présente une activité existante et beaucoup d’opportunités.
En attendant, on ne me verra pas écrire que « je fais du Libre au travail » avant très longtemps…

  • # CodeWarrior

    Posté par . Évalué à 4.

    Merci pour cette dépêche. Je réagis là-dessus :

    On voit même ce côté libre chez des fabricants avec, par exemple, Freescale qui fournit CodeWarrior, un IDE basé sur Eclipse dédié au développement sur ses produits.

    En lisant cette phrase, j'ai eu un sursaut en croyant comprendre que CodeWarrior était libre. Ce n'est pas le cas. J'ai bossé plusieurs années chez Freescale (jusqu'au licenciement massif de 2009...), et j'ai travaillé (resp. pesté) pas mal avec (resp. contre) CodeWarrior. D'ailleurs même en interne on était emmerdé par les licences...

    Le site de Freescale dit ceci :

    Freescale's CodeWarrior Development Studio for Microcontrollers v10.1 integrates the development tools for the RS08, HCS08, ColdFire, ColdFire+, Kinetis and MPC56xx architectures into a single product based on the Eclipse open development platform. Eclipse offers an excellent framework for building software development environments and is becoming a standard framework used by many embedded software vendors.

    La licence EPL d'Eclipse permet en effet de l'intégrer dans un logiciel propriétaire.

    Ah... CodeWarrior... Peut-être que la version distribuée en extérieur n'inclut pas les problèmes de celle qu'on utilisait (lourdeur et stabilité notamment, et puis problèmes de compatibilité ascendante / régressions qui faisaient que la dernière version n'était pas toujours celle à utiliser, peut-être à cause d'un cycle de livraison court). Un jour on a investi dans des sondes Lauterbach Trace32 qu'on pilotait avec le logiciel fourni avec et qui remplaçait CodeWarrior. Quel bonheur. Ca plantait bien de temps en temps, mais ça se relançait en quelques secondes. Et ça ramait drôlement moins.

    • [^] # Re: CodeWarrior

      Posté par (page perso) . Évalué à 3.

      Il n'y a que deux types de personnes qui se plaignent d'un IDE : ceux qui se plaignent de Paradigm, et ceux qui n'ont jamais utilisé Paradigm.

      C'est vrai que dans l'embarqué, les IDE sont généralement très mauvais. Mais Paradigm, c'est une catacatacatastrophe. Quand on est contraint de l'utiliser, on fini par se dire qu'on s'est planté de voie, qu'on a raté sa vocation, que n'importe quel autre job serait préférable.
      Code Warrior a côté de Paradigm, il est juste génial !

    • [^] # Re: CodeWarrior

      Posté par . Évalué à 2.

      Bon, j'avoue que je me suis très mal renseigné. Je pensais sincèrement qu'il s'agissait d'un outil libre, car basé sur Eclipse.

      En ce qui concerne sa facilité d'utilisation, je n'en sais franchement rien, moi je m'arrête au composant...

      Modérateurs: il serait bon de corriger mon erreur dans cette dépêche!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.