logiciel libre - Open Wide Ingénierie

Solutions libres pour les systèmes embarqués
Pierre FICHEUX ([email protected])
Mars 2015
Logiciels libres et SE
1
Programme
●
●
●
●
●
●
●
●
●
●
Présentation
Rappels sur les systèmes embarqués et temps réel
Le logiciel libre
Linux comme système embarqué
Extensions temps réel de Linux
Android « embarqué »
eCOS et RTEMS
Les outils libres pour l'embarqué
Open hardware
Co-design
Logiciels libres et SE
2
Présentation Open Wide
●
●
●
●
●
Société d'ingénierie créée en septembre 2001 avec le
concours de THALES et Schneider Electric
Rachat d'ESG-France (automotive) en 2014
Environ 160 salariés sur Paris, Lyon, Toulouse et
bientôt Grenoble
Industrialisation de composants open source
–
Développement
–
Conseil / Formation
Trois activités :
–
OW Système d'Information (Java/PHP)
–
OW Outsourcing: hébergement
–
OW Ingénierie: informatique industrielle
Logiciels libres et SE
3
Présentation PF
●
●
●
●
●
●
Ingénieur Arts et Métiers + Sup'Aéro
Utilisateur de logiciels libres depuis 1989
Utilisateur de Linux depuis 1992
Auteur des 4 éditions de l'ouvrage « Linux embarqué »
(Eyrolles), 4ème édition parue en juin 2012 avec E. Bénard
Auteur GNU Linux Magazine et Open Silicium
CTO Open Wide Ingénierie, enseignant EPITA, ENSEIRB
Logiciels libres et SE
4
Rappels sur les systèmes embarqué
Logiciels libres et SE
5
Système / logiciel embarqué
●
●
●
●
●
●
Un système est l'association matériel + logiciel
Logiciel utilisé dans un équipement industriel ou un
bien de consommation
On dit aussi logiciel dédié ou intégré → embedded
software
L'équipement est valorisé pour son coté fonctionnel et
non pas pour le logiciel !
Un bon logiciel embarqué doit savoir se faire oublier !
On parle parfois de logiciel enfoui ou profondément
enfoui → « deeply embedded »
Logiciels libres et SE
6
Domaines d'application
●
●
●
●
●
1960-70 : remplacer / compléter des systèmes
analogiques (spatial)
1980 : RTOS (Real Time OS) génériques
2000 : OS libres, grand public
Domaines historiques/industriels
–
Militaire, spatial (RTOS/360, VRTX sur Hubble)
–
Contrôle de processus industriel
–
Transport : AUTOSAR/OSEK, ARINC 653 →
certification (DO-178)
–
Internet/Telecom : routeurs, PABX
« Nouveaux » domaines
–
Multimédia
–
automobile (IVI), objets connectés
–
médical
Logiciels libres et SE
7
Les nouveaux domaines
●
●
●
●
●
Équipement grand public (multimédia, domotique, …)
Téléphonie → 1+ milliards de téléphones Android !
Infotainment transport: automobile, aéronautique
–
Ajout de fonctions communicantes → utilisation de
protocoles standards de type IP et dérivés (HTTP,
DHCP, etc.)
–
Difficile d'intégrer ces couches dans des logiciels
embarqués propriétaires → utilisation d'un OS
« Boite noire » dédiée à un ensemble de fonctions
(passerelle médicale, set-top box avec services
étendus)
Internet des objets → #iot :-)
Logiciels libres et SE
8
Avantages d'un OS
●
●
●
●
●
Affranchit le développeur d'un travail d'adaptation au
matériel pour les interfaces de base (PCI, USB,
Ethernet...)
Permet de bénéficier des dernières avancées
technologiques et de faire évoluer le système:
protocoles réseau, multimédia, etc.
Recrutement aisé de développeurs (Linux, Android) !
Utilisation de matériel « standard »
Focalisation sur le métier de l'entreprise
Logiciels libres et SE
9
Inconvénients d'un OS
●
●
●
●
●
Empreinte mémoire
Performances
Consommation d'énergie (nombreux travaux en cours)
Criticité (sauf OS spécialisés)
Perte de maîtrise du système
Logiciels libres et SE
10
Les systèmes temps réel
●
●
●
Les applications embarquées historiques étaient temps
réel
Les systèmes d'exploitation embarqués propriétaires
sont TR (VxWorks, LynxOS, VRTX, ...) → RTOS
La progression des OS libres dans l'industrie et dans
l'embarqué en général modifie la donne !
–
Linux est utilisable dans l'industrie
–
Linux n'est pas TR
–
Linux peut être modifié pour être TR (PREEMPT-RT,
Xenomai)
–
Il existe des RTOS libres (RTEMS, FreeRTOS, ...)
Logiciels libres et SE
11
Le logiciel libre dans l'embarqué
Logiciels libres et SE
12
Historique
●
●
●
Modèle économique du marché informatique → du
matériel vers le logiciel
Projets logiciels libres majeurs (chronologie)
–
UNIX BSD
–
X Window System (X11)
–
GNU (tout d'abord sur UNIX propriétaire)
–
Linux → GNU/Linux
–
Apache
Apparition de licences libres (vs « freeware »)
–
BSD
–
GPL (dérivation et « contamination »)
–
ASL
Logiciels libres et SE
13
Quelques éléments sur le LL
●
●
●
A peu près équivalent à la notion d'open source, voir
http://www.opensource.org
Libre ne veut pas dire gratuit
La confusion vient de la signification anglaise
–
●
free = libre / gratuit
Différents types de logiciels
–
Le freeware : gratuit mais sources non disponibles, pas
forcément de licence (abandon de la « paternité » du
code)
–
Le shareware : sources non disponibles, coût modique,
licence souvent propriétaire
–
Le logiciel libre: sources disponibles, licence open
source, non liée à la notion de gratuité (on peut
vendre un logiciel libre)
Logiciels libres et SE
14
Importance du logiciel libre
●
●
●
Le logiciel libre est important dans le SI (serveurs)
Le logiciel libre a pris un part importante dans les
systèmes embarqués
–
OS (Linux, Android)
–
Outils de base (compilateur, éditeur, débogueur, ...)
–
« build systems » (Buildroot, Yocto/OE)
–
IDE (Eclipse)
La plupart des éditeurs ont au catalogue des
composants basés sur du logiciel libre (Wind River,
Adacore, LynuxWorks, ...)
Logiciels libres et SE
15
Avantages/inconvénients du LL
●
●
Avantages
–
Disponibilité du code source → maîtrise et
maintenabilité dans le temps
–
Redistribution sans « royalties »
–
Outils de développement souvent « gratuits » !
–
Support de la communauté
Inconvénients
–
Méfiance vis à vis d'un modèle décentralisé (support)
–
Contraintes de certaines licences (GPL, LGPL)
–
Support de certains matériels (?)
–
Outils moins « ciblés »
–
Documentation (?)
Logiciels libres et SE
16
Les OS libres pour l'embarqué
Logiciels libres et SE
17
Linux comme (RT)OS
●
●
●
●
Réservé aux systèmes complexes
–
32 bits minimum
–
Gestion complexe de la mémoire (MMU, pagination +
segmentation)
–
Empreinte mémoire importante: 2 Mo pour µCLinux
(sans MMU), 4 Mo pour Linux
–
Consommation mémoire vive : 16 Mo minimum
Problème de migration de anciens RTOS car Linux
n’est pas TR → évolution avec les extensions
PREEMPT-RT et Xenomai
Incompatible avec les systèmes critiques/certifiés
Souvent utilisé pour les outils, les simulateurs et
architectures « mixtes » (banc de test)
Logiciels libres et SE
18
Linux et le TR, ooops :(
Logiciels libres et SE
19
Extensions TR pour Linux
●
●
L'utilisation de Linux comme RTOS est souvent
intéressante
–
POSIX
–
Approche hybride avec quelques tâches TR
–
On conserve le confort d'un système classique
Deux approches possibles :
–
Modifier le noyau Linux afin d'améliorer ses
performances TR (PREEMPT-RT)
–
Ajouter un « co-noyau » TR qui partage le matériel avec
le noyau Linux (RTLinux, RTAI, Xenomai) → approche
« virtualisation »
Logiciels libres et SE
20
PREEMPT-RT
●
●
●
●
●
●
●
●
Branche expérimentale pour le noyau 2.6, voir
https://rt.wiki.kernel.org
Initié par Ingo Molnar, contributeur majeur du noyau
Maintenu par Thomas Gleixner
Surtout utilisé sur x86 et des processeurs performants
(TSC = Time Stamp Counter)
Fonctionne également sur ARM (11 ou plus), Nios II,
Microblaze, ...
Nécessite un noyau « mainline » (ou proche) mais ne
sera probablement jamais intégré à la branche officielle
Mise en place très simple (application d'un patch)
Mêmes API de programmation que Linux standard
Logiciels libres et SE
21
PREEMPT-RT, caractéristiques
Utilisation d'un thread noyau (interruptible) pour le
traitement de chaque interruption
●
●
●
●
4
2 root
SW<
0
0%
0% [sirq-high/0]
5
2 root
SW<
0
0%
0% [sirq-timer/0]
6
2 root
SW<
0
0%
0% [sirq-net-tx/0]
Prévention des inversions de priorité (par héritage)
Timers noyau haute précision (HRTIMER)
Amélioration des mécanismes de synchronisation
Le résultat est un noyau (presque) « préemptif », mais
reste un noyau Linux
Logiciels libres et SE
22
PREEMPT-RT, résumé
●
●
●
●
●
●
Changements significatifs du code noyau
–
Verrouillage des sections critiques
–
Volume du patch important
Utilisation de mlockall() → verrouillage des pages
mémoire en RAM
Le coût de la préemption peut être important si le
nombre de tâches TR augmente
Temps de latence maximum nettement amélioré
–
dépend largement de la plate-forme matérielle (TSC)
–
dépend de la configuration logicielle
–
Bons résultats sur x86 depuis de nombreuses années
Permet de garantir moins de 50 µs de jitter (x86)
Risque sur la maintenance (financement) ?
Logiciels libres et SE
23
Linux avec co-noyau
●
●
Ajout d'un « co-noyau » pour la gestion du temps-réel
–
Sous-système temps-réel intégré à un module noyau
–
Patch de « virtualisation » des interruptions
Différents modèles de programmation
–
Noyau uniquement (RTLinux, version libre)
–
Noyau et espace utilisateur, semi-intégration Linux
(RTAI, www.rtai.org)
–
Noyau & espace utilisateur, intégration Linux complète
(Xenomai, www.xenomai.org)
Logiciels libres et SE
24
Linux avec co-noyau
●
●
Séparation entre le composant temps-réel et Linux
–
Ordonnanceur temps-réel spécifique
–
Pas de dépendance sur les sections critiques Linux :-)
Virtualisation de la gestion d'interruptions Linux
–
●
●
●
Routage prioritaire des IRQs vers le co-noyau
Linux comme tâche idle du co-noyau
Volume du patch noyau plus faible qu'avec PREEMPTRT
Se rapproche de la technique de « para-virtualisation »
des hyperviseurs (adaptation de l'OS)
Logiciels libres et SE
25
Linux + co-noyau, suite
●
●
●
Peu de modifications sur le noyau Linux
–
patch de virtualisation (très bas niveau)
–
notion de domaine d'exécution (temps-réel / normal)
Pas d'impact sur l'écriture de code noyau classique
Impact sur l'écriture de code temps-réel !
–
●
utilisation des API fournies par le co-noyau
Excellentes performances TR
–
ordonnanceur spécifique indépendant
–
sous-système temps-réel bien délimité
–
jitter maximal de l’ordre de 10 µs sur Atom/x86 !
Logiciels libres et SE
26
RTLinux
●
●
●
●
●
●
Projet universitaire (NMT) développé par Victor
Yodaiken et Michael Barabanov en 1999
Produit commercial développé par FSMLabs
Dépôt d’un brevet logiciel → conflit avec la FSF
Vendu à WIND RIVER en 2007
Développement en espace noyau (?)
Version GPL obsolète (2.6.9) retirée par WIND RIVER
Logiciels libres et SE
27
Architecture initiale RTLinux
Logiciels libres et SE
28
RTLinux en 2002
Logiciels libres et SE
29
RTAI
●
●
●
●
●
●
Real Time Application Interface
Un « fork » de RTLinux développé au DIAPM de l’école
polytechnique de Milan → Dipartimento di Ingegneria
Aerospaziale (Paolo Montegazza)
Utilisé au DIAPM pour des travaux d’enseignement et
de recherche
Quelques utilisations industrielles
Position douteuse / brevet logiciel FSMLabs
Toujours actif mais peu d’évolution → version 3.8 en
février 2010, 3.9 en août 2012
Logiciels libres et SE
30
Xenomai
●
●
●
●
●
●
Xenomai est un sous-système temps-réel de Linux
–
Programmation de tâches en espace utilisateur
–
API d'application et de pilotes temps réel
(RTDM) dédiées
Intégré au noyau Linux → « Real-time sub-system »
Supporte de nombreuses architectures
Dispose de « skins » permettant d'émuler des API
temps réel (POSIX, VxWorks, VRTX, uITRON, ...)
Plus complexe à mettre en œuvre que PREEMPT-RT
mais performances 5 à 10 fois supérieures
Licence GPL (cœur), LGPL (interfaces, espace
utilisateur)
Logiciels libres et SE
31
Architecture générale
●
●
Xenomai utilise un micro-noyau (ADEOS) pour partager
le matériel avec le noyau Linux
Un processus contient des threads TR et TP (Linux)
Processus Linux
pilote TR
API TR
noyau TR
micro-noyau
Logiciels libres et SE
32
Répartition sur les deux domaines
libpthread_rt
Code applicatif VxWorks
glibc
Code applicatif POSIX
Xenomai
libvxworks
glibc
Xenomai
libpthread
Appels système
Noyau Linux
Pile réseau
VFS/FS
Xenomai RTOS
...
Noyau
Adeos I-Pipe
Hardware
Logiciels libres et SE
33
Linux/Xenomai et le TR :)
Logiciels libres et SE
34
Android
●
●
●
●
●
●
●
Android = un système d'exploitation basé sur un noyau
Linux
Un « framework » fournissant des applications et
permettant d'en ajouter facilement
Basé sur Dalvik (puis ART), une machine virtuelle Java
(très) optimisée pour le mobile
Navigateur web basé sur Webkit puis Chrome
Graphique optimisé en 2D ou 3D basé sur OpenGL/ES
Nouvel environnement de développement « Android
Studio » compatible avec Android « wear » (#IoT)
Partiellement open source mais pas réellement du
logiciel libre...
Logiciels libres et SE
35
Android et l'industrie
●
●
●
●
●
●
●
Linux fournit des API graphiques (Qt, EFL) mais
« difficiles » à programmer
Android est avantageux si le projet utilise une IHM
Base importante d'applications Android !
Android est conçu pour la téléphonie et les tablettes
mais des BSP Android sont fournis pour les cartes
(ARM) récentes (BB Black, i.MX6, ...)
Android utilise un noyau Linux :-)
Assez peu de projets pour l'instant
Concurrence de Yocto !
Logiciels libres et SE
36
Avantages/inconvénients
●
●
Avantages
–
Programmation Java (simple et répandue) + IHM
–
Communauté importante
–
Fait rêver les managers (tablette = grand public → bon
marché)
Inconvénients
–
Compatibilité POSIX partielle
–
Système de « build » statique assez rudimentaire par
rapport à ceux de Linux (Buildroot, OE)
–
Qualité des BSP variable mais portage « simple »
–
Pas réellement un projet libre ni communautaire :-(
–
Google fait peur !
–
Interfaces matérielles industrielles non supportées
(CAN, I2C, SPI, …)
Logiciels libres et SE
37
eCOS
●
●
●
●
●
●
embeddable Configurable OS (CYGNUS 1997)
Supporte de nombreux CPU (16), 32 et 64 bits
Empreinte mémoire de 10 à 100 Ko
Outils de configuration avancé, gestion de «paquets»
Version « pro » par
Utilisé dans le multimédia :
–
http://www.ecoscentric.com/ecos/examples.shtml
Logiciels libres et SE
38
RTEMS
●
●
●
●
●
●
●
●
RTEMS = Real Time Executive for Multiprocessor
Systems
Initialement « Missile Systems » puis « Military
Systems »
Exécutif temps réel embarqué diffusé sous licence libre
(GPL avec exception)
Ce n'est pas exactement un système d'exploitation car
l'application est « liée » au noyau → un seul processus
mais plusieurs « threads »
Programmation C, C++, Ada
Plus de 100 BSP disponibles pour 20 architectures
API RTEMS « classique » ou POSIX
Utilisé par EADS Astrium, ESA, NASA, etc.
Logiciels libres et SE
39
RTEMS, suite
●
●
●
RTEMS est un exécutif TR :
–
Un seul processus
–
Beaucoup plus petit qu'un OS → en sélectionnant les
composants on peut arriver à une taille de quelques
dizaines de Ko :-)
–
Pas (peu) de support MMU
–
De nombreuses fonctionnalités sont optionnelles :
réseau, système de fichiers, etc.
–
Configuration statique de l'application
Permet d'ajouter « facilement » API, ordonnanceur
Léger, environ 600K lignes pour la version 4.11 (15 M
pour le noyau Linux)
Logiciels libres et SE
40
Les outils libres
Logiciels libres et SE
41
Typologie des outils
●
●
●
●
●
Outils de base → « toolchain » + mise au point →
GCC, GDB, LLVM
IDE → Eclipse (?)
Construction de distribution → Buildroot, Yocto/OE
Émulation / simulation → QEMU
Gestion de version (Git, SVN)
→ Les meilleurs de ces outils existent dans le monde
du logiciel libre :-)
Logiciels libres et SE
42
Production de distribution (Linux)
●
●
●
●
●
●
Un outil crée la distribution à partir des sources des
composants adaptés en appliquant des « patch »
Il ne s'agit pas de distribution mais d'outil de création
de distribution
L'outil ne fournit pas les sources mais les règles de
production et prend en compte les dépendances
L'outil peut produire la chaîne de compilation croisée
L'outil produit les différents éléments de la distribution
–
Image du bootloader
–
Noyau Linux
–
Images du root-filesystem
Meilleure solution qu'une distribution « générique »
–
sécurité
–
traçabilité
Logiciels libres et SE
43
Les principaux outils disponibles
●
●
●
Yocto/OpenEmbedded
–
Moteur écrit en Python
–
Très puissant mais lourd
–
Basé sur des fichiers de configuration
Buildroot
–
Basé sur la commande « make »
–
Au départ un démonstrateur pour uClibc
–
Désormais un véritable outil, bien maintenu !
–
Approche statique (pas de paquets)
OpenWrt
–
Dérivé de BR
–
Orienté vers les IAD (Internet Access Device)
–
Gère les paquets binaires
Logiciels libres et SE
44
Buildroot
Logiciels libres et SE
45
Buildroot
●
●
●
●
●
●
●
Lié au projet uClibc (micro-C-libc) = libC plus légère
que la Glibc
But initial: produire des root-filesystem simples pour
tester uClibc
Moteur uniquement basé sur des fichiers Makefile et
quelques scripts-shell →utilisation de GNU-Make
Outil de configuration utilise le langage Kconfig
Peut produire la chaîne de compilation (uClibc, Glibc,
Eglibc, ...) ou importer une chaîne existante
Approche statique
Pas de version « officielle » avant 2009 (2009.02)
Logiciels libres et SE
46
Buildroot aujourd’hui
●
●
●
●
●
●
●
●
Repris en 2009 par Peter Korsgaard et Thomas
Petazzoni
Une version officielle tous les 3 mois: 2009.02, ...
2012.11, ..., 2015.02
Projet géré sous Git : http://git.buildroot.net/buildroot
Bonne documentation :
http://buildroot.uclibc.org/docs.html
Plus de 1200 composants adaptés (2015.02)
Support CPU x86, ARM, PowerPC, SH4, ...
Il est désormais simple d’ajouter un support de carte
par des fichiers de configuration
Projets très dynamique !
Logiciels libres et SE
47
Yocto / OE
●
●
●
●
Similaire à BR mais plus évolué et modulaire
Utilisé par les éditeurs pour leurs produits commerciaux
→ Wind River
Utilisé par les fabricants de matériel pour les BSP
(Board Support Package) → Freescale, Gumstix, TI, ...
Yocto n'est pas une distribution mais fournit des
« templates » et outils pour créer des distributions →
« méta données » organisées en couches (layers)
–
Support matériel (meta-intel, meta-raspberrypi)
–
Distributions (meta-yocto, meta-angstrom)
–
Composants « métier » (meta-ivi) → GENIVI
http://layers.openembedded.org/layerindex
It's not an embedded Linux distribution
– it creates a custom one for you
Logiciels libres et SE
48
Principe des « layers »
Logiciels libres et SE
49
« Workflow » OE
Logiciels libres et SE
50
Émulateur QEMU
●
●
●
●
●
●
Émulateur de matériel initialement développé par
Fabrice Bellard, diffusé sous GPL v2
Exécuté dans l'espace utilisateur de Linux
Permet d'émuler diverses architectures: x86, PowerPC,
ARM, etc.
Émulation de carte complète → outil de
développement, mise au point, test automatique
Outil de certification DO-178 (Adacore/Couverture)
http://www.open-do.org/projects/couverture
Désormais, large communauté avec dépôt Git sur
http://git.savannah.gnu.org/cgit/qemu.git
Logiciels libres et SE
51
Open Hardware
Logiciels libres et SE
52
(R)évolution du matériel
●
●
●
●
●
Évolution du x86 vers ARM
Création d'un marché autour des « hobbyistes » en
électronique
–
Arduino, Raspberry Pi & friends
–
Adafruit, Snootlab & friends
Les professionnels utilisent parfois ces plate-formes ou
du moins profitent de la baisse des coûts → attention
au choix !
Développement et conception simplifiés
–
généralisation d'un open-hardware pragmatique
–
utilisation de modules CPU
–
nouveaux langages (HTML5, Python)
Nouveaux canaux de distribution et plate-formes de
financement (kickstarter, ...)
Logiciels libres et SE
53
Versatile PB and sons !
< 20 €
< 15 €
< 30 €
€€€€ !
< 25 €
Logiciels libres et SE
54
Cependant...
●
●
●
●
●
Certaines plate-formes génériques permettent de créer
une « maquette » mais difficilement la version
définitive → qualité insuffisante
La connectivité nécessaire n'est pas toujours disponible
–
Wi-Fi
–
BT
–
Capteurs divers
Un créateur n'est PAS un développeur logiciel et
encore moins un intégrateur système → « fusion » art /
design / technologie
Quelques plates-forme dédiées sont désormais
disponibles → WeIO (démo!)
Pour l'industrie ne pas oublier la durée de
maintenance !
Logiciels libres et SE
55
Module WeIO
Logiciels libres et SE
56
Co-design
Logiciels libres et SE
57
Situation actuelle
●
●
●
●
Les systèmes embarqués deviennent de plus en plus
complexes
–
Hier → RTOS mono-tâche (1 seule application)
–
Aujourd'hui → système multitâche proche d'un OS
classique (Linux, Android, …)
Exemples de systèmes :
–
Encodeur / décodeur vidéo HD
–
Système « mixte » temps réel et traitement des données
(banc de test)
Le CPU n'est pas forcément capable de répondre aux
exigences fonctionnelles du système
L'utilisation du multi-cœur améliore les choses mais
décale le problème (et augmente prix + consommation)
Logiciels libres et SE
58
Évolution de la conception
●
●
●
●
●
On travaille maintenant au niveau système (ou
fonctionnalité) et non au niveau porte logique
Les fonctionnalités peuvent être implantées dans des
composants spécifiques de type ASIC (Application
Specific Integrated Circuit). On parle alors de Système
sur Silicium « SoC » (System on Chip).
Les fonctionnalités peuvent être implantées dans des
composants logiques programmables de type FPGA
(Field Programmable Gate Array). On parle alors de
système « SoPC » (System on Programmable Chip).
Le plus souvent le système dispose d'un CPU (avec
OS) + d'un accélérateur matériel pour des tâches
dédiés (compression, génération de signal, …)
L'association des deux parties correspond au « codesign »
Logiciels libres et SE
59
Exemple de système
●
●
●
●
Le processeur est en général externe→ SoC associé à
un FPGA
Exemple de SoC : i.MX (Freescale), AM335x (TI)
Exemple de FPGA : Altera Cyclone, Xilinx
Spartan/Virtex
Système hybride : Armadeus, Zynq
Logiciels libres et SE
60
Avantages du co-design
●
●
●
●
●
L'OS – et donc le CPU - est déchargé de tâches très
coûteuses (voire inaccessibles) en calcul logiciel
L'approche FPGA permet de garantir la souplesse →
utilisation d'un langage de programmation (Verilog ou
VHDL) → portabilité sur plusieurs modèles de FPGA
Cette même approche garantit la propriété intellectuelle
dans le cas de licences parfois contraignantes
–
La fonctionnalité « métier » dans le FPGA
–
Le pilote (GPL si Linux) est une simple interface
On trouve des bibliothèques fonctionnelles (des « IP »)
comme avec le logiciel classique → €€€ !
Le co-design peut également concerner l'association
µP (CPU) / micro-contrôleur reliés – par exemple - par
un bus de type SPI
Logiciels libres et SE
61
Association µC / Linux
●
Cette approche « hybride » assure un faible coût en
garantissant les performances
Logiciels libres et SE
62
Système Linux « pur »
●
Cette approche nécessite souvent un adaptation coté
noyau → temps réel (Xenomai, PREEMPT-RT, …)
Logiciels libres et SE
63
Choix du matériel
●
●
Solution 1 :
–
Module type SoC
–
FPGA ajouté à la carte finale
–
Nécessite un design matériel
Solution 2 :
–
Module SoC intégrant directement un FPGA
–
Xilinx (Zynq), Altera, Armadeus APF27/APF51
–
Pas (ou peu) de design matériel
–
La demande du marché pousse ce type de solution
Logiciels libres et SE
64
Cas d'exemple
●
●
Un système nécessite une horloge de synchronisation
(période = 1 ms)
–
Réalisable sur certains systèmes (tâche périodique sur
un GPIO) → Raspberry Pi/ARM + Linux-TR
–
Impossible à réaliser sur d'autres architectures (x86)
sans 1 carte PCI dédiée (€€€)
Une solution hybride utilise :
–
Un système sous Linux (architecture x86, ARM, …) non
TR
–
Un contrôleur matériel FPGA sur bus USB
–
Simple à mettre en place en langage HDL
–
Le calculateur Linux pilote le contrôleur par message
USB mais ne gère pas le TR → insensible aux
variations de charge
Logiciels libres et SE
65
Raspberry Pi + FPGA
USB
KNJN DragonPCI-E
Bugblat sur bus local
Logiciels libres et SE
66
Questions ?
Logiciels libres et SE
67