Co-Design Exam

Exercice 1 - Concepts fondamentaux du Co-Design

Question 1.1 - Explication de l'IP-reuse et son utilité dans les SoC

L'IP-reuse (Intellectual Property reuse ou réutilisation de propriété intellectuelle) est une pratique consistant à utiliser des blocs matériels ou logiciels pré-conçus, pré-vérifiés et prêts à être intégrés dans un nouveau système. Dans la conception des SoC (System on Chip), l'intégration de millions de transistors de zéro est devenue impossible dans des délais raisonnables. En profitant de l'IP-reuse, les concepteurs assemblent des composants standards (comme un processeur ARM, un contrôleur mémoire, un bus) comme des briques de base. Cela permet de réduire drastiquement le temps de conception (Time-to-Market), de diminuer les coûts de développement et de limiter les risques d'erreurs puisque ces blocs ont déjà été testés et validés.

Question 1.2 - Architecture MPSoC

L'architecture MPSoC (Multi-Processor System on Chip) désigne une puce intégrant plusieurs processeurs (microprocesseurs, DSP, ou microcontrôleurs) travaillant en parallèle sur la même puce, accompagnés de mémoires et de périphériques de communication. Cette architecture permet de répondre aux besoins de calculs intensifs et parallèles tout en gardant une faible consommation d'énergie, chaque processeur pouvant être spécialisé pour une tâche précise.

Question 1.3 - Objectif du partitionnement matériel / logiciel

Le partitionnement matériel / logiciel a pour but de diviser les différentes tâches d'un cahier des charges entre une implémentation logicielle (exécutée par un processeur) et une implémentation matérielle (exécutée par des circuits dédiés comme des ASIC ou FPGA). L'objectif principal est de trouver la répartition optimale permettant de respecter les contraintes du système (performances temps réel, consommation énergétique, taille, coût) : on confie au matériel les tâches nécessitant de la vitesse et du parallélisme, et au logiciel les tâches exigeant de la flexibilité et impliquant des traitements séquentiels complexes.

Question 1.4 - Différence entre FPGA Hard Core et FPGA Soft Core

Cette distinction concerne la manière dont un processeur (ou une IP complexe) est implémenté dans le FPGA :

• Hard Core (Cœur en dur) : C'est un bloc de silicium dédié et figé physiquement au sein de la puce FPGA (par exemple, un processeur ARM intégré). Il offre d'excellentes performances (vitesse élevée) et consomme moins d'énergie, mais il n'est pas modifiable.
• Soft Core (Cœur en code/souple) : C'est un processeur décrit dans un langage de description matérielle (VHDL/Verilog) et synthétisé en utilisant les ressources logiques programmables standards du FPGA (LUTs, bascules). Il est très flexible (on peut configurer le nombre de registres ou le jeu d'instructions) mais il occupe de l'espace logique, consomme plus et fonctionne à une fréquence d'horloge inférieure.

Question 1.5 - Définition de la Co-Simulation

La co-simulation est la simulation conjointe des parties matérielles (hardware) et logicielles (software) d'un système avant sa fabrication physique. Elle permet de vérifier très tôt dans le cycle de conception que le code logiciel s'exécute correctement sur le modèle du matériel, et que les interfaces et bus de communication entre les deux mondes fonctionnent sans erreur de synchronisation.

Question 1.6 - Les compromis en co-design

Dans la conception conjointe, les concepteurs doivent évaluer en permanence plusieurs compromis (Trade-offs) :

• Performance (Vitesse) vs. Surface (Coût) : Implémenter un algorithme en matériel accélère l'exécution mais augmente la surface de silicium nécessaire, ce qui coûte plus cher.
• Flexibilité vs. Efficacité énergétique : Une solution logicielle est facile à mettre à jour (flexibilité) mais un processeur générique consomme plus d'énergie pour une tâche donnée qu'un accélérateur matériel dédié.
• Temps de développement vs. Optimisation : Utiliser des IP standards ou du logiciel raccourcit le temps de conception, mais concevoir un matériel personnalisé permet une optimisation maximale des ressources.

Exercice 2 - Choix d'environnement d'exécution

Tâche 1 - Traitement d'image temps réel

Choix : Environnement Matériel (Hardware / FPGA / ASIC). Argumentation : Le traitement d'image (ex: filtrage, détection de contours) sur un flux vidéo exige un très haut débit de données et des calculs matriciels massifs. Le matériel permet un traitement hautement parallèle (un pixel calculé à chaque coup d'horloge) indispensable pour garantir le strict respect des contraintes temps réel, ce qu'un processeur séquentiel classique peinerait à accomplir sans ralentissement.

Tâche 2 - Communication USART

Choix : Environnement Logiciel (Software / Microcontrôleur). Argumentation : L'USART est un protocole de communication asynchrone à très bas débit (généralement quelques kb/s à un peu plus de 1 Mb/s). La gestion des octets reçus/transmis est séquentielle, peu exigeante en calcul et peut être aisément gérée par les interruptions d'un processeur basique.

Tâche 3 - Cryptage de message SMS

Choix : Environnement Logiciel (Software). Argumentation : Un SMS est un bloc de données très court (160 caractères maximum) et son émission/réception est un événement ponctuel. Le cryptage d'un si petit volume de données prendra quelques microsecondes à un microcontrôleur. Développer un matériel dédié pour un flux aussi faible serait un gaspillage de ressources (surface et temps de développement).

Tâche 4 - Cryptage d'un flux vidéo

Choix : Environnement Matériel (Hardware). Argumentation : Contrairement au SMS, un flux vidéo représente un volume de données continu et très important (plusieurs Mo/s). Confier le cryptage en temps réel d'un tel flux à un processeur provoquerait un goulot d'étranglement majeur. Un bloc matériel dédié (ex: accélérateur AES) traitera le flux à la volée, soulageant le processeur central.

Tâche 5 - Stockage toute les secondes d'une information analogique sur SD

Choix : Environnement Logiciel (Software). Argumentation : La fréquence de traitement (1 Hz, soit une fois par seconde) est extrêmement lente à l'échelle de l'électronique. De plus, écrire sur une carte SD implique de gérer un système de fichiers (comme FAT32), ce qui relève de structures de données complexes et de décisions séquentielles, des tâches typiquement et facilement gérées par du code logiciel (bibliothèque C standard).

Exercice 3 - Conception du récepteur VOD

Question 3.1 - Tâches à développer (Extraction du cahier des charges)

À partir de l'énoncé et du tableau, le système nécessite le développement des 8 tâches fonctionnelles suivantes :

1. Acquisition vidéo : Réception du flux IP via Ethernet, Wifi ou 3G.
2. Décodage MPEG-2 : Décompression du flux vidéo entrant.
3. Bufferisation de 15 minutes : Gestion de la mémoire tampon pour la lecture et le saut rapide.
4. Stockage permanent (FLASH) : Enregistrement de la vidéo sur un support physique.
5. Gestion de la vidéo phonie : Prise en charge de la caméra intégrée.
6. Affichage principal : Pilotage de la sortie HDMI et de l'écran LCD.
7. Menu interactif : Gestion de l'interface utilisateur (télécommande IR, Bluetooth).
8. Superposition d'affichage : Incrustation de plusieurs vidéos simultanées (ex: VOD + appel visio en PIP).

Note : La gestion de l'alimentation (autonomie de 4h) est une contrainte transversale qui guidera les choix matériels (batterie, gestion d'énergie), mais n'est pas listée comme une tâche logicielle/matérielle de traitement des données dans le "tableau 1".

Question 3.2 - Schéma bloc du système

Le schéma bloc illustre le cheminement des données depuis l'acquisition jusqu'à l'affichage, articulé autour des bus du système.

Bloc Fonctionnel	Rôle	Connexions
Interface Réseau (Eth/Wifi/3G)	Reçoit le flux vidéo entrant	Connecté au contrôleur principal
Mémoire SDRAM (Buffer)	Stocke les 15 min de flux	Accès rapide (DMA) via bus système
Mémoire FLASH	Stockage vidéo à long terme	Connecté au contrôleur principal
Caméra (Vidéophonie)	Capture le flux de l'utilisateur	Connecté au contrôleur principal
Périphériques I/O (IR, BT)	Reçoit les commandes de menu	Connecté au CPU
CPU / Microcontrôleur	Gère les interfaces, l'acquisition, le système de fichiers, la vidéophonie et le menu interactif	Pilote l'ensemble via Bus Système (ex: AMBA)
Accélérateur MPEG-2 (HW)	Décode le flux vidéo de manière matérielle	Lit Buffer -> Décode -> Envoie au module d'affichage
Contrôleur Vidéo & Superposition (HW)	Gère la superposition matérielle (PIP) et génère le signal de sortie	Sortie vers Connecteur HDMI et Dalle LCD

Question 3.3 - 3.3.1 Partitionnement matériel / logiciel

L'analyse du tableau 1 et des contraintes textuelles nous permet de statuer sur le partitionnement :

1. Décodage MPEG-2 -> Matériel (HW). Justification : L'énoncé précise explicitement que c'est "trop lent en soft". C'est une obligation technique de l'implémenter en Hard.
2. Superposition d'affichage -> Matériel (HW). Justification : Contrainte stricte ("ne peut se faire que sur cible matériel").
3. Menu interactif -> Logiciel (SW). Justification : L'énoncé indique que la gestion est "plus facile à faire sur cible logiciel". Cela prend 1 mois en SW contre 1 semaine en HW, mais le logiciel offre la flexibilité requise pour les menus.
4. Vidéo phonie -> Logiciel (SW). Justification : Contrainte stricte ("L’IP vidéo phonie est faite sur cible logiciel").
5. Affichage -> Logiciel (SW). Justification : La tâche doit être finie en 2 semaines. Bien que le tableau affiche "---" pour le matériel, le besoin de le faire "avant tous les développements hardware" implique une implémentation logicielle rapide qui servira de base de test (stub) pour le reste.
6. Acquisition vidéo -> Logiciel (SW). Justification : Le développement HW prend 4 mois, ce qui monopoliserait une équipe entière et menacerait le délai de 6 mois. Le développement SW ne prend qu'1 mois et permet de gérer plus souplement les différents protocoles réseaux (TCP/IP).
7. Bufferisation (15 min) -> Logiciel (SW). Justification : Seulement possible en SW (1 mois) selon le tableau (HW "---"). Gestion d'adresses et pointeurs en RAM.
8. Stockage permanent -> Logiciel (SW). Justification : Prend 2 semaines en SW. Le tableau indique "---" pour le matériel. (La gestion du FAT/système de fichiers de la mémoire Flash est standardisée en logiciel).

Question 3.3.2 - Graphe de dépendance

Les dépendances entre les tâches découlent des contraintes de l'énoncé :

• Affichage n'a pas de prérequis et doit être exécuté en premier ("avant tous les développements hardware").
• Décodage MPEG-2 et Superposition (Hardware) doivent attendre la fin de l'Affichage.
• Menu interactif doit être développé après l'Affichage.
• Acquisition vidéo peut être développée de façon asynchrone par rapport au MPEG-2 (car on utilise des vidéos décodées locales pour les tests).
• Stockage permanent doit être développé après l'Acquisition.
• Intégration, tests et validation ne peuvent commencer que lorsque tout est terminé (dernier mois).

(Début)
   |
   v
[Affichage (SW)] 
   |
   +-----------------------+---------------------+
   |                       |                     |
   v                       v                     v
[Menu interactif (SW)]  [Superposition (HW)]  [Décodage MPEG-2 (HW)]
   |
   v
[Acquisition vidéo (SW)]
   |
   v
[Stockage permanent (SW)]
   |
   v
[Bufferisation (SW)]   (Ces tâches peuvent s'enchaîner indépendamment 
   |                    du HW car le Soft a une seule équipe)
   v
[Vidéophonie (SW)]
   |
   v
(Mois 6 : Intégration et Tests Systèmes)

Question 3.3.3 - Chronogramme de réalisation

Ressources : 1 équipe Soft, 2 équipes Hard. Durée totale max : 6 mois (M1 à M6). Pour gérer finement, nous découpons chaque mois en deux quinzaines (Q). 1 mois = 2 quinzaines.

• Equipe Soft (1 équipe) : Affichage (2 sem = 1Q), Menu (1 mois = 2Q), Acquisition (1 mois = 2Q), Stockage (2 sem = 1Q), Vidéophonie (2 sem = 1Q), Buffer (1 mois = 2Q). Total = 4.5 mois (9Q).
• Equipe Hard 1 : Superposition (1 mois = 2Q). Doit attendre M0.5.
• Equipe Hard 2 : Décodage (2 mois = 4Q). Doit attendre M0.5.

Période (Mois)	Temps	Equipe logicielle (Soft)	Equipe matérielle (Hard 1)	Equipe matérielle (Hard 2)
Mois 1	Q1	Affichage (0.5 mois)	En attente de l'affichage	En attente de l'affichage
	Q2	Menu Interactif (Début)	Superposition (Début)	Décodage MPEG-2 (Début)
Mois 2	Q3	Menu Interactif (Fin)	Superposition (Fin)	Décodage MPEG-2
	Q4	Acquisition (Début)	Libre / Aide	Décodage MPEG-2
Mois 3	Q5	Acquisition (Fin)	Libre / Aide	Décodage MPEG-2 (Fin)
	Q6	Stockage (0.5 mois)	Libre	Libre
Mois 4	Q7	Vidéophonie (0.5 mois)	Libre	Libre
	Q8	Bufferisation (Début)	Libre	Libre
Mois 5	Q9	Bufferisation (Fin)	Libre	Libre
	Q10	Marge de sécurité (0.5 m)	Marge de sécurité	Marge de sécurité
Mois 6		Intégration et Validation	Intégration et Validation	Intégration et Validation

Question 3.4 - Implémentation via microcontrôleur et FPGA

Dans cette architecture mixte, le système est organisé autour d'une carte électronique intégrant un Microcontrôleur (MCU) et un composant programmable (FPGA) reliés par un bus de communication haute vitesse (par exemple, SPI, ou un bus parallèle asynchrone type mémoire).

• Le Microcontrôleur (MCU) agit comme le maître du système (Master). Il exécute le code C/C++ gérant l'Interface Réseau TCP/IP pour l'acquisition vidéo. Il gère également le système de fichiers pour le stockage local (Flash), maintient les pointeurs circulaires pour le Buffer Vidéo, scrute les entrées (IR, Bluetooth) pour le Menu, et exécute la routine logicielle de la vidéophonie.
• Le FPGA agit comme un co-processeur (Slave/Accelerators). Il héberge les cœurs IP matériels validés par les équipes Hard. Le MCU lui envoie le flux vidéo compressé MPEG-2 récupéré depuis l'Acquisition ou le Buffer. Le FPGA décompresse matériellement le flux en temps réel, assure la superposition de l'image (VOD en fond, caméra vidéophonie au premier plan) selon les registres de contrôle fixés par le MCU, et gère directement la génération des signaux physiques à destination de l'écran (signaux HDMI / signaux d'horloge LCD).

Question 4 - Scénarios de test et de validation

Pendant le 6ème mois d'intégration, les équipes utiliseront des scénarios incrémentaux :

1. Test unitaire Matériel (Vidéo Locale) : Injection d'une vidéo MPEG-2 depuis la mémoire locale directement vers le FPGA pour s'assurer que le pipeline (Décodage HW -> Superposition HW -> Affichage) fonctionne et produit une image nette sur le LCD/HDMI sans impliquer le réseau.
2. Test d'Interface (Le Menu) : Pendant la lecture locale, activation de la télécommande IR/Bluetooth pour valider que le microcontrôleur intercepte l'événement et que le menu s'affiche fluidement (test de la communication entre la logique d'Affichage et le HW).
3. Test Nominal bout-en-bout (VOD Streaming) : Lancement de l'acquisition réseau (Ethernet/Wifi). Validation que les paquets IP sont correctement désencapsulés par le SW, placés dans le Buffer, envoyés au HW pour décodage, avec mesure du respect des contraintes temps réel (pas de saccades).
4. Test de Charge (Pip + Réseau + Stockage) : Lancement d'une session complète VOD avec enregistrement simultané en mémoire Flash, puis initiation d'un appel vidéophonie par-dessus (vérification de la superposition HW et de la capacité du processeur à gérer l'IP téléphonie + l'acquisition sans geler le système).
5. Test d'Autonomie : Validation finale de la consommation globale de l'implémentation HW/SW fonctionnant à plein régime pour s'assurer qu'elle respecte la limite d'autonomie de 4 heures sur batterie.

Méthode

Pour aborder sereinement un problème de "Co-Design" à l'examen :

1. Identifier les limites et les contraintes : La clé de cet exercice réside dans les contraintes textuelles (ex: "l'affichage doit se faire avant le hardware"). Ces phrases ne sont pas là pour habiller l'énoncé, elles dictent strictement vos dépendances (Graphe) et votre calendrier (Chronogramme). Surlignez-les en première lecture.
2. Évaluer les compromis temporels : Lorsqu'une tâche offre des temps radicalement différents (ex: Acquisition = 4 mois en HW, 1 mois en SW), et que vous avez un délai global serré (6 mois), le choix du partitionnement devient souvent une simple question de survie au planning, plus qu'un pur choix technologique.
3. Visualiser le flux de données : Le schéma de l'architecture devient évident une fois que vous suivez le cheminement de la donnée brute. (Ex: La donnée arrive du réseau -> entre dans le MCU -> va au Buffer -> passe au FPGA pour le décodage -> sort sur l'écran). L'organisation logique dicte l'organisation physique.